A method and system for implementing distributed capabilities of an Android application based on a shadow process

Abstract

The application discloses a method and system for realizing distributed capability of an Android application based on a shadow process, and the method comprises the following steps: starting a fusion system, obtaining a request of starting an Android application by a user, creating a shadow process, registering a mapping relationship between the Android application and the shadow process to a resource sharing bridge, and registering resource information of a remote device obtained by a distributed component of OpenHarmony to the resource sharing bridge by the shadow process; the shadow process calls the distributed component to receive data sent by the remote device and injects the data into the resource sharing bridge, and an Android application accesses the resource sharing bridge to obtain the data; the Android application sends the data to the resource sharing bridge, the shadow process accesses the resource sharing bridge to read the data, and then sends the data to the remote device by the distributed component. The application realizes the distributed capability of the Android application under the condition of realizing the Android application compatible layer based on the container isolation technology.

Description

Technical Field

[0001] This invention relates to the field of Android application development technology, and specifically to a method for implementing distributed capabilities of Android applications based on shadow processes. Background Technology

[0002] As an emerging operating system, OpenHarmony possesses many leading technical features, such as distributed capabilities. Against the backdrop of the rapid development of the Internet of Things (IoT), these features can provide powerful innovation capabilities for IoT scenarios. For example, its distributed task scheduling capabilities can support cross-device application startup, remote invocation, and application migration, enabling cross-device resource sharing and computing power integration, significantly reducing the innovation cost of IoT applications and promoting the rapid arrival of the "Internet of Everything."

[0003] However, OpenHarmony also has its fatal weakness: as a new operating system, its ecosystem of applications is severely lacking, and its installed base is relatively small. On the other hand, Android, as a mainstream operating system, has a rich ecosystem of applications and a huge installed base. If a technology can be provided to integrate Android and OpenHarmony and give Android applications distributed capabilities, the integration between OpenHarmony and the Android ecosystem can be greatly improved, promoting the rapid arrival of the "Internet of Everything".

[0004] To achieve system integration, an Android application compatibility layer is typically implemented, and this compatibility layer usually employs isolation technologies, such as containers or virtualization. Figure 1 As shown, when Android applications and the compatibility layer are isolated, Android applications cannot directly access the distributed features of the host system OpenHarmony, and therefore cannot have distributed capabilities. Summary of the Invention

[0005] Purpose of the invention: The purpose of this invention is to address the shortcomings of existing technologies by providing a method and system for implementing distributed capabilities of Android applications based on shadow processes. In a system integrating Android and OpenHarmony, this invention solves the technical challenge of providing distributed capabilities of OpenHarmony for Android applications, enabling Android applications to access the hardware resources of remote devices across devices.

[0006] Technical solution: The method for implementing distributed capabilities of Android applications based on shadow processes as described in this invention includes the following steps:

[0007] S1. Create a shadow process: Start the fusion system, obtain the user's request to launch the Android application, create a corresponding shadow process, register the mapping relationship between the Android application and the shadow process to the resource sharing bridge, the shadow process obtains the resource information of the remote device through the distributed components of OpenHarmony and registers it to the resource sharing bridge, and the Android application accesses the resource sharing bridge to obtain the resource information of the remote device registered with its corresponding shadow process.

[0008] S2. Get data: The shadow process calls the distributed component to receive data sent by the remote device, injects the received data into the resource sharing bridge, and the Android application accesses the resource sharing bridge to get the data injected by the shadow process.

[0009] S3. Sending Data: The Android application sends data to the resource sharing bridge. The shadow process accesses the resource sharing bridge to read the data sent by the Android application, and then sends it to the remote device through the distributed component.

[0010] Further improvements to the above technical solution include obtaining the shadow process cancellation request, obtaining the user's request to cancel the shadow process, canceling the mapping between the Android application and the shadow process, and disconnecting the communication between the shadow process and the Android application through the resource sharing bridge.

[0011] Furthermore, the fusion system includes a host system and a client system. The host system is an OpenHarmony system, and the client system is an Android system. The Android system uses container isolation technology to implement an Android application compatibility layer to run the Android application.

[0012] A system for implementing the above-mentioned method of achieving distributed capabilities of Android applications based on shadow processes includes: a shadow process manager, used to obtain the startup request of an Android application, create a shadow process corresponding to the Android application, and register the mapping relationship between the Android application and the shadow process to a resource sharing bridge; a shadow process, corresponding one-to-one with the Android application, capable of obtaining resource information of a remote device through the distributed components of OpenHarmony and registering it to the resource sharing bridge; and a resource sharing bridge, connecting the shadow process and the Android application, allowing the Android application to read the resource information of the remote device registered by the shadow process for distributed data transmission.

[0013] Furthermore, the shadow process manager is used for the lifecycle management of shadow processes, including the creation, cancellation, status management, and querying of shadow processes.

[0014] Furthermore, the distributed data transmission refers to: the shadow process obtaining data sent by the Android application from the resource-sharing bridge and sending it to the remote device through the distributed component; and obtaining data from the remote device from the distributed component and transmitting it to the Android application through the resource-sharing bridge.

[0015] Furthermore, the resource sharing bridge provides the following interfaces: register_sp, unregister_sp, push_device_list, get_device_list, push_remote_data, get_remote_data, pop_remote_data, and send_remote_data. The shadow process manager calls the register_sp and unregister_sp interfaces to register and unregister the mapping relationship between the shadow process and the Android application, respectively. The shadow process calls the push_device_list interface to encapsulate the resource information of the remote device obtained through the distributed components of OpenHarmony and register it to the relevant application. The resource-sharing bridge is configured as follows: the Android application calls the `get_device_list` interface to obtain resource information of remote devices registered with the corresponding shadow process on the resource-sharing bridge; the shadow process calls the `push_remote_data` interface to inject remote device data received through the distributed component into the resource-sharing bridge; the Android application calls the `get_remote_data` interface to obtain remote device data injected into the resource-sharing bridge by its corresponding shadow process; the Android application calls the `send_remote_data` interface to send Android data to the resource-sharing bridge; and the shadow process calls the `pop_remote_data` interface to read the Android data and sends it to the remote device through the distributed component.

[0016] Beneficial Effects: Compared with existing technologies, the advantages of this invention are as follows: This invention solves the problem of how to endow Android applications with distributed capabilities and achieve distributed communication with remote OpenHarmony devices under the condition of implementing an Android application compatibility layer based on container isolation technology. This invention does not require modification or intrusive alteration of Android applications, has great scalability, and can be adapted to various versions of Android systems, thereby promoting the interconnection and integration of Android and OpenHarmony in IoT scenarios. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the architecture of an existing fusion system;

[0018] Figure 2 This is a schematic diagram of the architecture of the method for implementing distributed capabilities of Android applications based on shadow processes according to the present invention;

[0019] Figure 3 This is a flowchart of the method for implementing distributed capabilities of Android applications based on shadow processes, as described in this invention. Detailed Implementation

[0020] The technical solution of the present invention will be described in detail below with reference to the accompanying drawings, but the scope of protection of the present invention is not limited to the embodiments described.

[0021] System fusion refers to running multiple operating systems simultaneously on a single piece of hardware. Conversely, "converged systems" refers to multiple systems running simultaneously on a single piece of hardware after "system fusion." In the case of system fusion, there is typically a master system that has access to all resources; this system is called the host system. Other systems rely on the interfaces provided by the host system to access resources; these systems are called client systems or slave systems.

[0022] In this invention, OpenHarmony is the host system, Android is the client system, and the compatibility layer is a system integration technology that runs on top of OpenHarmony, enabling Android applications to run on OpenHarmony. To ensure security and consistency, the Android application compatibility layer employs isolation technologies such as containers or virtualization. Distributed functionality, a unique feature of OpenHarmony, enables distributed transfer of applications across different devices.

[0023] This invention enables distributed capabilities for Android applications by designing shadow processes and resource-sharing bridges, and its architecture is as follows: Figure 2 As shown, it includes shadow processes, shadow process managers, Android applications, and resource sharing bridges.

[0024] The role of shadow processes and resource sharing bridges is as follows: There is a one-to-one correspondence between shadow processes and Android applications. When the system launches an Android application, it creates an Android process for that application, which is isolated within the compatibility layer. Simultaneously, the system creates a corresponding shadow process on the host system side. Because this process runs directly on the host system side, it is considered a native OpenHarmony application and can access directly distributed components. Therefore, shadow processes can access the hardware resources of remote devices through distributed components.

[0025] The shadow process manager is used for the lifecycle management of shadow processes, such as creation, deregistration, status management, and querying. For example, when the merged system starts an Android application, it notifies the shadow process manager to create a shadow process. It is also responsible for registering the mapping relationship between shadow processes and Android applications with the resource sharing bridge to ensure a one-to-one correspondence between shadow processes and Android applications.

[0026] The resource sharing bridge is responsible for connecting the shadow process of the Android application. When the shadow process obtains access to the hardware resources of the remote device through the distributed component, it will register the device on the resource sharing bridge. After that, the Android application can discover the device from the resource sharing bridge and operate on the device as if it were a local device.

[0027] Table 1 Interface Table of Resource Sharing Bridge

[0028] interface caller Function register_sp(sppid: the ID of the shadow process; appid: the ID of the Android application) Shadow Process Manager Register a mapping between a shadow process and an Android application. Afterward, the shadow process communicates with the corresponding Android application via a resource-sharing bridge. unregister_sp(sppid: the ID of the shadow process) Shadow Process Manager Unmapping a shadow process from an Android application prevents that shadow process from communicating with the corresponding Android application via a resource-sharing bridge. push_device_list(devices: Injects remote device information into the resource-sharing bridge) Shadow process After obtaining remote device information from OpenHarmony's distributed components, the shadow process encapsulates the information and injects it into the resource-sharing bridge. get_device_list(&devices: used to store a list of devices) Android application An Android application obtains device information injected into a resource-sharing bridge by a shadow process. This Android application can only obtain information injected by its corresponding shadow process. push_remote_data(data: data) Shadow process The shadow process injects remote device data obtained by the distributed components into the resource-sharing bridge. get_remote_data(data: data) Android application An Android application obtains remote data injected into a resource-shared bridge by a shadow process. This Android application can only obtain information injected by its corresponding shadow process. pop_remote_data(data: data) Shadow process The shadow process reads the data that the Android application is trying to send to the remote device from the resource-sharing bridge and sends it to the remote device through distributed components. send_remote_data(data: data) Android application When an Android application sends data to a resource-sharing bridge, its corresponding shadow process then sends the data to a remote device.

[0029] like Figure 3 As shown, the call flow for distributed capabilities in an Android application is as follows:

[0030] 1. Activate the resource sharing bridge

[0031] Once the converged system starts up—that is, after both the host and client systems are running—the resource-sharing bridge is automatically activated. On the host system (OpenHarmony) side, the resource-sharing bridge provides several interfaces that shadow processes can call to register remote device resources obtained from distributed components onto the resource-sharing bridge. On the client system (Android) side, it also provides several interfaces that Android applications can call to obtain device information from remote devices and perform distributed data communication with them.

[0032] 2. Launch Shadow Process Manager

[0033] After the resource sharing bridge starts up, the system starts the shadow process manager.

[0034] 3. Launch an Android application

[0035] When a user launches an Android application, the system notifies the Shadow Process Manager. After the Android application launches successfully, a shadow process is created. The creation process is completed by calling the OpenHarmony standard interface, and the shadow process runs in the background. After the shadow process is created, the Shadow Process Manager calls the register_sp interface to register the mapping relationship between the shadow process and the Android application with the resource sharing bridge.

[0036] 4. Obtain remote device resources through distributed components

[0037] The shadow process obtains resource information of remote devices through OpenHarmony's distributed components and registers the resource information of remote devices with the resource sharing bridge.

[0038] 5. Android applications gain distributed capabilities

[0039] Android applications read resource information of remote devices registered by shadow processes from the resource-sharing bridge and call the resource-sharing bridge's interface to obtain or send data.

[0040] 6. Achieve distributed data transmission with remote devices through shadow processes.

[0041] The shadow process retrieves data sent by the Android application from the resource-shared bridge and sends it to the remote device via the distributed component. Similarly, data from the remote device can be retrieved from the distributed component and passed to the Android application via the resource-shared bridge.

[0042] This invention provides Android applications with a universal distributed capability and enables distributed communication with remote OpenHarmony devices. This invention requires no modification or intrusive alteration to Android applications, possesses high scalability, and can be adapted to various versions of the Android system; thereby promoting the interconnection and integration of Android and OpenHarmony in IoT scenarios.

[0043] As described above, although the invention has been shown and described with reference to specific preferred embodiments, it should not be construed as limiting the invention itself. Various changes in form and detail may be made without departing from the spirit and scope of the invention as defined in the appended claims.

Claims

1. A method for implementing distributed capabilities of Android applications based on shadow processes, characterized in that, Includes the following steps: S1. Create a shadow process: Start the fusion system, obtain the user's request to launch the Android application, create a corresponding shadow process, register the mapping relationship between the Android application and the shadow process to the resource sharing bridge, the shadow process obtains the resource information of the remote device through the distributed components of OpenHarmony and registers it to the resource sharing bridge, and the Android application accesses the resource sharing bridge to obtain the resource information of the remote device registered with its corresponding shadow process. S2. Get data: The shadow process calls the distributed component to receive data sent by the remote device, injects the received data into the resource sharing bridge, and the Android application accesses the resource sharing bridge to get the data injected by the shadow process. S3. Sending Data: The Android application sends data to the resource sharing bridge. The shadow process accesses the resource sharing bridge to read the data sent by the Android application, and then sends it to the remote device through the distributed component.

2. The method for implementing distributed capabilities of Android applications based on shadow processes according to claim 1, characterized in that: It also includes obtaining the cancellation of the shadow process, obtaining the user's request to cancel the shadow process, canceling the mapping between the Android application and the shadow process, and disconnecting the communication between the shadow process and the Android application through the resource sharing bridge.

3. The method for implementing distributed capabilities of Android applications based on shadow processes according to claim 1, characterized in that: The fusion system includes a host system and a client system. The host system is an OpenHarmony system, and the client system is an Android system. The Android system uses container isolation technology to implement an Android application compatibility layer to run the Android application.

4. A system for implementing the method of achieving distributed capabilities of Android applications based on shadow processes as described in claim 1, characterized in that, include: The shadow process manager is used to obtain the launch request of an Android application, create a shadow process corresponding to the Android application, and register the mapping relationship between the Android application and the shadow process to the resource sharing bridge. The shadow process, which corresponds one-to-one with the Android application, can obtain resource information of remote devices through the distributed components of OpenHarmony and register with the resource sharing bridge; as well as A resource-sharing bridge connects the shadow process and the Android application, allowing the Android application to read resource information from remote devices registered by the shadow process for distributed data transmission.

5. The system according to claim 4, characterized in that: The shadow process manager is used for the lifecycle management of shadow processes, including the creation, cancellation, status management and querying of shadow processes.

6. The system according to claim 4, characterized in that: The distributed data transmission refers to: the shadow process obtaining data sent by the Android application from the resource-sharing bridge and sending it to the remote device through the distributed component; and obtaining data from the remote device from the distributed component and transmitting it to the Android application through the resource-sharing bridge.

7. The system according to claim 4, characterized in that: The resource sharing bridge provides the following interfaces: register_sp, unregister_sp, push_device_list, get_device_list, push_remote_data, get_remote_data, pop_remote_data, send_remote_data; The shadow process manager calls the `register_sp` and `unregister_sp` interfaces to register and unregister the mapping relationship between shadow processes and Android applications, respectively. The shadow process calls the `push_device_list` interface to encapsulate the resource information of the remote device obtained through the OpenHarmony distributed component and registers it to the resource sharing bridge. The Android application calls the `get_device_list` interface to obtain the resource information of the remote device registered to the resource sharing bridge by its corresponding shadow process. The shadow process calls the `push_remote_data` interface to inject the remote device data received through the distributed component into the resource sharing bridge. The Android application calls the `get_remote_data` interface to obtain the remote device data injected to the resource sharing bridge by its corresponding shadow process. The Android application calls the `send_remote_data` interface to send Android data to the resource sharing bridge. The shadow process calls the `pop_remote_data` interface to read the Android data and sends it to the remote device through the distributed component.

Images