Dynamic execution method of Android and MicroAndroid, Android host, Android client, computer readable storage medium and system

By establishing a data transmission channel between the Android host and the Microdroid payload, dynamic transmission and loading of business information and shared libraries are achieved, solving the problem of persistent data invalidation caused by virtual machine key changes, and improving program running efficiency and system stability.

CN121579128APending Publication Date: 2026-02-27FUJIAN WISBO DIGITAL TECHNOLOGY CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202511621522.8
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-11-07
Publication Date
2026-02-27

AI Technical Summary

Technical Problem

In the Android virtualization framework, changes to the application's virtual machine key can cause persistent data to become invalid.

Method used

By establishing a data transmission channel between the Android host and the Microdroid payload, dynamic transmission of business information and dynamic loading of shared libraries are achieved, avoiding changes to the payload code and ensuring that the virtual machine key remains unchanged.

Benefits of technology

It improves program execution efficiency, avoids problems such as virtual machine key changes and the invalidation of old persistent data, and enhances system stability and efficiency.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121579128A_ABST
    Figure CN121579128A_ABST
Patent Text Reader

Abstract

The invention discloses a dynamic execution method for Android and MicroAndroid, an Android host, an Android client, a computer readable storage medium and a system. The dynamic execution method comprises the following steps: establishing a data transmission channel for communication with a payload Payload of the MicroAndroid; target service information to be executed, which is stored in the Android, is sent to the Payload; target business data forwarded by the Payload are received, the target business data are obtained by calling a business execution program to load and run a corresponding target business shared library by the Payload based on the target business information, and a dynamic shared library stored in the Android is transmitted to the MicroAndroid for dynamic loading execution, so that data interaction between the effective load Payload and the Android host is realized, and data interaction between the Payload and the Android host is realized. In this way, the payload Payload is separated from the specific service content, updating or changing of the specific service content cannot cause changing of the payload Payload code, the problems that a virtual machine secret key is changed and old persistent data loses efficacy cannot be caused, and the program running efficiency is greatly improved in the AVF implementation process.
Need to check novelty before this filing date? Find Prior Art

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of Android virtualization framework, and particularly relates to a dynamic execution method of Android and Microdroid, an Android host, an Android guest, a computer readable storage medium and a system. BACKGROUND

[0002] Android Virtualization Framework (AVF) can provide a secure and private execution environment to execute code. AVF is very suitable for security-oriented use cases that require higher security than the security provided by the Android application sandbox, or even formally verified isolation guarantees. A pVM is a mutually distrustful isolated execution environment (guest) that runs alongside the main Android operating system (host). Microdroid is a mini version of the Android OS that runs in the pVM, which provides an isolated execution environment to run a part of an application with higher confidentiality and integrity than the regular Android environment.

[0003] In a traditional operating system, a lot of work (and usually repetitive work) must be done to provide strong confidentiality and integrity protection. This is because the traditional operating system cannot be well compatible with the overall Android architecture. For example, for the standard Android architecture, the developer needs to implement a method to securely load and execute a part of the application in the pVM, and also needs to build the payload according to glibc. However, the Android application needs to use Bionic, the communication needs to use a custom protocol based on vsock, and the debugging needs to use adb and is quite difficult.

[0004] Microdroid can easily bridge these differences. It provides a well-designed ready-to-use operating system image, allowing the developer to offload a part of the application to the pVM in the most labor-saving way. The native code of Microdroid is based on Bionic, and the communication is implemented through Binder. It supports importing APEX from the host Android, and exposes a part of the Android API, such as the key store needed when using hardware-supported keys for encryption operations. In summary, Microdroid provides a familiar environment for the developer, which contains various tools in the full version of the Android OS that they are already familiar with.

[0005] The application implemented based on AVF contains two parts: the application part running on the host Android OS, and the application part running on the Microdroid inside the pVM, which is loaded by the Payload process of the Microdroid in the form of native shared library. The application part running on the Android implements the interface, non-confidential business logic, and creates and manages the lifecycle of the pVM. The native shared library running on the Microdroid inside the pVM is responsible for executing any tasks that need to be executed securely.

[0006] In order to start the pVM part of the application and communicate with it, the host part of the application creates a pVM and runs the Microdroid inside the pVM, the zipfuse (FUSE file system of the Microdroid) installs the application (i.e. APK, basically a Zip file) as a file system, and then loads and runs the native shared library of the application. This library creates a Binder service object and RpcServer and registers the Binder service object as the root object of the RpcServer, and then starts listening for connections from the host part of the application. The host part of the application creates an RpcSession to connect to the RpcServer of the native shared library and gets the root object to get the Binder service object, so that the host part of the application can communicate with the native shared library running inside the pVM through Binder. Figure 1 shows the two parts of the application and the Binder communication channel.

[0007] In AVF, each virtual machine (VM) has a 32-byte unique key (called virtual machine identity) that is not exposed to the host and is usually kept unchanged in the following situations: the same VM is stopped and restarted. It is usually kept unchanged even after a system restart. The key in Android 14 is dynamically generated by the following elements: 1. a device-specific random value; 2. the complete system image; 3. a salt value for each instance; 4. the code running in the VM, including the bootloader, kernel, Microdroid, and Payload; 5. key VM configuration options, such as whether the VM is enabled for debug mode. Any modification of the above elements (such as code changes, configuration adjustments) will generate a completely new key, and attempting to start an old VM instance that does not generate the same key will directly fail.

[0008] To improve program efficiency, it's typically desirable for the payload running on Microdroid to persistently store data, such as runtime status, keys, or business-related data. This allows for direct loading upon VM restart without regeneration. The persistent data stored in the VM is encrypted and protected by the VM's key. However, according to the VM identity and key generation mechanism, when the code running in the VM (including the bootloader, kernel, Microdroid, and payload) is updated, the key generated for the VM instance—that is, the VM identity—changes, rendering the old VM instance unusable. The bootloader, kernel, and Microdroid are the basic firmware or system components of the VM, and their code is less likely to change. The payload, however, is a native shared library running AVF applications, involving specific business logic, and its code can change depending on the business requirements. Therefore, the original VM will become unusable, and its encrypted persistent data will also become unusable. Summary of the Invention

[0009] The technical problem to be solved by the present invention is to provide a dynamic execution method for Android and Microdroid, an Android host, an Android client, a computer-readable storage medium and system, which can avoid the problem of virtual machine key changes and old persistent data invalidation caused by the runtime of AVF-based applications.

[0010] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: A dynamic execution method for Android and Microdroid, comprising: Establish a data transmission channel for communication with the Microdroid payload; Send the target business information to be executed, stored in Android, to the payload; The payload receives target service data forwarded by the payload. The target service data is obtained by the payload calling the service execution program to load and run the corresponding target service shared library based on the target service information.

[0011] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: A dynamic execution method for Android and Microdroid, comprising: Establish a data transmission channel for communication with the Android host; Receive the target service information to be executed sent by the Android host; Based on the target business information, the Microdroid business execution program is invoked to load and run the corresponding target business shared library, a communication connection is established with the business execution program, and the business data obtained by the business execution program is forwarded to the Android host.

[0012] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: A dynamic execution method for Android and Microdroid, comprising: The Android host establishes a data transmission channel for communication with the Microdroid's payload. The payload receives the target service information to be executed sent by the Android host; The payload calls the Microdroid business execution program based on the target business information to load and run the corresponding target business shared library, establishes a communication connection with the business execution program, and forwards the business data obtained by the business execution program to the Android host.

[0013] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: An Android host includes a first memory, a first processor, and a first computer program stored in the first memory and executable on the first processor. When the first processor executes the first computer program, it implements the steps of the above-described dynamic execution method for Android and Microdroid.

[0014] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: An Android client includes a payload, the payload including a second memory, a second processor, and a second computer program stored on the second memory and executable on the second processor, wherein the second processor executes the second computer program to implement the steps of the above-described dynamic execution method for Android and Microdroid.

[0015] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: A computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the steps of the above-described dynamic execution method for Android and Microdroid.

[0016] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: A dynamic execution system for Android and Microdroid is disclosed. The system includes an Android host and an Android client. The Android host includes a first memory, a first processor, and a first computer program stored in the first memory and executable on the first processor. The Android client includes a payload. The payload includes a second memory, a second processor, and a second computer program stored in the second memory and executable on the second processor. When the first processor executes the first computer program, it implements the steps of the Android host implementing a dynamic execution method for Android and Microdroid. When the second processor executes the second computer program, it implements the steps of the Android client implementing a dynamic execution method for Android and Microdroid.

[0017] The beneficial effects of this invention are as follows: In the implementation of AVF applications, the payload and shared libraries in Microdroid are separated. The payload acts as a data relay station, establishing communication connections with both the Android host and the business execution program in Microdroid. Based on the target business information sent by the Android host, the payload calls the business execution program to load and run the corresponding target business shared library, and forwards the business data obtained by the business execution program to the Android host. The dynamic shared library stored in Android is transmitted to Microdroid for dynamic loading and execution, thereby realizing data interaction between the payload and the Android host. This decouples the payload from the specific business content, and updates or changes to the specific business content do not lead to changes in the payload code. Consequently, problems such as virtual machine key changes and the invalidation of old persistent data are avoided, greatly improving the efficiency of program execution during AVF implementation. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of the structure of AVF application loading and communication in the prior art; Figure 2 This is a flowchart illustrating the steps of a dynamic execution method for Android and Microdroid implemented from the perspective of an Android host, according to an embodiment of the present invention. Figure 3 This is a detailed flowchart illustrating the steps of the dynamic execution method for Android and Microdroid according to an embodiment of the present invention. Figure 4 This is a detailed flowchart illustrating another implementation method for dynamic execution of Android and Microdroid according to an embodiment of the present invention. Figure 5 This is a system architecture diagram illustrating the implementation of the dynamic execution method for Android and Microdroid according to an embodiment of the present invention. Figure 6 This is a flowchart illustrating the steps of a dynamic execution method between Android and Microdroid implemented from the perspective of an Android client, according to an embodiment of the present invention. Figure 7 This is a flowchart illustrating the steps of a dynamic execution method for Android and Microdroid implemented from the perspective of a system consisting of an Android host and an Android client, according to an embodiment of the present invention. Figure 8 This is a schematic diagram of the structure of an Android host according to an embodiment of the present invention; Figure 9 This is a schematic diagram of the structure of an Android client according to an embodiment of the present invention; Figure 10 This is a schematic diagram of the structure of a dynamic execution system for Android and Microdroid according to an embodiment of the present invention. Detailed Implementation

[0019] To explain in detail the technical content, objectives, and effects of the present invention, the following description is provided in conjunction with the embodiments and accompanying drawings.

[0020] The above-described dynamic execution method for Android and Microdroid, Android host, Android client, computer-readable storage medium, and system are applicable to scenarios where native shared libraries of AVF applications run via payload in AVF implementations. The following detailed embodiments illustrate these methods: In one alternative implementation, such as Figure 2 As shown, a dynamic execution method for Android and Microdroid is described in this embodiment from the perspective of the Android host, specifically including: Establish a data transmission channel for communication with the Microdroid payload; Specifically, the Android host establishes a vsock connection with the payload: The Android host application starts the pVM and sets up the callback interface; After starting pVM, the payload creates a vsock listening socket with the set port number, enters the state of listening for connections, and then notifies the Android host through a callback. After receiving the notification through the callback interface, the Android host connects to the pVM payload via the set port and the vsock socket. pVM can accept connections from Android applications, and only the Android application that launched pVM can connect to it, but it cannot launch connections to other pVMs or other processes in the host Android. The main interface for Android applications to communicate with pVM is vsock, which is a standard Virtio socket interface. Each virtual machine has a 32-bit context identifier (CID) (similar to an IP address). When the host establishes a vsock connection with pVM, it needs to specify this identifier. Only Android applications signed with the platform key can obtain the permission to create, own, or interact with pVM, thus ensuring that the established vsock connection does not compromise the isolation and security of pVM.

[0021] Send the target business information to be executed, stored in Android, to the payload; The payload receives target service data forwarded by the payload. The target service data is obtained by the payload calling the service execution program to load and run the corresponding target service shared library based on the target service information.

[0022] To send the target business information to be executed, stored in Android, to the payload, there are two methods: The first method involves sending the target business data to Microdroid every time the Android AVF application starts and runs. The target business information includes the shared library and its signature file. The business execution program loads and runs the target business shared library after successfully verifying the shared library and its signature file.

[0023] In specific implementation, such as Figure 3 As shown: When an AVF application is initialized, a pVM is created to run Microdroid, and then the native shared library of the AVF application is loaded and run. Specifically, the shared library is loaded and run by the Microdroid Payload process. After the payload is initialized, it notifies the host part of the AVF application. The host part and the payload establish a connection based on vsock (VM Socket, a socket for virtualization environment, used for communication between virtual machines) to establish a data transmission channel for communication between them. The host portion of the AVF application locates the business modules that need to be dynamically executed (including executable shared libraries and signature files for the shared libraries) in a specific path on Android, and then sends the file information and file data to the payload. The payload stores the executable shared library and signature file of the target business module in a specific path of Microdroid, and then calls the business execution program and specifies the path of the target business module's shared library and signature file. The business execution program verifies the target business module's shared library and signature file. If the verification is successful, the target business module's shared library is loaded and run. If the verification fails, the execution program exits. After the target business module's shared library is successfully loaded and run, it establishes a vsock connection with Payload. Through Payload's data forwarding, data interaction between the AVF application host and the business module can be realized, thereby enabling specific business processing.

[0024] The second implementation method is to save the business module file in the persistent path of Microdroid's encrypted storage, which is available the next time the VM is run. Therefore, it is not necessary to send the business module file to Microdroid every time the Android AVF application is launched. The business module file only needs to be sent to Microdroid in the following cases: the business module is running for the first time; the business module is updated and the version is higher or the VM is updated. Compared with the first implementation method, it has higher execution efficiency. In a specific implementation, sending the target business information to be executed stored in Android to the payload includes: Locate the target business information to be executed stored in Android, read its version information, and send the version information to the payload; The payload receives a target service information sending request from the payload. The payload persistently stores executable target service information. The target service information sending request is sent by the payload if it determines, based on the version information, that the version of the target service to be executed is greater than the version of the target service persistently stored by the payload, or if the payload does not persistently store the target service to be executed. Send the target service information to be executed to the payload; After sending the version information to the Payload, the Payload receives the target service data forwarded by the Payload. The target service data is obtained by the Payload calling the service execution program to load and run the corresponding target service shared library when the Payload determines that the version of the target service to be executed is not lower than the version of the target service persistently stored by the Payload based on the version information. Figure 4 The following is a flowchart illustrating the specific steps of this implementation: (1) When Microdroid’s payload is initialized and run, it reads the dynamically executed business modules (including executable shared libraries and signature files for shared libraries) from the persistent path / mnt / encryptedstore (the data under this path is encrypted and will be persisted and available when the VM is run again). (2) The payload verifies the target business module's shared library and signature file. After verification, it saves the target business module's version information and executable shared library path in the ModuleMap (saves them in the payload's memory with a mapping relationship of [business module name, module version and shared library path]). (3) After the host part of the Android AVF application establishes a connection with the payload, it searches for dynamically executed business modules (including executable shared libraries and their signature files) in a specific path of Android and reads the version information. Then, it processes them according to the following situations: a. When the Payload's ModuleMap contains a target business module and its version is not lower than the version of the target business module read by the Android side, it is not necessary to send the target business module file to the Payload; continue to execute step (4), wherein the host part of the Android AVF can make a judgment by requesting the Payload to obtain the ModuleMap information, or the host part of the Android AVF can send the version information to the Payload, and the Payload will make a judgment based on the received version information; b. When the Payload's ModuleMap contains a target business module and its version is lower than the version of the target business module read by the Android side, or when the ModuleMap does not contain a target business module, the host part of the AVF application sends the target business module file to the Payload; the Payload verifies the target business module's shared library and signature file, and after successful verification, saves the target business module file to the persistent path / mnt / encryptedstore in encrypted storage, and saves the version information of the target business module and the executable shared library path in the ModuleMap; (4) The payload calls the business execution program and specifies the executable shared library path in the ModuleMap; (5) After the business execution program successfully loads and runs the target business module shared library, it establishes a vsock connection with Payload. Through Payload's data forwarding, data interaction between the AVF application host and the business module can be realized. Figure 5 The diagram shown is the system architecture diagram corresponding to the above implementation method.

[0025] In another alternative implementation, such as Figure 6 As shown, a dynamic execution method for Android and Microdroid is described in this embodiment from the perspective of the Microdroid's payload in the Android client, including: Establish a data transmission channel for communication with the Android host; Receive the target service information to be executed sent by the Android host; Based on the target business information, Microdroid's business execution program is invoked to load and run the corresponding target business shared library, a communication connection is established with the business execution program, and the business data obtained by the business execution program is forwarded to the Android host. There are two ways to receive the target business information to be executed sent by the Android host. The first way is that the Android AVF application sends the target business data to Microdroid every time it starts up. The target business information includes the shared library and its signature file. After receiving the target business information, the Microdroid business execution program is invoked to verify the shared library and its signature file. After the verification is successful, the step of invoking the business execution program to load and run the corresponding target business shared library is executed. The step of calling the Microdroid business execution program to verify the shared library and the signature file of the shared library includes: The target business information is stored in a specific path of the Microdroid; The Microdroid business execution program is invoked, specifying the shared library path and the signature file path. The business execution program then verifies the shared library and its signature file based on the specified shared library path and signature file path.

[0026] The second implementation method is to save the business module file in the persistent path of Microdroid's encrypted storage, which is available the next time the VM is run. Therefore, it is not necessary to send the business module file to Microdroid every time the Android AVF application is launched. The business module file only needs to be sent to Microdroid in the following cases: the business module is running for the first time; the business module is updated and the version is higher or the VM is updated. Compared with the first implementation method, it has higher execution efficiency. The Payload persistently stores executable target business information; When Microdroid's payload is initialized and running, it reads executable target business information from the persistent storage path. The target business information includes a shared library and its signature file. The shared library is signed and verified. After the verification is successful, the version information and path of the shared library are saved to the preset memory of the payload. Before receiving the target service information to be executed sent by the Android host, the process includes: Receive version information of the executable target service sent by the Android host; If, based on the version information, it is determined that the version of the persistently stored target service is lower than the version of the target service to be executed, or that the target service to be executed is not persistently stored, then a target service information sending request is sent to the Android host. Receive the target service information to be executed sent by the Android host; After receiving the target service information to be executed sent by the Android host, the process also includes: The shared library and its signature file in the target business information to be executed are verified. After the verification is successful, the shared library and its signature file are saved to the persistent storage path, and their version information and path are guaranteed to be stored in the preset memory of the payload. The process of calling the Microdroid business execution program to load and run the corresponding target business shared library includes: The Microdroid business execution program is invoked, and the preset shared library path in memory is specified. The business execution program then loads and runs the corresponding target business shared library according to the shared library path. If, based on the version information, it is determined that the version of the target service in the persistent storage is greater than or equal to the version of the target service to be executed, then the Microdroid service execution program is directly invoked based on the target service information to load and run the corresponding target service shared library, a communication connection is established with the service execution program, and the service data obtained by the service execution program is forwarded to the Android host.

[0027] In another alternative implementation, such as Figure 7 As shown, a dynamic execution method for Android and Microdroid is described in this embodiment from the perspective of a system consisting of an Android host and an Android client, including: The Android host establishes a data transmission channel for communication with the Microdroid's payload. The payload receives the target service information to be executed sent by the Android host; The payload calls the Microdroid business execution program based on the target business information to load and run the corresponding target business shared library, establishes a communication connection with the business execution program, and forwards the business data obtained by the business execution program to the Android host.

[0028] There are two ways to receive the target business information to be executed sent by the Android host. The first way is that the Android AVF application sends the target business data to Microdroid every time it starts up. The target business information includes the shared library and its signature file. After the Payload receives the target service information, it calls the Microdroid service execution program to verify the shared library and its signature file. After the verification is successful, it executes the step of calling the service execution program to load and run the corresponding target service shared library. The step of calling the Microdroid business execution program to verify the shared library and the signature file of the shared library includes: The target business information is stored in a specific path of the Microdroid; The Microdroid business execution program is invoked, specifying the shared library path and the signature file path. The business execution program then verifies the shared library and its signature file based on the specified shared library path and signature file path.

[0029] The second implementation method is to save the business module file in the persistent path of Microdroid's encrypted storage, which is available the next time the VM is run. Therefore, it is not necessary to send the business module file to Microdroid every time the Android AVF application is launched. The business module file only needs to be sent to Microdroid in the following cases: the business module is running for the first time; the business module is updated and the version is higher or the VM is updated. Compared with the first implementation method, it has higher execution efficiency. The payload persistently stores executable target business information; When Microdroid's payload is initialized and running, the payload reads executable target business information from the persistent storage path. The target business information includes a shared library and its signature file. The shared library is signed and verified. After the verification is successful, the version information and path of the shared library are saved to the preset memory of the payload. The payload receives the target service information to be executed sent by the Android host, including: The Android host locates the target business information to be executed stored in Android, reads its version information, and sends the version information to the payload; If the payload determines, based on the version information, that the version of the persistently stored target service is lower than the version of the target service to be executed, or that the target service to be executed is not persistently stored, then it sends a target service information sending request to the Android host. The payload receives the target service information to be executed sent by the Android host; After the payload receives the target service information to be executed sent by the Android host, it further includes: The payload verifies the shared library and its signature file in the target business information to be executed. After the verification is successful, the shared library and its signature file are saved to the persistent storage path, and their version information and path are guaranteed to be stored in the preset memory of the payload. The process of calling the Microdroid business execution program to load and run the corresponding target business shared library includes: The Microdroid business execution program is invoked, and the preset shared library path in memory is specified. The business execution program then loads and runs the corresponding target business shared library according to the shared library path. If the payload determines, based on the version information, that the version of the target service in the persistent storage is greater than or equal to the version of the target service to be executed, then it directly calls the Microdroid service execution program to load and run the corresponding target service shared library based on the target service information, establishes a communication connection with the service execution program, and forwards the service data obtained by the service execution program to the Android host.

[0030] In another alternative implementation, such as Figure 8 As shown, an Android host includes a first memory, a first processor, and a first computer program stored in the first memory and executable on the first processor. When the first processor executes the first computer program, it implements the steps of the dynamic execution method of Android and Microdroid implemented from the perspective of the Android host in the above embodiments.

[0031] In another alternative implementation, such as Figure 9 As shown, an Android client includes a payload, which includes a second memory, a second processor, and a second computer program stored on the second memory and executable on the second processor. When the second processor executes the second computer program, it implements the steps of a dynamic execution method for Android and Microdroid implemented from the perspective of the Android client in the above embodiment.

[0032] In another alternative embodiment, a computer-readable storage medium stores computer program instructions that, when executed by a processor, implement the steps of a dynamic execution method for Android and Microdroid as described in any of the above embodiments. In another alternative implementation, such as Figure 10 As shown, a dynamic execution system for Android and Microdroid is disclosed. The system includes an Android host and an Android client. The Android host includes a first memory, a first processor, and a first computer program stored in the first memory and executable on the first processor. The Android client includes a payload. The payload includes a second memory, a second processor, and a second computer program stored in the second memory and executable on the second processor. When the first processor executes the first computer program, it implements the steps of the dynamic execution method for Android and Microdroid implemented by the Android host in the above embodiment. When the second processor executes the second computer program, it implements the steps of the dynamic execution method for Android and Microdroid implemented by the Android client in the above embodiment.

[0033] In summary, the present invention provides a dynamic execution method for Android and Microdroid, an Android host, an Android client, a computer-readable storage medium, and a system. In the implementation of AVF applications, the payload and shared libraries in Microdroid are separated. The payload acts as a data relay station, establishing communication connections with both the Android host and the business execution program in Microdroid. Based on the target business information sent by the Android host, the payload calls the business execution program to load and run the corresponding target business shared library, and forwards the business data obtained by the business execution program to the Android host. The dynamically shared library stored in Android is transmitted to Microdroid for dynamic loading and execution, thereby realizing data interaction between the payload and the Android host. This decouples the payload from the specific business content, ensuring that updates or changes to the specific business content do not lead to changes in the payload code. Consequently, it avoids issues such as virtual machine key changes and the invalidation of old persistent data, significantly improving the efficiency of program execution in the AVF implementation process.

[0034] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A dynamic execution method for Android and Microdroid, characterized in that, include: Establish a data transmission channel for communication with the Microdroid payload; Send the target business information to be executed, stored in Android, to the payload; The payload receives target service data forwarded by the payload. The target service data is obtained by the payload calling the service execution program to load and run the corresponding target service shared library based on the target service information.

2. The dynamic execution method for Android and Microdroid according to claim 1, characterized in that, The step of sending the target business information to be executed stored in Android to the payload includes: Locate the target business information to be executed stored in Android, read its version information, and send the version information to the payload; The payload receives a target service information sending request from the payload. The payload persistently stores executable target service information. The target service information sending request is sent by the payload if it determines, based on the version information, that the version of the target service to be executed is greater than the version of the target service persistently stored by the payload, or if the payload does not persistently store the target service to be executed. The target business information to be executed is sent to the payload.

3. The dynamic execution method for Android and Microdroid according to claim 2, characterized in that, After sending the version information to the payload, the payload receives the target service data forwarded by the payload. The target service data is obtained by the payload calling the service execution program to load and run the corresponding target service shared library when it determines that the version of the target service to be executed is not lower than the version of the target service persistently stored by the payload based on the version information.

4. A dynamic execution method for Android and Microdroid according to claim 1 or 2, characterized in that, The target business information includes the shared library and its signature file; The business execution program loads and runs the target business shared library after successfully verifying the shared library and its signature file.

5. A dynamic execution method for Android and Microdroid, characterized in that, include: Establish a data transmission channel for communication with the Android host; Receive the target service information to be executed sent by the Android host; Based on the target business information, the Microdroid business execution program is invoked to load and run the corresponding target business shared library, a communication connection is established with the business execution program, and the business data obtained by the business execution program is forwarded to the Android host.

6. The dynamic execution method for Android and Microdroid according to claim 5, characterized in that, The target business information includes the shared library and its signature file; After receiving the target business information, the Microdroid business execution program is invoked to verify the shared library and its signature file. After successful verification, the step of invoking the business execution program to load and run the corresponding target business shared library is executed.

7. The dynamic execution method for Android and Microdroid according to claim 6, characterized in that, The step of calling the Microdroid business execution program to verify the shared library and the signature file of the shared library includes: The target business information is stored in a specific path of the Microdroid; The Microdroid business execution program is invoked, specifying the shared library path and the signature file path. The business execution program then verifies the shared library and its signature file based on the specified shared library path and signature file path.

8. The dynamic execution method for Android and Microdroid according to claim 5, characterized in that, Persistent storage contains executable target business information; Before receiving the target service information to be executed sent by the Android host, the process includes: Receive version information of the executable target service sent by the Android host; If, based on the version information, it is determined that the version of the persistently stored target service is lower than the version of the target service to be executed, or that the target service to be executed is not persistently stored, then a target service information sending request is sent to the Android host. Receive the target service information to be executed sent by the Android host.

9. The dynamic execution method for Android and Microdroid according to claim 8, characterized in that, Also includes: Read executable target business information from persistent storage path. The target business information includes a shared library and its signature file. Perform signature verification on the shared library. After successful verification, save the version information and path of the shared library to the preset memory of the payload. After receiving the target service information to be executed sent by the Android host, the process also includes: The shared library and its signature file in the target business information to be executed are verified. After the verification is successful, the shared library and its signature file are saved to the persistent storage path, and their version information and path are guaranteed to be stored in the preset memory of the payload. The process of calling the Microdroid business execution program to load and run the corresponding target business shared library includes: The Microdroid business execution program is invoked, and the preset shared library path in memory is specified. The business execution program then loads and runs the corresponding target business shared library according to the shared library path.

10. The dynamic execution method for Android and Microdroid according to claim 8, characterized in that, If, based on the version information, it is determined that the version of the target service in the persistent storage is greater than or equal to the version of the target service to be executed, then the Microdroid service execution program is directly invoked based on the target service information to load and run the corresponding target service shared library, a communication connection is established with the service execution program, and the service data obtained by the service execution program is forwarded to the Android host.

11. A dynamic execution method for Android and Microdroid, characterized in that, include: The Android host establishes a data transmission channel for communication with the Microdroid's payload. The payload receives the target service information to be executed sent by the Android host; The payload calls the Microdroid business execution program based on the target business information to load and run the corresponding target business shared library, establishes a communication connection with the business execution program, and forwards the business data obtained by the business execution program to the Android host.

12. The dynamic execution method for Android and Microdroid according to claim 11, characterized in that, The target business information includes the shared library and its signature file; After the payload receives the target service information, it calls the Microdroid service execution program to verify the shared library and its signature file. After the verification is successful, it executes the step of calling the service execution program to load and run the corresponding target service shared library.

13. The dynamic execution method for Android and Microdroid according to claim 12, characterized in that, The step of calling the Microdroid business execution program to verify the shared library and the signature file of the shared library includes: The target business information is stored in a specific path of the Microdroid; The Microdroid business execution program is invoked, specifying the shared library path and the signature file path. The business execution program then verifies the shared library and its signature file based on the specified shared library path and signature file path.

14. The dynamic execution method for Android and Microdroid according to claim 11, characterized in that, The payload persistently stores executable target business information; The payload receives the target service information to be executed sent by the Android host, including: The Android host locates the target business information to be executed stored in Android, reads its version information, and sends the version information to the payload; If the payload determines, based on the version information, that the version of the persistently stored target service is lower than the version of the target service to be executed, or that the target service to be executed is not persistently stored, then it sends a target service information sending request to the Android host. The payload receives the target service information to be executed sent by the Android host.

15. The dynamic execution method for Android and Microdroid according to claim 14, characterized in that, Also includes: The payload reads executable target business information from the persistent storage path. The target business information includes a shared library and its signature file. The shared library is signed and verified. After the verification is successful, the version information and path of the shared library are saved to the preset memory of the payload. After the payload receives the target service information to be executed sent by the Android host, it further includes: The payload verifies the shared library and its signature file in the target business information to be executed. After the verification is successful, the shared library and its signature file are saved to the persistent storage path, and their version information and path are guaranteed to be stored in the preset memory of the payload. The process of calling the Microdroid business execution program to load and run the corresponding target business shared library includes: The Microdroid business execution program is invoked, and the preset shared library path in memory is specified. The business execution program then loads and runs the corresponding target business shared library according to the shared library path.

16. The dynamic execution method for Android and Microdroid according to claim 14, characterized in that, If the payload determines, based on the version information, that the version of the target service in the persistent storage is greater than or equal to the version of the target service to be executed, then it directly calls the Microdroid service execution program to load and run the corresponding target service shared library based on the target service information, establishes a communication connection with the service execution program, and forwards the service data obtained by the service execution program to the Android host.

17. An Android host, comprising a first memory, a first processor, and a first computer program stored in the first memory and executable on the first processor, characterized in that, When the first processor executes the first computer program, it implements the steps of a dynamic execution method for Android and Microdroid as described in any one of claims 1 to 4.

18. An Android client comprising a payload, the payload including a second memory, a second processor, and a second computer program stored on the second memory and executable on the second processor, characterized in that, When the second processor executes the second computer program, it implements the steps of a dynamic execution method for Android and Microdroid as described in any one of claims 5 to 10.

19. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the steps of the dynamic execution method for Android and Microdroid as described in any one of claims 1 to 10.

20. A dynamic execution system for Android and Microdroid, the system comprising an Android host and an Android client, the Android host comprising a first memory, a first processor, and a first computer program stored in the first memory and executable on the first processor, the Android client comprising a payload, the payload comprising a second memory, a second processor, and a second computer program stored in the second memory and executable on the second processor, characterized in that, When the first processor executes the first computer program, it implements the steps of the dynamic execution method of Android and Microdroid as described in any one of claims 1 to 4; when the second processor executes the second computer program, it implements the steps of the dynamic execution method of Android and Microdroid as described in any one of claims 5 to 10.