Program scheduling method and system with trusted intent verification on android side

Abstract

The application relates to the field of information technology, in particular to a program scheduling method and system with trusted intent verification on an Android end. The method comprises the following steps: intercepting a cross-application execution request of an AI Agent, obtaining calling party information, target application information, action type, data range, current permission snapshot and user context abstract, and encapsulating the same into an intent encapsulation body; performing integrity protection and coding processing on the intent encapsulation body, and transmitting the intent encapsulation body into a trusted execution environment; performing multi-stage intent verification on the intent encapsulation body in the trusted execution environment; issuing a secure execution token after the verification in the trusted execution environment is passed, wherein the secure execution token is bound with the intent encapsulation body; and verifying the validity of the secure execution token in a normal execution environment, and if the verification is passed, determining a target execution resource and scheduling a corresponding AI Agent subtask to the target execution resource for execution.

Description

Technical Field

[0001] This application relates to the field of information technology, specifically to a program scheduling method and system with trusted intent verification on an Android device. Background Technology

[0002] Edge AI Agents refer to intelligent agent programs deployed on devices such as smartphones, tablets, and in-vehicle terminals, possessing the capabilities of intent understanding, task planning, tool invocation, and cross-application execution. With the deepening deployment of large language models on mobile devices, edge AI Agents have evolved from simple "conversational assistants" into "executable intelligent agents" with local reasoning, context awareness, and system API operation capabilities. They can invoke sensitive capabilities such as SMS, camera, photo album, location, system settings, payment, file management, and third-party application interfaces based on user natural language commands, while consuming significant amounts of heterogeneous computing resources on the edge.

[0003] Currently, the execution chain of edge AI agents typically spans the application layer, system service layer, native layer, hardware accelerator, and security module. Existing solutions often have the following shortcomings: At the security verification level, permission verification and intent filtering are mostly completed at the Android application layer or system service layer. This layer belongs to the Rich Execution Environment (REE), which is vulnerable to threats such as hook frameworks, privilege escalation attacks, malicious application injection, prompt word injection, or man-in-the-middle tampering, making it difficult to guarantee the integrity and reliability of intent payload and verification results; Although some solutions store device keys in a Trusted Execution Environment (TEE), this is only used for a single cryptographic operation and does not perform dynamic analysis and risk assessment of the complete execution intent of the AI ​​Agent, failing to identify the potential risks of combined actions such as "reading the SMS and immediately sending it to the public network".

[0004] Therefore, it is necessary to continue researching security control technologies for edge AI agents. Summary of the Invention

[0005] This specification describes a program scheduling method and system with trusted intent verification on an Android device through several embodiments.

[0006] Firstly, embodiments of this specification provide an Android application scheduling method with trusted intent verification, comprising the following steps:

[0007] Step S1: Intercept the cross-application execution request of the AI ​​Agent, obtain the caller information, target application information, action type, data scope, current permission snapshot and user context summary, and encapsulate the obtained information into an intent encapsulation body;

[0008] Step S2: Perform integrity protection and encoding processing on the intent package, establish a communication session with the trusted execution environment through a secure interface, and transmit the intent package to the trusted execution environment;

[0009] Step S3: Perform multi-stage intent verification on the intent package in the trusted execution environment. The multi-stage intent verification includes integrity verification, anti-replay verification, caller authentication, and permission snapshot verification.

[0010] Step S4: After the trusted execution environment verification is passed, a security execution token is issued. The security execution token is bound to the intent encapsulation body. The security execution token includes a risk level, a set of allowed actions, and a resource scheduling policy.

[0011] Step S5: Verify the validity of the security execution token in a normal execution environment. If the verification passes, determine the target execution resource based on the risk level and resource scheduling policy in the security execution token, as well as the real-time hardware status of the end device, and schedule the corresponding AI Agent subtask to the target execution resource for execution.

[0012] Secondly, embodiments of this specification provide an Android-based program scheduling system with trusted intent verification, comprising:

[0013] The acquisition module intercepts cross-application execution requests from the AI ​​Agent, obtains caller information, target application information, action type, data scope, current permission snapshot, and user context summary, and encapsulates the acquired information into an intent encapsulation.

[0014] The encapsulation module performs integrity protection and encoding processing on the intent encapsulation body, establishes a communication session with the trusted execution environment through a secure interface, and transmits the intent encapsulation body to the trusted execution environment;

[0015] The verification module performs multi-stage intent verification on the intent encapsulation in the trusted execution environment. The multi-stage intent verification includes integrity verification, anti-replay verification, caller authentication, and permission snapshot verification.

[0016] The issuance module issues a security execution token after the trusted execution environment verification is passed. The security execution token is bound to the intent encapsulation body and includes a risk level, a set of allowed actions, and a resource scheduling policy.

[0017] The execution module verifies the validity of the security execution token in a normal execution environment. If the verification passes, it determines the target execution resource based on the risk level and resource scheduling policy in the security execution token, as well as the real-time hardware status of the edge device, and schedules the corresponding AI Agent subtask to the target execution resource for execution.

[0018] Thirdly, embodiments of this specification provide an electronic device, including a processor and a memory;

[0019] The processor is connected to the memory;

[0020] The memory is used to store executable program code;

[0021] The processor runs a program corresponding to the executable program code stored in the memory to perform the method described in any of the above aspects.

[0022] Fourthly, embodiments of this specification provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the methods described in any of the above aspects.

[0023] Fifthly, embodiments of this specification provide a computer program product, including a computer program that, when executed by a processor, implements the methods described in any of the above aspects.

[0024] The beneficial effects of the technical solutions provided in some embodiments of this specification include at least the following:

[0025] First, it significantly improves cross-application execution security. The AI ​​Agent's intent verification logic is executed within a Trusted Execution Environment (TEE). The policy tables, risk rules, and anti-replay counters upon which verification relies are all maintained within this secure environment, which cannot be tampered with in a normal execution environment. This effectively reduces the risks of intent tampering, unauthorized execution, and replay attacks.

[0026] Second, it enables the reliable constraint of security verification results on scheduling behavior. By using a security execution token, the risk level, allowed action set, resource scheduling policy, sandbox requirements, and user confirmation status output by the TEE are reliably transmitted to the scheduling engine, so that the scheduler can clearly define "what permissions, what resources, and what priority should be used to execute the task".

[0027] Third, reduce the risk of resource contention and overheating-induced frequency throttling. Under high load scenarios, the scheduling engine proactively reduces the priority of background tasks, splits or postpones tasks, avoids submitting tasks to congested resources in a concentrated manner, reduces resource contention and instantaneous power consumption spikes, and alleviates frequency throttling and performance degradation caused by overheating.

[0028] Fourth, it improves user experience and resource utilization efficiency. Through an idle-aware backfilling scheduling mechanism, low-risk lightweight quantum tasks are inserted into the hardware's idle window for execution. This fully utilizes idle computing power without affecting the smoothness of foreground applications, improving game frame rate stability, camera preview smoothness, and navigation response real-time performance. It also boasts good compatibility with the native Android system, facilitating deployment and promotion on existing terminal platforms.

[0029] Other features and advantages of various embodiments of this specification will be further revealed in the following detailed description and accompanying drawings. Attached Figure Description

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

[0031] Figure 1 This is a schematic diagram of the program scheduling system architecture with trusted intent verification provided in this specification.

[0032] Figure 2 This is a flowchart illustrating the program scheduling method with trusted intent verification provided in this specification.

[0033] Figure 3 This is an activity diagram of the program scheduling method with trusted intent verification provided in this specification.

[0034] Figure 4 This is a schematic diagram of the intent encapsulation and security execution token structure provided in this specification.

[0035] Figure 5 This is a schematic diagram of the heterogeneous resource scheduling method provided in this specification.

[0036] Figure 6 This is a schematic diagram of a program scheduling system with trusted intent verification provided in this specification.

[0037] Figure 7 This is a schematic diagram of the electronic device provided in this specification. Detailed Implementation

[0038] The technical solutions of the embodiments of this specification will be explained and described below with reference to the accompanying drawings. However, the following embodiments are only preferred embodiments of this specification and not all of them. Other embodiments obtained by those skilled in the art based on the embodiments in the implementation methods without creative effort are all within the protection scope of this specification.

[0039] The terms "first," "second," "third," etc., in the description, claims, and accompanying drawings are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such processes, methods, products, or apparatus.

[0040] In the following description, terms such as “inner,” “outer,” “upper,” “lower,” “left,” and “right” are used only to facilitate the description of the embodiments and to simplify the description, and are not intended to indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this specification.

[0041] All data involved in this application are information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0042] Before introducing the technical solutions described in this manual, the application scenarios and related technologies of the technical solutions will be introduced.

[0043] This application relates to the field of edge AI security and system resource collaborative scheduling technology, and in particular to a method and system for AI Agent trusted intent verification and heterogeneous resource scheduling applicable to the Android operating system environment. The edge devices include, but are not limited to, smart devices with local computing capabilities and trusted execution environments, such as smartphones, tablets, in-vehicle smart terminals, wearable devices, and edge computing terminals.

[0044] With the lightweight deployment of large language models on mobile devices, edge AI agents have evolved from simple conversational assistants into intelligent agents capable of autonomously performing cross-application tasks. Typical application scenarios include users requesting the agent to retrieve schedules, take photos, send text messages, organize files, access third-party payment interfaces, or modify system settings via voice or text commands. When performing these tasks, the agent needs to access sensitive capabilities such as SMS, contacts, photo album, location, camera, microphone, Bluetooth, NFC, payment interfaces, and system settings, while simultaneously utilizing heterogeneous computing resources such as CPU, GPU, and NPU to complete model inference and data processing.

[0045] Currently, the execution chain of edge AI Agent spans the application layer, system service layer, native layer, and hardware layer, involving two key links: security verification and resource scheduling.

[0046] First, in terms of security verification, existing solutions mainly rely on Android application layer permission verification or system service layer intent filtering. These verification logics run in a Rich Execution Environment (REE), which is vulnerable to Hook frameworks, privilege escalation attacks, malicious injections, or man-in-the-middle tampering threats, making it difficult to guarantee the authenticity and integrity of the intent payload. Although some solutions store keys in a Trusted Execution Environment (TEE), they are only used for a single encryption and decryption operation, lacking dynamic risk assessment of the Agent's complete execution intent, and cannot identify the potential risks of combined actions such as "reading the SMS and immediately sending it out".

[0047] Second, in terms of resource scheduling, existing inference frameworks typically allocate resources based on fixed priorities or static hardware backends. The scheduler cannot obtain the security verification results, nor can it perform differentiated scheduling based on risk level and real-time hardware status (such as temperature, load, memory bandwidth, and foreground frame deadline), resulting in prominent resource contention and overheating / frequency reduction issues in high-concurrency scenarios.

[0048] In existing technologies, security verification and execution scheduling are disconnected, lacking a closed-loop mechanism that can combine trusted intent verification results with underlying heterogeneous resource scheduling strategies. To address this, this specification proposes an Android application scheduling method and system with trusted intent verification. Through intent encapsulation, multi-stage verification within the TEE, security token issuance, and token-driven heterogeneous resource collaborative scheduling, it achieves trusted constraints on scheduling behavior based on security decisions, while simultaneously improving cross-application execution security and system resource utilization efficiency.

[0049] For details, please refer to the appendix. Figure 1 The program scheduling method and system with trusted intent verification for Android provided in this manual achieve trusted verification of AI Agent execution intent across applications and security-driven heterogeneous resource scheduling through collaborative interaction between the normal execution environment and the trusted execution environment.

[0050] The first step involves the AIAgent request initiation module, running in the normal execution environment (i.e., the Android Framework layer or system service layer), generating a cross-application execution intent based on user instructions or automated tasks. This intent is intercepted by the AgentSchedulerService. As a scheduling service module, AgentSchedulerService does not directly trust the permission judgment results in the normal execution environment. Instead, it extracts key information from the cross-application execution request, including the caller's UID, caller's package name, AI Agent identifier, target application package name, target component or target API, action type, data scope, current permission snapshot, and user context summary. This information is then standardized into a structured intent capsule (IntentCapsule), and a timestamp and random number are appended to the capsule to ensure its timeliness and uniqueness.

[0051] The second step involves AgentSchedulerService passing the intent package to the Native security bridge module via JNI. This module performs binary encoding, digest calculation, and integrity protection on the intent package, and establishes a secure session with the Trusted Execution Environment (TEE) through secure interfaces such as TEE ClientAPI, KeyMint HAL, or vendor-secure HAL. During this process, the Native security bridge module does not directly obtain the hardware key plaintext; instead, it requests the TEE to use a non-exportable hardware-bound key to perform encryption, signing, or message authentication code calculation, passing the ciphertext, digest, random number, timestamp, and call context to the intent verification TA (Trusted Application) within the TEE.

[0052] Third, on the Trusted Execution Environment (TEE) side, after receiving the aforementioned data, the TEE Intent Verification TA performs multi-stage intent verification in a secure isolation environment: The integrity verification unit verifies the MAC or signature of the intent encapsulation to determine if it has been tampered with; the anti-replay verification unit checks whether the timestamp window and random number have been used and whether the anti-replay counter is continuously valid; the caller identity verification unit verifies the matching of the UID, package name, Agent identifier, and session identifier; and the permission snapshot verification unit determines whether the current permission status is consistent with that at the time of submission based on the permission snapshot digest. In addition, the TA also performs context consistency verification and combined action risk verification to determine whether the user's current context matches the requested action and whether multiple action combinations constitute a high-risk path. During the verification process, the TA queries the security policy table, risk rule table, and historical authorization status maintained within the TEE to comprehensively derive security decisions such as allowing execution, denying execution, downgrading execution, requiring user confirmation, sandboxing execution, or delaying execution.

[0053] Fourth, after successful verification, the TEE's intent verification TA token issuing unit generates a Secure Execution Token uniquely bound to the intent encapsulation. This token includes at least the risk level, allowed action set, prohibited action set, scheduling priority category, resource scheduling policy, whether user confirmation is required, whether sandbox execution is required, network access restrictions, token expiration time, and anti-replay counter. It is signed or MAC protected by the TEE using a non-exportable hardware-bound key. Once this Secure Execution Token is returned to the normal execution environment, the normal execution environment can only read the policy fields and cannot forge or modify the token content.

[0054] Fifth, after receiving the secure execution token, the heterogeneous resource scheduling engine first verifies the token signature or MAC, determines whether the token has expired, whether it matches the current intent encapsulation digest, whether replay occurs, and checks whether the target action is within the allowed action set. After successful verification, the scheduling engine, combined with the real-time hardware status of the end-device acquired by the hardware status acquisition module, selects the target execution resource. Simultaneously, the scheduling engine executes the corresponding scheduling operation according to the resource scheduling policy in the secure execution token. For example, hardware status sources include: Android Thermal HAL, Power HAL, Performance HAL, devfreq node, sysfs node, PMU performance counters, vendor NPU / GPU Runtime, kernel scheduler statistics, cgroup resource statistics, or vendor power management interfaces.

[0055] Thus, through the binding mechanism between the intent encapsulation body and the security execution token, as well as the token-driven heterogeneous resource collaborative scheduling mechanism, a complete closed loop is formed from security verification to scheduling execution and then to feedback failure.

[0056] For details, please refer to the appendix. Figure 2 and appendix Figure 3 This embodiment first provides a program scheduling method with trusted intent verification on Android, including the following steps:

[0057] Step S1: Intercept the cross-application execution request of the AI ​​Agent, obtain the caller information, target application information, action type, data scope, current permission snapshot and user context summary, and encapsulate the obtained information into an intent encapsulation.

[0058] When the AI ​​Agent attempts to execute a cross-application task, the AgentSchedulerService, running at the Android framework layer or system service layer, intercepts the request. The AgentSchedulerService extracts the following information from the cross-application execution request: caller UID, caller package name, AI Agent identifier, user session identifier, target application package name, target component or target API, action type, data access scope, current permission snapshot, user context summary, and device basic state summary. Subsequently, the AgentSchedulerService normalizes the above information into an Intent Capsule and appends a timestamp and a random number to this capsule to ensure the timeliness and uniqueness of the request.

[0059] Please see the appendix Figure 4 In a preferred embodiment, the intent encapsulation includes an AI Agent identifier, a caller UID, a caller package name, a target application package name, a target component or target API, an action type, a data range, a user context summary, a permission snapshot summary, a session identifier, a timestamp, a random number, and an integrity check value.

[0060] In this embodiment, agent_id represents the AI ​​Agent identifier; caller_uid represents the caller's UID; caller_package represents the caller's package name; target_package represents the target application package name; target_component represents the target component or target API; action_type represents the action type, which can represent actions such as reading, writing, sending, deleting, paying, taking pictures, recording, uploading, sharing, or modifying settings; data_scope represents the data scope, which can represent data scopes such as SMS, contacts, albums, location, files, clipboard, accounts, network, or sensors; user_context_digest represents the user context digest, used to bind the user's current context, such as whether the user is operating in the foreground, whether they have just issued a voice command, or whether they are in a locked screen state; permission_snapshot_hash represents the permission snapshot digest, used to record the current permission status and prevent the permission status from being tampered with after verification; session_id represents the session identifier; timestamp represents the timestamp; nonce represents a one-time random number, and the timestamp and random number are used together to prevent old requests from being replayed; capsule_mac represents the integrity check value, used to verify whether the intent encapsulation has been tampered with.

[0061] If the request fields are incomplete, the target application does not exist, the action type is not within the supported range, or the parameter format is invalid, AgentSchedulerService can directly reject the request before entering the trusted execution environment.

[0062] In another implementation, capsule_version can be used to represent the intent package version number; payload_hash can be used to represent the original request payload digest; device_state_digest can be used to represent the device state digest; and risk_hint can be used to represent the initial risk hint given by the normal execution environment.

[0063] Step S2: Perform integrity protection and encoding processing on the intent package, establish a communication session with the trusted execution environment through a secure interface, and transmit the intent package to the trusted execution environment.

[0064] Specifically, AgentSchedulerService passes the intent package to the Native security bridging module via a Java native interface. The Native security bridging module performs binary encoding, digest calculation, and integrity protection on the intent package, and establishes a secure session with the TEE intent verification TA running in the Trusted Execution Environment through secure interfaces such as the TEE Client API, KeyMint HAL, or vendor-secure HAL.

[0065] During this process, the Native security bridging module does not directly obtain the plaintext hardware key. Instead, it requests the Trusted Execution Environment (TEE) to use a non-derivative hardware binding key to perform at least one of the following operations: calculate the Message Authentication Code (MAC) for the intent package; encrypt the intent package; sign the intent package digest; establish a session key with the TEE intent verification TA; and bind the timestamp, random number, and call context. Subsequently, the Native security bridging module passes the encrypted intent package, digest, timestamp, random number, and call context to the TEE intent verification TA.

[0066] Specifically, the Native security bridging module performs binary encoding, digest calculation, and integrity protection on the intent encapsulation, generating a nonce, timestamp, and session_id. It then requests the key service within the Android Keystore / KeyMint / TEE to complete encryption, signing, signature verification, or key derivation. The ciphertext, digest, random number, timestamp, and call context are passed to the TEE. Finally, the module receives a security execution token or rejection result returned by the TEE.

[0067] Step S3: Perform multi-stage intent verification on the intent package in the trusted execution environment. The multi-stage intent verification includes integrity verification, anti-replay verification, caller authentication, and permission snapshot verification.

[0068] The multi-stage intent verification also includes contextual consistency verification and combined action risk verification.

[0069] In context consistency verification, it is determined whether the user's current context matches the requested action. If the device is locked, the user has not initiated an explicit command, or the context summary is abnormal, the risk level is increased or the user is required to confirm.

[0070] In the combined action risk verification, it is determined whether the combination of multiple actions constitutes a high-risk path. The high-risk path includes at least one of the following: sending a network request after reading an SMS message, calling a third-party sharing interface after reading a contact, uploading a file after calling the camera in the background, batch compressing and sending photos after reading the album, launching an unknown application after modifying system settings, calling an untrusted network interface after obtaining location, and triggering a payment / transfer / login action after reading the clipboard.

[0071] For example, the TEE intent verification TA may include: an integrity verification unit, an anti-replay verification unit, a caller identity verification unit, a permission snapshot verification unit, an intent risk assessment unit, a combined action risk judgment unit, a security policy matching unit, and a security execution token issuance unit.

[0072] Specifically, multi-stage verification is performed within a secure, isolated area of ​​the Trusted Execution Environment (TEE). The first stage is integrity verification. The TEE Intent Verifier (TA) checks the message authentication code, signature, or digest of the intent encapsulation to determine if the intent encapsulation has been tampered with during transmission. If the integrity verification fails, the TA directly returns a rejection result.

[0073] The second phase involves timeliness and replay protection verification. The TA checks if the timestamp is within the allowed time window, if the nonce has been used, and if the replay counter is continuous or valid. If the timestamp has expired, the nonce has been used, or the counter is abnormal, the TA determines there is a risk of a replay attack and rejects the request.

[0074] The third stage is caller authentication. The AI ​​Agent verifies whether the caller_uid, caller_package, agent_id, and session_id match to determine if the AI ​​Agent is qualified to initiate the corresponding request.

[0075] The fourth stage is permission snapshot verification. The TA determines whether the current permission status is consistent with that at the time of submission based on the permission_snapshot_hash, and combines this with the security policy table maintained internally by the TA to determine whether the caller has the access qualifications for the corresponding action type and data range.

[0076] The fifth stage is context consistency verification. The Task Manager (TA) determines whether the user's current context matches the requested action. For example, if the user has not issued an explicit command, the device is locked, the target application is in the background, or the context summary is abnormal, the TA increases the risk level or requires user confirmation.

[0077] The sixth stage involves risk verification of combined actions. The Task Manager (TA) determines whether a combination of multiple actions constitutes a high-risk path. Examples include: immediately sending a network request after reading an SMS message; calling a third-party sharing interface after reading a contact's information; uploading files after accessing the camera in the background; performing batch compression and sending photos after reading the photo album; launching an unknown application after modifying system settings; calling an untrusted network interface after obtaining location information; and triggering payment, transfer, or login actions after reading the clipboard. If any of these high-risk combinations are detected, the TA will either increase the risk level or refuse to execute the action.

[0078] Phase 7, Security Decision Output. Based on the risk assessment results, the Task Manager (TA) outputs one of the following: Allow execution, issuing a secure execution token; Deny execution, returning a rejection code and a risk reason summary; Degrade execution, issuing a token after restricting the scope of actions, data, or resources; Require user confirmation, issuing a token with a user confirmation flag or returning a confirmation request; Sandbox execution, requiring the scheduling engine to restrict the task to an isolated environment; Delayed execution, requiring execution only after certain conditions are met, such as device temperature, load, or user status.

[0079] Step S4: After the trusted execution environment verification is passed, a secure execution token is issued. The secure execution token is bound to the intent encapsulation body. The secure execution token includes a risk level, a set of allowed actions, and a resource scheduling policy.

[0080] Specifically, if the TEE intent verification TA determination request is executable, a Secure Execution Token (SToken) is generated and bound to the intent encapsulation body. Please refer to the appendix again. Figure 4 In a preferred embodiment, the secure execution token further includes a token version number, a token number, a bound intent encapsulation summary, an AI Agent identifier, a caller UID, a target application package name, a set of prohibited actions, a scheduling priority category, whether secondary user confirmation is required, whether sandbox execution is required, network access restrictions, a token expiration time, and an anti-replay counter.

[0081] For example, `token_version` represents the token version number; `token_id` represents the token number; `intent_hash` represents the digest of the bound intent package, used to uniquely associate the token with a specific intent package; `agent_id` represents the AI ​​Agent identifier; `caller_uid` represents the caller's UID; `target_package` represents the target application package name; `risk_level` represents the risk level, calculated by the TA based on factors such as action type, data range, call context, historical authorization status, and combined action sequences; `allowed_action_set` represents the set of actions allowed to be executed; `denied_action_set` represents the set of actions prohibited to be executed; `resource_policy` represents the resource scheduling policy, including whether background execution is allowed, whether NPU is allowed, whether GPU is allowed, whether only low-power CPU cores are allowed to execute, whether waiting for a foreground task idle window is required, and whether... The options include: allowing network access, limiting memory bandwidth, delaying execution, requiring user confirmation before execution, and downgrading to read-only or sandbox mode. `priority_class` indicates the scheduling priority category; `require_user_confirm` indicates whether secondary user confirmation is required; `sandbox_required` indicates whether sandbox execution is required; `network_limit` indicates network access restrictions; `expire_time` indicates the token expiration time; `replay_counter` indicates the anti-replay counter; and `token_signature` indicates the TEE signature or message authentication code, generated by the TEE using a non-exportable hardware binding key. After the secure execution token is returned to the normal execution environment, the normal execution environment can only read some policy fields from the token and cannot forge or modify the token content. The scheduling engine must verify the token signature or MAC before execution.

[0082] The secure execution token is protected by the trusted execution environment using a non-derivative hardware binding key for signing or a message authentication code.

[0083] Step S5: Verify the validity of the security execution token in a normal execution environment. If the verification passes, determine the target execution resource based on the risk level and resource scheduling policy in the security execution token, as well as the real-time hardware status of the end device, and schedule the corresponding AI Agent subtask to the target execution resource for execution.

[0084] Please see the appendix Figure 5 The method for verifying the validity of the security execution token in a normal execution environment includes:

[0085] Verify the signature or message authentication code of the security execution token;

[0086] Determine whether the security execution token has expired;

[0087] Determine whether the security execution token matches the current intent encapsulation digest;

[0088] Determine whether the security execution token has been used or whether a replay has occurred;

[0089] Determine whether the target action is in the set of allowed actions;

[0090] Determine whether secondary confirmation from the user is required;

[0091] Determine whether sandbox execution or network restrictions are required;

[0092] If any check fails, execution will be refused.

[0093] Specifically, in a normal execution environment, the heterogeneous resource scheduling engine receives and verifies the security execution token.

[0094] First, the token signature or MAC address is verified to confirm that the token was legally issued by the TEE. Next, it is checked whether the token has expired. Then, the token is checked to see if it matches the current intent encapsulation digest. Finally, it is checked whether the token has been used or if a replay has occurred. The target action is checked if it is in the allowed_action_set. If secondary user confirmation is required, it is determined whether sandbox execution or network restrictions are necessary. If any verification fails, the scheduling engine refuses to execute the task and returns the result to the AgentSchedulerService.

[0095] If the token is valid, the scheduling engine will break down the AI ​​Agent task into one or more of the following sub-tasks: lightweight preprocessing task, model inference task, file or database access task, network access task, target application invocation task, UI-related task, post-processing task, and security audit task.

[0096] The real-time hardware status includes:

[0097] CPU temperature, frequency, utilization, and run queue length.

[0098] GPU temperature, frequency, utilization, and rendering queue status.

[0099] NPU temperature, frequency, utilization, and inference queue length.

[0100] In addition, at least one of the following: memory bandwidth usage, system bus load, foreground application frame deadline, battery level and power consumption mode, system thermal limit status, device operating mode, number and priority of background tasks.

[0101] Methods for determining target execution resources include:

[0102] Calculate scheduling scores for at least two available execution resources from CPU, GPU, NPU, DSP, and delayed execution queue, and select the target execution resource based on the scheduling scores;

[0103] The scheduling score is calculated based on at least one of the following: available computing power, temperature pressure, memory bandwidth usage pressure, foreground application frame deadline risk, scheduling priority carried by the security execution token, risk level penalty items, and queue waiting time.

[0104] For example, a preferred scoring model is as follows:

[0105] Score(resource) =

[0106] α×AvailableCompute(resource)

[0107] -β×ThermalPressure(resource)

[0108] -γ×MemoryBandwidthPressure

[0109] -δ×ForegroundDeadlineRisk

[0110] +ε×TokenPriority

[0111] -ζ×RiskPenalty

[0112] -η×QueueDelay(resource).

[0113] Where: AvailableCompute(resource) represents the available computing power of the resource; ThermalPressure(resource) represents the temperature pressure corresponding to the resource; MemoryBandwidthPressure represents the memory bandwidth usage pressure; ForegroundDeadlineRisk represents the risk affecting the frame rate or response of the foreground application; TokenPriority represents the scheduling priority carried in the security execution token; RiskPenalty represents the penalty item brought by the risk level; QueueDelay(resource) represents the queue waiting time of the corresponding resource; α, β, γ, δ, ε, ζ, and η are configurable weights.

[0114] For example, when the AI ​​Agent requests to execute a local model inference task, the TEE intends to verify that the TA determines the task to be low-risk based on the action type and data range, and issues a secure execution token containing a low-risk level and permission to use the NPU policy. After the scheduling engine verifies the token's validity, it obtains the current hardware status: if the NPU temperature is below the first temperature threshold (45°C in the example), the NPU queue length is less than the first queue threshold (5 tasks in the example), and the memory bandwidth usage is less than the first bandwidth threshold (70% in the example), then the scheduling engine submits the inference subtask to the NPU for execution; if the NPU temperature exceeds the second temperature threshold (85°C in the example) or the system is in a thermally limited state, then the scheduling engine transfers the inference subtask to a low-power CPU core for execution, while reducing the number of concurrent subtasks from 4 to 1, and resumes NPU scheduling after the temperature drops back to a safe range.

[0115] On the other hand, in another implementation, the resource scheduling strategy includes at least one of the following:

[0116] If the security execution token indicates low risk and there is an available idle time window for the foreground application frame deadline, then the AI ​​Agent subtask is split and inserted into the idle window of the CPU, GPU, or NPU for execution.

[0117] If the NPU temperature is lower than the first temperature threshold, the NPU queue length is lower than the first queue threshold, and the memory bandwidth pressure is lower than the first bandwidth threshold, then the model inference subtask will be submitted to the NPU for execution.

[0118] If the foreground application is in a high real-time scenario and the GPU or memory bandwidth pressure is higher than the threshold, then reduce the priority of the background AIAgent task, split the task into smaller sub-tasks or postpone it to the next free window for execution.

[0119] If the system is under thermal limitation or the temperature of any critical hardware exceeds the second temperature threshold, then at least one of the following will be executed: reduce the number of concurrent subtasks, transfer tasks from the NPU / GPU to low-power CPU cores, extend the task execution interval, suspend non-critical background tasks, limit memory bandwidth intensive tasks, or wait for the temperature to drop before continuing execution.

[0120] If the security execution token indicates that user confirmation is required, then the task execution is paused and the user confirmation process is triggered;

[0121] If the security execution token indicates that sandbox execution is required, the task will be restricted to run in the sandbox environment, including prohibiting network access, prohibiting writing to external storage, prohibiting access to non-essential application components, allowing only reading of de-identified data, allowing only the return of summary results, or limiting at least one of the following:

[0122] If the security execution token indicates a security-critical task, then the scheduling level of that task is increased.

[0123] Specifically, in one implementation, if the security execution token indicates low risk and there is an available idle time window for the foreground application frame deadline, the scheduling engine splits the AI ​​Agent subtask and inserts it into the idle window of the CPU, GPU, or NPU for execution. This mechanism is suitable for lightweight tasks such as text summarization preprocessing, embedding calculation, short text classification, lightweight local retrieval, parameter validation, and format conversion.

[0124] In one implementation, if the foreground application is in a high real-time scenario such as gaming, camera, video conferencing, or navigation, and the GPU or memory bandwidth pressure is higher than the threshold, the scheduling engine reduces the priority of the background AI Agent task, splits the task into smaller sub-tasks, or postpones the execution to the next free window to avoid affecting the smoothness of the foreground application.

[0125] In one implementation, if the require_user_confirm field in the security execution token is true, the scheduling engine suspends task execution and notifies the AgentSchedulerService to trigger a user confirmation process. For example, when an AI Agent requests to read the clipboard and triggers a payment action, the TEE intends to verify that the TA recognizes that this combination of actions is high-risk, issues a token with a user confirmation flag, the scheduling engine suspends execution and pops up a user confirmation interface, and only resumes execution after the user confirms.

[0126] In one implementation, if the sandbox_required field in the security execution token is true, the scheduling engine restricts the task to run in a sandbox environment or a restricted execution environment, including prohibiting network access, prohibiting writing to external storage, prohibiting access to non-essential application components, allowing only reading of de-identified data, allowing only the return of summary results, or limiting runtime and resource usage.

[0127] In one implementation, if the security execution token indicates a security-critical task, such as fraud detection, emergency privacy protection, malicious operation blocking, or system security alarm, the scheduling engine increases the scheduling level of the task, including setting a higher system service priority, allocating a higher cgroup or task profile, increasing the NPU / GPU submission priority, reducing the resource quota for non-critical background tasks, or reserving a short execution window for security-critical tasks.

[0128] After the task is completed, the scheduling engine will send the execution results back to AgentSchedulerService and TEE Intent Verification (TA). The feedback includes the actual execution resources, execution latency, temperature changes, queue waiting time, whether degradation was triggered, whether user cancellation occurred, whether permission changes occurred, whether tokens expired, and whether abnormal termination occurred.

[0129] A secure execution token expires under the following circumstances: the expire_time period expires; the user revokes authorization; the target application's permission status changes; the target application version changes; a nonce or replay_counter is detected; the current intent digest does not match the token binding digest; the device enters a high-risk security state; or the TEE policy table is updated and the original token is deemed insecure. After the token expires, the AI ​​Agent must resubmit the intent encapsulation and request the TEE to re-verify it.

[0130] In the following abnormal situations, follow these steps.

[0131] (1) TEE verification failure: If the TEE determines that the intent encapsulation has been tampered with, the permissions do not match, the context is abnormal, the combined action is high-risk, or there is a replay attack, it will return a rejection code. After receiving the rejection code, AgentSchedulerService will block the cross-application execution request and may report the risk summary to the user or the system security center.

[0132] (2) Token verification failure: If the scheduling engine cannot pass the token signature verification, or finds that the token has expired or does not match the current intent, it will refuse to execute the task.

[0133] (3) The device is in a high temperature state: If the device temperature exceeds the preset threshold, the scheduling engine will downgrade, split, delay or transfer the AI ​​Agent task to a low-power resource for execution.

[0134] (4) User context inconsistency: If the user’s current context is inconsistent with the Agent’s request, such as the device is locked, the user is not authorized, or the user is performing a sensitive operation, the system will pause execution and require the user to confirm.

[0135] (5) Changes in the permissions of the target application: If the permission status of the target application or the caller changes after the token is issued, the system immediately invalidates the token and requires re-verification.

[0136] On the other hand, this embodiment provides an Android application scheduling system with trusted intent verification. Please refer to the appendix. Figure 6 ,include:

[0137] The acquisition module 100 intercepts cross-application execution requests from the AI ​​Agent, obtains caller information, target application information, action type, data scope, current permission snapshot, and user context summary, and encapsulates the acquired information into an intent encapsulation body.

[0138] The encapsulation module 200 performs integrity protection and encoding processing on the intent encapsulation body, establishes a communication session with the trusted execution environment through a secure interface, and transmits the intent encapsulation body to the trusted execution environment;

[0139] The verification module 300 performs multi-stage intent verification on the intent package in the trusted execution environment. The multi-stage intent verification includes integrity verification, anti-replay verification, caller authentication, and permission snapshot verification.

[0140] The issuance module 400 issues a security execution token after the trusted execution environment verification is passed. The security execution token is bound to the intent encapsulation body and includes a risk level, a set of allowed actions, and a resource scheduling policy.

[0141] The execution module 500 verifies the validity of the security execution token in a normal execution environment. If the verification passes, it determines the target execution resource based on the risk level and resource scheduling strategy in the security execution token, as well as the real-time hardware status of the end device, and schedules the corresponding AI Agent subtask to the target execution resource for execution.

[0142] Please see Figure 7 The diagram shown is a structural schematic of an electronic device provided in an embodiment of this specification.

[0143] like Figure 7As shown, the electronic device 1100 may include: at least one processor 1101, at least one network interface 1104, a user interface 1103, a memory 1105, and at least one communication bus 1102. The communication bus 1102 can be used to connect and communicate with the various components mentioned above. The user interface 1103 may include buttons, and optionally may include standard wired or wireless interfaces. The network interface 1104 may include, but is not limited to, a Bluetooth module, an NFC module, or a Wi-Fi module. The processor 1101 may include one or more processing cores. The processor 1101 connects to various parts within the electronic device 1100 using various interfaces and lines, and performs various functions of the routing device and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 1105, and by calling data stored in the memory 1105. Optionally, the processor 1101 may be implemented using at least one hardware form of DSP, FPGA, or PLA. The processor 1101 may integrate one or more combinations of CPU, GPU, and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content that the display screen needs to show; and the modem is used for wireless communication.

[0144] It is understandable that the aforementioned modem may not be integrated into the processor 1101, but may be implemented using a separate chip.

[0145] The memory 1105 may include RAM or ROM. Optionally, the memory 1105 may include a non-transitory computer-readable medium. The memory 1105 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 1105 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 1105 may also be at least one storage device located remotely from the aforementioned processor 1101. As a computer storage medium, the memory 1105 may include an operating system, a network communication module, a user interface module, and application programs. The processor 1101 may be used to call the application programs stored in the memory 1105 and execute the methods in the above-described embodiments.

[0146] This specification also provides a computer-readable storage medium storing instructions that, when executed on a computer or processor, cause the computer or processor to perform multiple steps as described in the above embodiments. If the constituent modules of the above-described electronic device are implemented as software functional units and sold or used as independent products, they can be stored in the computer-readable storage medium.

[0147] This specification also provides a computer program product, including a computer program that, when executed by a processor, implements the multiple steps described in the above embodiments.

[0148] Where there is no conflict, the technical features in this embodiment and implementation scheme can be combined arbitrarily.

[0149] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes multiple computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this specification are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted through the computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center integrating multiple available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital versatile discs (DVDs)), or semiconductor media (e.g., solid-state drives (SSDs)).

[0150] When implemented through hardware or firmware, the aforementioned method flow is programmed into the hardware circuit to obtain the corresponding hardware circuit structure and achieve the corresponding function. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit, whose logic function is determined by the user programming the device. Designers can program a digital system onto a PLD themselves, eliminating the need for chip manufacturers to design and fabricate dedicated integrated circuit chips. Furthermore, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly implemented using "logic compiler" software, similar to the software compiler used in program development. The original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There is not just one HDL, but many. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of the aforementioned hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0151] The embodiments described above are merely preferred embodiments of this specification and are not intended to limit the scope of this specification. Any modifications and improvements made by those skilled in the art to the technical solutions of this specification without departing from the spirit of this specification should fall within the protection scope defined by the claims of this specification.

Claims

1. A program scheduling method with trusted intent verification on Android, characterized in that, Including the following steps: Step S1: Intercept the cross-application execution request of the AI ​​Agent, obtain the caller information, target application information, action type, data scope, current permission snapshot and user context summary, and encapsulate the obtained information into an intent encapsulation body; Step S2: Perform integrity protection and encoding processing on the intent package, establish a communication session with the trusted execution environment through a secure interface, and transmit the intent package to the trusted execution environment; Step S3: Perform multi-stage intent verification on the intent package in the trusted execution environment. The multi-stage intent verification includes integrity verification, anti-replay verification, caller authentication, and permission snapshot verification. Step S4: After the trusted execution environment verification is passed, a security execution token is issued. The security execution token is bound to the intent encapsulation body. The security execution token includes a risk level, a set of allowed actions, and a resource scheduling policy. Step S5: Verify the validity of the security execution token in a normal execution environment. If the verification passes, determine the target execution resource based on the risk level and resource scheduling policy in the security execution token, as well as the real-time hardware status of the end device, and schedule the corresponding AI Agent subtask to the target execution resource for execution.

2. The Android-based program scheduling method with trusted intent verification according to claim 1, characterized in that, The intent encapsulation includes the AI ​​Agent identifier, caller UID, caller package name, target application package name, target component or target API, action type, data range, user context summary, permission snapshot summary, session identifier, timestamp, random number, and integrity verification value.

3. The Android-based program scheduling method with trusted intent verification according to claim 1, characterized in that, The multi-stage intent verification also includes contextual consistency verification and combined action risk verification. In context consistency verification, it is determined whether the user's current context matches the requested action. If the device is locked, the user has not initiated an explicit command, or the context summary is abnormal, the risk level is increased or the user is required to confirm. In the combined action risk verification, it is determined whether the combination of multiple actions constitutes a high-risk path. The high-risk path includes at least one of the following: sending a network request after reading an SMS message, calling a third-party sharing interface after reading a contact, uploading a file after calling the camera in the background, batch compressing and sending photos after reading the album, launching an unknown application after modifying system settings, calling an untrusted network interface after obtaining location, and triggering a payment / transfer / login action after reading the clipboard.

4. The Android-based program scheduling method with trusted intent verification according to claim 1, characterized in that, The secure execution token also includes a token version number, token number, bound intent encapsulation summary, AI Agent identifier, caller UID, target application package name, prohibited action set, scheduling priority category, whether secondary user confirmation is required, whether sandbox execution is required, network access restrictions, token expiration time, and anti-replay counter. The secure execution token is protected by the trusted execution environment using a non-derivative hardware binding key for signing or a message authentication code.

5. The Android-based program scheduling method with trusted intent verification according to claim 1, characterized in that, Methods for verifying the validity of the security execution token in a normal execution environment include: Verify the signature or message authentication code of the security execution token; Determine whether the security execution token has expired; Determine whether the security execution token matches the current intent encapsulation digest; Determine whether the security execution token has been used or whether a replay has occurred; Determine whether the target action is in the set of allowed actions; Determine whether secondary confirmation from the user is required; Determine whether sandbox execution or network restrictions are required; If any check fails, execution will be refused.

6. The Android-based program scheduling method with trusted intent verification according to claim 1, characterized in that, The real-time hardware status includes: CPU temperature, frequency, utilization, and run queue length. GPU temperature, frequency, utilization, and rendering queue status. NPU temperature, frequency, utilization, and inference queue length. In addition, at least one of the following: memory bandwidth usage, system bus load, foreground application frame deadline, battery level and power consumption mode, system thermal limit status, device operating mode, number and priority of background tasks; Methods for determining target execution resources include: Calculate scheduling scores for at least two available execution resources from CPU, GPU, NPU, DSP, and delayed execution queue, and select the target execution resource based on the scheduling scores; The scheduling score is calculated based on at least one of the following: available computing power, temperature pressure, memory bandwidth usage pressure, foreground application frame deadline risk, scheduling priority carried by the security execution token, risk level penalty items, and queue waiting time.

7. The Android-based program scheduling method with trusted intent verification according to claim 1, characterized in that, The resource scheduling strategy includes at least one of the following: If the security execution token indicates low risk and there is an available idle time window for the foreground application frame deadline, then the AI ​​Agent subtask is split and inserted into the idle window of the CPU, GPU, or NPU for execution. If the NPU temperature is lower than the first temperature threshold, the NPU queue length is lower than the first queue threshold, and the memory bandwidth pressure is lower than the first bandwidth threshold, then the model inference subtask will be submitted to the NPU for execution. If the foreground application is in a high real-time scenario and the GPU or memory bandwidth pressure is higher than the threshold, then reduce the priority of the background AI Agent task, break the task into smaller sub-tasks or postpone it to the next free window for execution. If the system is under thermal limitation or the temperature of any critical hardware exceeds the second temperature threshold, then at least one of the following will be executed: reduce the number of concurrent subtasks, transfer tasks from the NPU / GPU to low-power CPU cores, extend the task execution interval, suspend non-critical background tasks, limit memory bandwidth intensive tasks, or wait for the temperature to drop before continuing execution. If the security execution token indicates that user confirmation is required, then the task execution is paused and the user confirmation process is triggered; If the security execution token indicates that sandbox execution is required, the task will be restricted to run in the sandbox environment, including prohibiting network access, prohibiting writing to external storage, prohibiting access to non-essential application components, allowing only reading of de-identified data, allowing only the return of summary results, or limiting at least one of the following: If the security execution token indicates a security-critical task, then the scheduling level of that task is increased.

8. An Android application scheduling system with trusted intent verification, characterized in that: include: The acquisition module intercepts cross-application execution requests from the AI ​​Agent, obtains caller information, target application information, action type, data scope, current permission snapshot, and user context summary, and encapsulates the acquired information into an intent encapsulation. The encapsulation module performs integrity protection and encoding processing on the intent encapsulation body, establishes a communication session with the trusted execution environment through a secure interface, and transmits the intent encapsulation body to the trusted execution environment; The verification module performs multi-stage intent verification on the intent encapsulation in the trusted execution environment. The multi-stage intent verification includes integrity verification, anti-replay verification, caller authentication, and permission snapshot verification. The issuance module issues a security execution token after the trusted execution environment verification is passed. The security execution token is bound to the intent encapsulation body and includes a risk level, a set of allowed actions, and a resource scheduling policy. The execution module verifies the validity of the security execution token in a normal execution environment. If the verification passes, it determines the target execution resource based on the risk level and resource scheduling policy in the security execution token, as well as the real-time hardware status of the edge device, and schedules the corresponding AI Agent subtask to the target execution resource for execution.

9. An electronic device, characterized in that, Including the processor and memory; The processor is connected to the memory; The memory is used to store executable program code; The processor runs a program corresponding to the executable program code stored in the memory to perform the method as described in any one of claims 1-7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-7.

Images