WO2021233103A1

WO2021233103A1 - Method and apparatus of cross-ipc access

Info

Publication number: WO2021233103A1
Application number: PCT/CN2021/090658
Authority: WO
Inventors: Yiwei ZHAO; Xiaofeng Li
Original assignee: Guangdong Oppo Mobile Telecommunications Corp., Ltd.
Priority date: 2020-05-21
Filing date: 2021-04-28
Publication date: 2021-11-25

Abstract

Embodiments of the disclosure relates to a method of cross inter-process communication (IPC) access, which is implemented by a first device provided with an application based on a first IPC protocol and includes: receiving a service request initiated by the application, wherein the service request is used for invoking a remote service provided by a second device based on a second IPC protocol; transmitting the service request to the second device through a connection established based on a third IPC protocol; and providing the application with a service response based on a feedback from the second device, wherein at least two of the first, second and third protocols are different.

Description

METHOD AND APPARATUS OF CROSS-IPC ACCESS

RELATED APPLICATION

This application claims the benefit of priority of U.S. Provisional Patent Application No. 63/028,373 filed on May 21, 2020, the contents of which are incorporated herein by reference in, their entirety.

TECHNICAL FIELD

The present disclosure, in some embodiments thereof, relates to remote communication, and more specifically, but not exclusively, to a method and an apparatus of cross-IPC (Inter-Process Communication) access.

BACKGROUND

IPC generally refers to a set of techniques for the exchange of data among multiple threads in one or more processes, where the processes may run on one or more computers connected by a network. Remote procedure call (RPC) is an IPC technology that allows an application (e.g., a computer program) to cause a subroutine or procedure to execute in another address space (e.g., another computer on a shared network) without the programmer explicitly coding the details for this remote interaction.

Within a distributed environment, an application should better be able to access any available service, regardless of the IPC mechanism based on which the service is provisioned. Currently, however, there are many IPC protocols that are very popular in consumer device’s programming without ability of cross-IPC access. It is a urgent problem to be solved on how to implement cross-IPC access between different IPC protocols.

SUMMARY

The present disclosure provides a method and an apparatus of cross-IPC access.

According to some embodiments of the disclosure, there is provided a method of cross-IPC access, implemented by a first device provided with an application based on a first IPC protocol, including: receiving a service request initiated by the application, wherein the service request is used for invoking a remote service provided by a second device based on a second IPC protocol; transmitting the service request to the second device through a connection established based on a third IPC protocol; and providing the application with a service response based on a feedback from the second device, wherein at least two of the first, second and third protocols are different.

According to some embodiments of the disclosure, there is provided a method of cross-IPC access, implemented by a second device provided with a remote service based on a second IPC protocol, including: receiving a service request from a first device through a connection established based on a third IPC protocol, wherein the first device is provided with an application based on a first IPC protocol, and the service request is initiated by the application and used for invoking the remote service; and sending a feedback to the first device in response to an invoking result of the remote device, wherein at least two of the first, second and third protocols are different.

According to some embodiments of the disclosure, there is provided an apparatus of cross-IPC access, implemented as a first device provided with an application based on a first IPC protocol, including: an initiation module, configured to receive a service request initiated by the application, wherein the service request is used for invoking a remote service provided by a second device based on a second IPC protocol; a transmission module, configured to transmit the service request to the second device through a connection established based on a third IPC protocol; and a receiving module, configured to provide the application with a service response based on a feedback from the second device, wherein at least two of the first, second and third protocols are different.

According to some embodiments of the disclosure, there is provided an apparatus of cross-IPC access, implemented as a second device provided with a remote service based on a second IPC protocol, including: a receiving module, configured to receive a service request from a first device through a connection established based on a third IPC protocol, wherein the first device is provided with an application based on a first IPC protocol, and the service request is initiated by the application and used for invoking the remote service; and a sending module, configured to send a feedback to the first device in response to an invoking result of the remote device, wherein at least two of the first, second and third protocols are different.

According to some embodiments of the disclosure, there is provided a device of cross-IPC access, including: a processor and a memory. The memory is configured to store a computer program, and the processor is configured to call and run the computer program stored in the memory, thereby implementing the method of cross-IPC access according to the related embodiments.

According to some embodiments of the disclosure, there is provided a chip configured to implement the method of cross-IPC access according to the related embodiments.

Specifically, the chip includes a processor, configured to call and run a computer program from a memory, thereby causing an apparatus provided with the chip to implement the method of cross-IPC access according to the related embodiments.

According to some embodiments of the disclosure, there is provided a non-transitory computer readable storage medium, being used for storing a computer program, wherein the computer program causes a computer to implement the method of cross-IPC access according to the related embodiments.

According to some embodiments of the disclosure, there is provided a computer program product, including computer program instructions that cause a computer to implement the method of cross-IPC access according to the related embodiments.

According to some embodiments of the disclosure, there is provided a computer program which, when running on a computer, causes the computer to implement the method of cross-IPC access according to the related embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an exemplary development environment of binder.

FIG. 2 illustrates an exemplary development environment of gRPC.

FIG. 3 is a flow chart exemplarily illustrating a method of cross-IPC access according to some embodiments of the disclosure.

FIG. 4 illustrates an exemplary development environment of blinder-to-gRPC.

FIG. 5 illustrates an exemplary implementation for establishing a binder connection between two binder applications on an Android device.

FIG. 6 is a flow chart exemplarily illustrating the method of cross-IPC access according to some embodiments of the disclosure.

FIG. 7 illustrates an exemplary implementation for establishing a connection between a binder application and a gRPC service.

FIG. 8 is a flow chart exemplarily illustrating steps for establishing the connection between the binder application and the gRPC service.

FIG. 9 is a flow chart exemplarily illustrating the method of cross-IPC access according to some embodiments of the disclosure.

FIG. 10 illustrates an exemplary implementation of the embodiment illustrated by FIG. 9.

FIG. 11 illustrates an exemplary development environment of the plugins.

FIG. 12 is a flow chart exemplarily illustrating steps for establishing the connection between PA and gRPC server.

FIG. 13 illustrates another exemplary implementation of the embodiment illustrated by FIG. 9.

FIG. 14 is a flow chart exemplarily illustrating the method of cross-IPC access according to some embodiments of the disclosure.

FIG. 15 illustrates an exemplary implementation of the embodiment illustrated by FIG. 14.

FIG. 16 illustrates an exemplary flow chart for establishing the gRPC connection in the embodiment illustrated by FIG. 15.

FIG. 17 illustrates an exemplary flow chart for processing the binder call in the embodiment illustrated by FIG. 15.

FIG. 18 is a flow chart exemplarily illustrating the method of cross-IPC access according to some embodiments of the disclosure.

FIG. 19 illustrates an exemplary implementation for establishing a connection between a gRPC application and a binder service.

FIG. 20 is a flow chart exemplarily illustrating steps for communicating between the gRPC application and the binder service.

FIG. 21 is a flow chart exemplarily illustrating the method of cross-IPC access according to some embodiments of the disclosure.

FIG. 22 illustrates an exemplary implementation of distributed binder over gRPC.

FIG. 23 is a flow chart exemplarily illustrating a method of cross-IPC access according to some embodiments of the disclosure.

FIG. 24 is a block diagram exemplarily illustrating an apparatus of cross-IPC access according to some embodiments of the disclosure.

FIG. 25 is a block diagram exemplarily illustrating an apparatus of cross-IPC access according to some embodiments of the disclosure.

FIG. 26 is a block diagram illustrating a cross-IPC accessing device 2600 according to some embodiments of the application.

FIG. 27 is a block diagram illustrating a chip according to some embodiments of the application.

DETAILED DESCRIPTION

Exemplary embodiments of the disclosure will now be described more fully with reference to the accompanying drawings, in which exemplary embodiments are shown. Exemplary embodiments of the disclosure may, however, be embodied in many different forms and should not be construed as being limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of exemplary embodiments to those skilled in the art. In the drawings, the separate layers and regions are exaggerated for clarity. Like reference numerals in the drawings denote like elements, and thus their description will be omitted.

The described features, structures, or/and characteristics of the disclosure may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are disclosed to provide a thorough understanding of embodiments of the disclosure. One skilled in the relevant art will recognize, however, that the disclosure may be practiced without one or more of the specific details, or with other methods, components and so forth. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the disclosure.

In the description of the present disclosure, terms such as "connection" and the like should be understood broadly, and may refer to direct connection or indirect connection through an intermediate medium, unless otherwise specified. The specific meanings of the above terms in the present disclosure can be understood by those skilled in the art on a case-by-case basis.

In the description of the present disclosure, the term “server” refers to an application or a process which can host one or more “services” , so the terms “server” and “service” are interchangeably used herein unless otherwise specified.

Further, in the description of the present disclosure, the meaning of "a plurality" , "multiple" or "several" is at least two, for example, two, three, etc., unless specifically defined otherwise. "And/or" , describing the association relationship of the associated objects, indicates that there may be three relationships, such as A and/or B, which may indicate that there are three cases of single A, single B and both A and B. The symbol "/" generally indicates that the contextual object is an "or" relationship.

With reference to the accompanying drawings, a method and an apparatus of cross-IPC access provided by the embodiments of the disclosure will be specifically described below.

Within a distributed environment, an application should better be able to access any available service, regardless of the IPC mechanism based on which the service is provisioned. Currently, however, different IPC protocols are provided without ability of cross-IPC access.

For example, there are two IPC/RPC mechanisms in consumer device’s programming, one is “binder” , which is standard IPC mechanism used in billions of Android devices; the other is gRPC, which is widely adopted to connect mobile devices to backend services.

Reference is now made to FIG. 1, showing an exemplary development environment of binder. Android binder is originally to support an application to invoke other applications’ procedures, and all the applications run on the same device. The binder IPC interfaces between android client and server are defined by the Android Interface Definition Language (AIDL) and is saved in a . aidl file 101. The input parameters and return value of a binder interface must be defined as the Java or C++ classes which implement the Parcelable classes 102. Android SDK tools 103 generates the skeleton implementation of binder interfaces 104 for both the client side 105 (called proxy) and server side 106 (called stub) based on the . aidl file 101. Programmer develops the actual implementation logic for the server and client based on the generated skeleton code.

There are some efforts in the industry to make the binder work across devices, which means an android application can invoke a binder interface implemented by an Android application running on another device. This kind of binder is also known as distributed binder.

Another RPC technology, gRPC (referring to “https: //grpc. io/” ) , is an open source RPC mechanism developed by Google. It is used for calling a remote procedure on another computer and, thus, is applicable in distributed computing to connect services between computers, or to connect client application to backend services.

Reference is now made to FIG. 2, showing an exemplary development environment of gRPC. gRPC uses protocol buffers (referring to “https: //developers. google. com/protocol-buffers” ) as the Interface Definition Language (IDL) for describing the service interfaces, which is normally saved in a . proto file 201. The Input parameter types (i.e. request type) and return type (i.e. response type) are also defined in . proto file. Protocol buffer compiler, named as protoc 202, parses the . proto file 201 and generate the types for both request and response, and also generate the skeleton implementation of gRPC interfaces 203 for both client 204 and server 205. Programmer develops the actual interface implementation for the gRPC client 204 and server 205 based on the generated code.

Distributed binder is a promising technology to construct the foundation of the distributed software environment. It can enable huge amount legacy android applications (that only run within a device) to execute in a distributed environment with minimum or even zero changes. And because binder is a widely accepted IPC mechanism in Android, it is much more attractive for android developers to continue using binder while create novel experience for distributed environment.

Meanwhile, gRPC has been widely adopted and there are lots of gRPC services available in distributed environment. In order to get access to gRPC services, an android application is required to implement a gRPC client, which includes to establish the channel to connect to the server, create different stubs for different kinds of APIs (such as synchronous, asynchronous or future) , and then invoke the various kinds of procedures such as unary call, server streaming, client streaming or bidirectional streaming.

Within the distributed environment, it is desirable for the application to be able to access any available service no matter if the services are provisioned in the protocol of binder or gRPC. For example, a media browser service, no matter whether it is a binder service or a gRPC service, should be accessible by a media player application, no matter whether it is a gRPC client or a binder client. Currently, however, a gRPC client can only access a gRPC service; and a binder client can only access a binder service.

Moreover, to build distributed binder in a distributed environment, the system has to implement a robust communication mechanism across computing devices, on top of which the binder client can call its binder server. It is a challenge to implement such a communication mechanism from scratch. Since gPRC has already a robust implementation for cross-computer communication, it is desirable to run distributed binder over gRPC.

According to some embodiments of the disclosure, a method is proposed to implement the cross-IPC access between binder and gPRC protocols.

According to some embodiments of the disclosure, a method is further proposed to run distributed binder over gPRC protocol.

In other words, the disclosure proposes solutions to make different IPC systems to interact with each other. For example, a binder client can call a gRPC server or vice versa. Furthermore, a binder client can call another binder server by using gRPC as the underlying data transportation layer.

It should be noted that, although binder and gRPC are mainly used as examples for implementing the embodiments of the disclosure, those skilled in the art, based on the disclosure, can easily conceive implementation with other IPC protocols, for example, REST/HTTP, socket and the like.

Reference is now made to FIG. 3, which is a flow chart exemplarily illustrating a method of cross-IPC access according to some embodiments of the disclosure. Such embodiments may be performed by at least one hardware processor, which is located in a first device provided with an application based on a first IPC protocol. In such embodiments, the at least one hardware processor receives (301) a service request initiated by the application, wherein the service request is used for invoking a remote service provided by a second device based on a second IPC protocol; transmits (303) the service request to the second device through a connection established based on a third IPC protocol; and provides (305) the application with a service response based on a feedback from the second device. In such embodiments, at least two of the first, second and third protocols are different from each other.

According to some embodiments of the disclosure, the first IPC is binder, and the second IPC is gRPC. In other words, a binder client at the first device is to access a gRPC service at the second device. Before describing such embodiments in detail, it may be noted that there are four kinds of gRPC service protocols, and the embodiments to be discussed here deal with two of them, which can substantially satisfy practical needs.

The service protocols that a gRPC server can provide can be categorized as following four kinds.

1) Unary RPCs, in which the client sends a single request to the server and gets a single response back, just like a normal function call.

2) Server streaming RPCs, in which the client sends a request to the server and uses a stream to read a sequence of response message back.

3) Client streaming RPCs, in which the client writes a sequence of messages and sends them to the server and sever gives a response when receiving the messages.

4) Bidirectional streaming RPCs, in which both the client and server sides send a sequence of messages using a read-write stream.

The embodiments to be discussed here support at least that an Android client application issues binder RPC call to a server application that implements the first two gRPC protocols 1) and 2) . Moreover, synchronous gRPC call is involved herein, because asynchronous call generally requires tightly coupled client/server programming, which is impractical for decoupled programming between binder client and gRPC server.

Since synchronous server streaming is essentially as same as synchronous unary RPC. The solution for synchronous unary RPC is applicable to synchronous server streaming RPC. So unary RPC is to be discussed below to represent both protocols.

When a binder client accesses a gRPC service, it should know the application programming interfaces (APIs) that the gRPC service exports. As discussed above, the tool protoc generates gRPC interface skeleton implementation. Reference is now made to FIG. 4, showing an exemplary development environment of blinder-to-gRPC. In order to achieve the cross-IPC access from the binder client to the gRPC service, it is developed a tool protoc-for-binder that can generate skeleton implementation of both gRPC interfaces 403 and binder interfaces 405 based on . proto file 401. The tool also generates the classes 404 for the parameters and return values that implements Parcelable specification. The protoc-for-binder tool can be included in protoc 402 as part of it. With the binder interface skeleton implementation and the Parcelable classes, the developer can develop the gRPC server 406 as well as the binder client 407.

In Android standard binder implementation, there are three stages for a binder client to access a binder server: the first step is to establish binder connection between client and server; after connection is established, client and server can interact between each other through binder object; and finally, the connection is to be disconnected to release system resource. Following will describe three similar stages for a binder client accessing a gRPC service.

Reference is now made to FIG. 5, showing an exemplary implementation for establishing a binder connection between two binder applications on an Android device.

If a binder application wants to provide a service to other components, it first registers its service information to the system. Package manager service (PMS) 511 in system server 510 manages all the installed applications on an Android device and has all the registered service information.

When a client 520 requests to establish binder connection with a server 530, the request is sent to activity manager service (AMS) 512. AMS 512 then asks for the service information from PMS 511. When PMS 511 returns the service information, AMS 512 can find out the real server 530 (and launch it if it is not already running) and passes the request to the server 530. Then, the server 530 returns its binder stub 531; and finally, AMS 512 passes the binder information to the client 520 through OS kernel driver, and the client 520 gets a binder proxy 521 that can be used to make RPC call.

Binder stub 531 is a binder object and hold by the server 530 in order to provide service; binder proxy 521 is a derived binder object as well and hold by the client 520 in order to call the service 530. Both binder stub 531’s and binder proxy 521’s codes are generated from . aidl file. For the binder proxy 521, the generated codes implement the interfaces which marshal requests into a parcel object and send it to the corresponding binder stub 531. For the binder stub 531, the generated codes unmarshall the received parcel, and invokes the server’s actual implementation to handle the request, and finally sends response back to client 520.

Reference is now made to FIG. 6, which is a flow chart exemplarily illustrating the method of cross-IPC access according to some embodiments of the disclosure. Such embodiments may be performed by the at least one hardware processor mentioned above. In such embodiments, the at least one hardware processor stores (601) registration information of the remote service, wherein the registration information is used for indicating a local proxy of the remote service; retrieves (603) the registration information in response to the service request initiated by the application; establishes (605) , based on the registration information, a binder connection between the application and the local proxy; and establishes (607) the connection based on the third IPC protocol between the local proxy and the remote service.

According to some embodiments, the registration information is stored in remote manager service (RMS) separately from PMS of the Android device. In such embodiments, the at least one hardware processor receives, through AMS, the service request initiated by the application; determines, through the PMS, that the service request is used for invoking the remote service; and retrieves, through the RMS, the registration information of the remote service for being returned to the AMS.

Reference is now made to FIG. 7, showing an exemplary implementation for establishing a connection between a binder application and a gRPC service.

In order to make the gRPC server 740 accessible to the binder client 720, gRPC server 740 registers in the system server 710, and is to be treated as normal binder server from the binder client 720’s perspective. In view of this, the local proxy of the gRPC service and the RMS mentioned above are introduced according to some embodiments of the disclosure. In the following description, such local proxy is also referred to as generic remote service gateway (GRSG) . GRSG 730 in FIG. 7 serves as a binder server, which has a binder stub 731 serving the binder client 720’s requests. GRSG 730 works as a proxy of the real gRPC server 740 and maintains real connection with the gRPC server 740; and it registers the gRPC server information in RMS 713. RMS 713 manages all the remote services’ information. In some embodiments, such information includes at least one item of:

1) server address and port number of all the servers;

2) service full name (e.g., package name and service name) of all the services in every server; and

3) gRPC call options (optional)

Reference is now made to FIG. 8, which is a flow chart exemplarily illustrating steps for establishing the connection between the binder application and the gRPC service.

When a client application tries to establish a connection with (i.e., bind) a gRPC service, it sends (801) a request to setup binder connection with the server, for example, it inputs gRPC service’s full name as parameter. AMS 712 receives (802) the request and asks for the service’s information from PMS 711. PMS checks (803) whether it is a local service; if yes, PMS directly returns (804) the server’s information to AMS. Otherwise, PMS asks (805) RMS to check whether there is registration information of a remote server; if yes, RMS returns (806) GRSG server information to AMS via PMS. Then, AMS informs (807) the server of the client’s request and determines (808) whether the server is a GRSG; if not, the server returns (809) its binder stub to AMS. Otherwise, when the GRSG serves as a binder server connected with the client, the GRSG also establishes (810) connection with the real gRPC server, and then returns (809) its own binder stub object to the client once its connection with the real gRPC server is established. AMS then passes (811) the returned binder stub to the client. Finally, the client application gets the corresponding binder proxy of GRSG. If any of the steps fails, the GRSG sends (812) a connection failure notification to the client.

As described above, GRSG acts as the relay between the binder client and the gRPC server. It passes the request from the binder client to the gRPC server, and also passes the response from the gRPC server to the binder client. After the binder client has connected to gRPC service, when the client invokes a service method, GRSG’s binder stub will get the corresponding method id and the parcel (which has the method’s input arguments) . Following will discuss how GRSG sends them to the gRPC server, invokes the RPC and gets response.

Reference is now made to FIG. 9, which is a flow chart exemplarily illustrating the method of cross-IPC access according to some embodiments of the disclosure. Such embodiments may be performed by the at least one hardware processor mentioned above. In such embodiments, the at least one hardware processor acquires (901) , through the local proxy, binder request information based on the service request initiated by the application via the binder connection; transmits (903) the binder request information to the second device through the connection established based on the third IPC protocol; receives (905) binder response information from the second device through the connection established based on the third IPC protocol; and generates (907) the service response for being provided to the application.

Reference is now made to FIG. 10, showing an exemplary implementation of the embodiment illustrated by FIG. 9.

As shown in FIG. 10, there is a GRSG component on both client device 1010 and gRPC server device 1020, respectively. The GRSG 1011 on client device 1010 works as a binder server to handle client’s binder call; and the GRSR 1021 on service device 1020 works as a local gRPC client to invoke gRPC call.

The two GRSG components are connected by transport layer (TL) 1030, which passes the RPC information (such as method call id, input parameters, returns, exception and the like) . TL 1030 can be implemented based on any existing protocol. For example, it can be a gRPC connection, REST/HTTP or simple a socket. Following will describe a socket solution.

TL 1030 setups a socket connection between client device 1010 and service device 1020 when a binder client 1012 initiates request to bind gRPC service (described in FIG. 8) . TL 1030 provides an API for client GRSG 1011 to send RPC information; when the API is invoked by the client GRSG 1011, TL 1030 encapsulates the RPC information into packets and sends them to server device 1020. At the server device 1020, TL 1030 waits for the client’s input packets; decapsulates the packets to RPC information, and then transfers it to the server GRSG 1021, which then handles the RPC. After GRSG processing at the gRPC server 1022, the RPC return values are encapsulated into packets and sent back to client GRSG 1011 through the TL socket.

As shown in FIG. 10, GRSG 1021 on server device 1020 includes two major components: protocol adapter (PA) 1023 and plugins 1024. PA 1023 processes the RPC information sent by TL 1030. It loads the plugins 1024 and invokes the real gRPC server 1022’s RPC and finally returns result to client device 1010 through TL 1030.

In some embodiments, PA 1023 is provided with the following data structures and methods to transform a binder call to a gRPC calls:

1) map between binder’s method id and gRPC service’s method id;

2) map between binder’s method id and its parcelable request class and response class;

3) map between gRPC Service’s method id and its request type and response type;

4) map between gRPC Service’s method id and function entrance;

5) the method in generated Parcelable class: Parcelable2ProtoBuf; and

6) the method in generated ProtoBuf message class: ProtoBuf2Parcelable.

Reference is now made to FIG. 11, showing an exemplary development environment of the plugins. Those data structures and methods described above are generated by the revised tool protoc 402 (also referring to FIG. 4) . Because both the parcelable class and protocol buffer class are generated based on the same . proto 401 (also referring to FIG. 4) , the type converter (e.g., items 5 and 6 in above list) can be implemented straightforwardly. Similarly, the new maps (e.g., items 1-4 in above list) mentioned above are easy to generate. The generated codes are built as a Plugin component 1024, which is dynamically loadable library (e.g. a . jar file or a . so file) and to be loaded by PA 1023.

In some embodiments, PA 1023 also works as a gRPC client, which has local gRPC connection with the real gRPC server 1022. Reference is now made to FIG. 12, which is a flow chart exemplarily illustrating steps for establishing the connection between PA 1023 and gRPC server 1022.

As shown in FIG. 12, PA firstly receives (1201) a request from TL, and determines (1202) whether the service's plugin is loaded. If not, PA loads (1203) the service's plugin; otherwise, PA directly unmarshalls (1204) the Parcel to ParcelableClass. Then, PA invokes (1205) its Parcellable2ProtoBuf, which returns the request object. Accordingly, a gRPC method id is obtained from the binder method id and a function entrance is obtained (1206) . Subsequently, PA requests (1207) a response from the gRPC server (response = funcEntrance (request) ) , gets (1208) the response and invoke its ProtoBuf2Parcelable to get the Parcelable response. Finally, PA returns (1209) the marshalled Parcelable response and a success state. If there is an error when requesting the response, PA returns (1210) an error state.

Referring back to FIG. 10, when GRSG 1011 on the client device 1010 receives the response, if it is the success state, GRSG 1011 sends the marshalled response to client 1012 through its binder stub; otherwise GRSG 1011 throws an exception to inform of the remote error state.

Reference is now made to FIG. 13, showing another exemplary implementation of the embodiment illustrated by FIG. 9. When there are multiple clients on different

Android devices

1310 and 1320 accessing the same gRPC server 1330, there are multiple GRSG/TL pairs established. When there are several clients on the same device (e.g., the device 1310) , one GRSG/TL module on the client device is multiplexed by

different clients

1311 and 1312.

Reference is now made to FIG. 14, which is a flow chart exemplarily illustrating the method of cross-IPC access according to some embodiments of the disclosure. Such embodiments may be performed by the at least one hardware processor mentioned above. In such embodiments, the at least one hardware processor acquires (1401) , through the local proxy, binder request information based on the service request initiated by the application via the binder connection; adapts (1403) the binder request information to a gRPC call; transmits (1405) the gRPC call to the second device through the connection established based on gRPC; receives (1407) a gRPC response from the second device through the connection established based on gRPC; adapts (1409) the gPRC response to binder response information; and generates (1411) the service response for being provided to the application.

Reference is now made to FIG. 15, showing an exemplary implementation of the embodiment illustrated by FIG. 14.

As shown in FIG. 15, compared to FIG. 10, there is only a GRSG component on the client device 1510. The GRSG 1512 on client device 1510 works as a binder server to handle client’s binder call and a gRPC client to invoke gRPC call.

As further shown in FIG. 15, compared to FIG. 10, PA 1513 is provided on client device 1510 instead of the server device 1520. When the client 1511 needs to access a new gRPC server, its plugin may be not available locally, GRSG 1512 is to search and download the plugin from either the gRPC server or from a predefined storage.

Another solution does not require to load the plugin, and the PA 1513 can dynamically explore the method information of the gRPC server at runtime. This solution is more flexible and avoids the changes in protoc. This solution assumes the gRPC server has enabled reflection support; and it also assumes the version of the generated binder interface exactly match the version of the gRPC service.

Because the input and response parcels are to be marshalled or unmarshalled in PA 1513, PA 1513 may be implemented in language like C/C++ to manipulate those data structures.

Reference is now made to FIG. 16, showing an exemplary flow chart for establishing the gRPC connection in the embodiment illustrated by FIG. 15. When a binder client initiates request to bind gRPC service, GRSG on the client device starts (1601) to connect the remote gRPC server. Firstly, PA gets (1603) the address (e.g., URL) and port number of the remote server, gets (1605) the client’s credential, and then setups (1607) the gRPC connection with the remote server. Subsequently, PA creates (1609) gRPC sync tub and constructs (1611) the service RPC table, thereby establishing the connection.

In some embodiments, the RPC table has following the information: method ID; method name; element type list for request; and element type list for response.

Because the gRPC server’s reflection has been enabled, PA can query the service information as follows:

After the connection is established between PA and gRPC server, GRSG is able to process the binder call.

Reference is now made to FIG. 17, showing an exemplary flow chart for processing the binder call in the embodiment illustrated by FIG. 15. Firstly, GRSG’s binder stub gets (1701) call id and input parcel, uses (1703) the call id as an index to get the element type list of the request from the RPC table, and reads (1705) out each element value from the input parcel. Then, GRSG constructs (1707) the unary call from the method name and invokes (1709) the unary call with the list of element values of the input type. After getting the response, GRSG uses (1711) the element type list of the response from the RPC table to constructs a response parcel, and returns (1713) the response parcel to the client via binder stub. When there is an error upon invoking the unary call, an exception is thrown (1715) .

When all Android binder clients disconnect, GRSG’s binder stub will get unbound notification. Then it can disconnect the gRPC channel and reclaim the resource.

According to some embodiments of the disclosure, the first IPC is gRPC, the second IPC is binder, and the third IPC is gRPC. In other words, a gRPC client at the first device is to access a binder service at the second device through a gRPC connection.

Reference is now made to FIG. 18, which is a flow chart exemplarily illustrating the method of cross-IPC access according to some embodiments of the disclosure. Such embodiments may be performed by the at least one hardware processor mentioned above. In such embodiments, the at least one hardware processor initiates (1801) , through the connection established based on gRPC, a gRPC call to the second device based on the service request; receives (1803) a gRPC response from the second device through the connection established based on gRPC; and generates (1805) the service response for being provided to the application.

When a gRPC client is to access a binder server, the RPC APIs may be defined by IDL in . proto file as well. The binder server may not transport the objects, which are reference to local resources (e.g., file descriptor, binder objects) , because they are meaningless for gRPC client.

Reference is now made to FIG. 19, showing an exemplary implementation for establishing a connection between a gRPC application and a binder service. GRSG 1922 is on the same device 1920 as the binder server 1921. Its PA 1923 works as a gRPC server. gRPC client 1911 at the client device 1910 talks to the PA 1923’s gRPC server in a normal gRPC way. Meanwhile, PA 1923 loads the plugin 1924 to perform the method and data conversion. Details of the plugin 1923 may refer to the plugin 1024 describe with reference to FIG. 10 and, thus, will not be repeated here for brevity.

Reference is now made to FIG. 20, which is a flow chart exemplarily illustrating steps for communicating between the gRPC application and the binder service.

As shown in FIG. 20, PA firstly determines (2001) whether the service's plugin is loaded. If not, PA loads (2003) the service's plugin; otherwise, PA, serving as the gRPC server directly gets (2005) a gRPC method id and a request object. After that, PA invokes (2007) the request’s ProtoBuf2Parcelable, which gets the parcelable request object; and then marshals it to get the request parcel. Then, PA gets (2009) a binder call id from the gRPC method id and invokes (2011) the binder proxy’s transact (e.g., including method id and request parcel) . Subsequently, PA gets (2013) a response parcel, unmarshalls it to get a response object, invokes (2015) the object’s Parcelable2ProtoBuf to get the ProtoBuf response, and then returns (2017) the gRPC response to the client device. When there is an error upon invoking the binder proxy, PA returns (2019) an error response.

According to some embodiments of the disclosure, the first IPC is binder, the second IPC is binder, and the third IPC is gRPC. In other words, a binder client at the first device is to access a binder service at the second device through a gRPC connection.

Reference is now made to FIG. 21, which is a flow chart exemplarily illustrating the method of cross-IPC access according to some embodiments of the disclosure. Such embodiments may be performed by the at least one hardware processor mentioned above. In such embodiments, the at least one hardware processor acquires (2101) a remote binder call based on the service request initiated by the application; establishes (2103) a gRPC connection between the first device and the second device; and performs (2105) , through the gRPC connection, transmission of the remote binder call to the second device and a remote binder response from the second device.

In some embodiment, the gRPC connection established between the first and second devices include a command channel for transmission of command messages and a data channel for transmission of data messages.

Reference is now made to FIG. 22, showing an exemplary implementation of distributed binder over gRPC.

Android applications

2211 and 2221 on different devices 2210 and 2220 make RPC among each other using distributed binder. Distributed binder may perform transmission of the commands and data between the devices through TL 2230. In some embodiments, the TL 2230 is constructed based on gRPC for distributed binder.

As shown in FIG. 22, each of

GRSG

2212 and 2222 has

binder proxies

2213 and 2223 to handle the RPC called from other devices; and has

binder stubs

2214 and 2224 to forward the RPC towards other devices. All the in/out RPC goes through the TL 2230. The TL 2230 includes two gRPC channels between the pair of Android devices 2210 and 2220: one for command, the other for data.

Command channel 2231 sends commands and responses between the devices 2210 and 2220; it is typically short and needs quick response. The data channel 2232 is to carry relatively bigger data blocks like files. gRPC bidirectional streaming call runs on both channels 2231 and 2232, thereby enabling either side to “push” message to the other side.

On command channel 2231, the gRPC service may be defined as follows:

And on data channel 2232, the gRPC service may be defined as follows:

Because a binder RPC can be initiated from either device and the gRPC channels are to carry binder call information (including call id, parcel, and the like) back and forth, the TL’s gRPC calls may have identical request and response types, part of which is listed as follows.

1) The “isResposne” is to identify whether it is a binder request or a response. If it is true, corresponding request can be identified by the mMessageId.

2) “mServiceId” is to identify different binder services on remote device. “mCodeId” is binder service’s method id. The “mParcel” is the byte array to contain the call’s parcel data.

3) “hasDataMessage” indicates whether the message has an affiliated “BinderDataMessage” , which contains the data blocks as input parameter for the binder call or as returned data blocks in a response.

4) One data block (for example, a file) have a “DataMessage” . The “mName” is optional to name the data; and “mBody” is the byte array having the real data. A “BinderDataMessage” can have multiple “DataMessage” which are indicated by “mPayload” .

5) A “BinderDataMessage” on data channel affiliates a “BinderCommandMessage” . For example, considering a binder call which has a file as an input parameter, when sending the binder call, there are two objects sent out, one is a BinderCommandMessage object which indicate the call id; and the other is a BinderDataMessage object which has an embedded DataMessage object to contain the file. The mMessageId in BinderDataMessage is to associate the BinderCommandMessage.

Accordingly, TL implements the gRPC client and server following the service definition as described above. Furthermore, in some embodiments, TL provides the following generic API for GRSG:

“Int remoteCall (int serviceId, int codeId, byte [] inputparcel, byte [] outputparcel, uri [] inputfiles, uri [] outputfiles) ”

While implementing this API, TL may encapsulate the input parameters (e.g., serviceId, codeId, inputparcel, inputfiles) into BinderCommandMessage or BinderDataMessage (if inputfiles is not empty) ; and unpack the returned messages and return them to caller through the output parameters (e.g., outputparcel, outputfiles) . The API itself returns a status (like non-zero for kinds of errors) .

It is synchronous API, meaning that, when binder stub invokes it, it will block until response comes. TL may support for multiple threads to access this API concurrently and multiplex the command and data channels.

Meanwhile, GRSG may implement the following interface, TL may invoke it when get request message:

“Int processRequest (int serviceId, int codeId, byte [] inputparcel, byte [] outputparcel, uri [] inputfiles, uri [] outputfiles) ”

When TL invokes the interface above, input parameters (e.g., serviceId, codeId, inputparcel and inputfiles) comes from the original request. Since TL has transported the data blocks to current device, the inputfiles are processed and referencing to local valid resource. GRSG implements the API and returns the results through output parameters (e.g., outputparcel, outputfiles) .

When an Android application invokes Android’s binder service to start to binder a remote binder application, TL initiates its gRPC client and setups connection with remote TL gRPC service. This connection is for bidirectional streaming.

When an application makes a binder RPC (e.g., assuming both request and response have data blocks) , GRSG’s corresponding binder stub is invoked and then invokes the remoteCall () API, and block here.

TL composes a command message and a data message, and send them through command channel and data channel, respectively.

On the remote device, after the TL receives the command message and its affiliated data message; it invokes GRSG’s processsRequest () , which then invokes the corresponding binder proxy’s function to make local binder call. After it returns, TL composes a new command message and a new data message as response and sends them back to original device.

The TL on original device is waken up from remoteCall () , receives the response message and its affiliated data message, and then returns to GRSG’s binder stub. Finally, GRSG completes the binder stub call and returns the original binder RPC.

Both distributed binder and gRPC provide applications with the capability of making RPC in a distributed environment. According to some embodiments as described above, the interaction between the two different RPC systems can be supported.

According to some embodiments as described above, there is provided a method for Android applications to use binder RPC to access gRPC services. For example, gRPC services can register in Android system; and applications can bind the gRPC service in the same way as bind to normal Android service. Accordingly, binder application can invoke gRPC service methods through a Protocol Adapter (PA) , which can be implemented in one of the following ways. In the first way, the PA can load plugin component, which has tool generated data structure and methods to facilitate the adaptation, and dynamically transform binder call to gRPC call. In the other way, the PA can read out the gRPC’s service information and make transformation between binder call and gRPC call. Moreover, multiple applications on one device or several different devices can use binder RPC to access one gRPC service on a remote device.

According to some embodiments as described above, there is also provided a method for a gRPC client to access a binder server.

According to some embodiments as described above, there is also provided a method to use gRPC to construct a TL on which applications on different devices can make binder RPC among each other. For example, APIs are exposed from TL to enable distributed binder to operate on the TL, a dedicated gRPC channel is constructed for command transportation, and another dedicated channel is constructed for heavy data. Accordingly, bidirectional streaming gRPC call can carry binder RPC back and forth on the channels.

Above embodiments are described with respect to the client side which invokes a binder/gRPC service. Following will describe embodiments from the aspect of server side which responds to the invoking. Details and examples for implementing the server side may also refer to the forgoing embodiments as described above and, thus, will not be repeated herein for brevity.

Reference is now made to FIG. 23, which is a flow chart exemplarily illustrating a method of cross-IPC access according to some embodiments of the disclosure. Such embodiments may be performed by at least one hardware processor, which is located in a second device provided with a remote service based on a second IPC protocol. In such embodiments, the at least one hardware processor receives (2301) a service request from a first device through a connection established based on a third IPC protocol, wherein the first device is provided with an application based on a first IPC protocol, and the service request is initiated by the application and used for invoking the remote service; and sends (2303) a feedback to the first device in response to an invoking result of the remote device, wherein at least two of the first, second and third protocols are different.

In some embodiments, the first IPC is binder, the second IPC is gRPC, and the method further includes: establishing the connection based on the third IPC protocol between the remote service and a local proxy provided in the first device, wherein the local proxy is used for establishing a binder connection with the application in the first device.

In some embodiments, the service request includes binder request information, and the method further includes: adapting the binder request information to a gRPC call for the remote service; generating a gRPC response in response to the gRPC call; adapting the gRPC response to binder response information serving as the feedback to the first device.

In some embodiments, the third IPC is gRPC, the service request is a gRPC call, and the method further includes: generating, in response to the gRPC call, a gRPC response serving as the feedback to the first device. Further in some embodiments, the method further includes: sending mapping information to the first device, wherein the mapping information is used by the first device for adapting binder request information to the gRPC call and/or adapting the gPRC response to binder response information.

In some embodiments, the first IPC is gRPC, the second IPC is binder, the third IPC is gRPC, the service request is a gRPC call, and the method further includes: adapting the gRPC call to a binder call for the remote service; generating a binder response in response to the binder call; and adapting the binder response to a gRPC response serving as the feedback to the first device.

In some embodiments, the first IPC is binder, the second IPC is binder, the third IPC is gRPC, and the method further includes: establishing a gRPC connection between the second device and the first device; and perform, through the gRPC connection, transmission of a remote binder call from the first device and a remote binder response to the first device. Further in some embodiments, the establishing the gRPC connection includes: establishing a command channel for transmission of command messages and a data channel for transmission of data messages.

Following will describe embodiments from the aspect of an apparatus for implementing the client side which invokes a binder/gRPC service. Details and examples for implementation of the apparatus may also refer to the first device in the forgoing embodiments as described above and, thus, will not be repeated herein for brevity.

Reference is now made to FIG. 24, which is a block diagram exemplarily illustrating an apparatus of cross-IPC access according to some embodiments of the disclosure. The apparatus is implemented as the first device provided with the application based on the first IPC protocol, and includes: an initiation module 2410, configured to receive a service request initiated by the application, wherein the service request is used for invoking a remote service provided by a second device based on a second IPC protocol; a transmission module 2420, configured to transmit the service request to the second device through a connection established based on a third IPC protocol; and a receiving module 2430, configured to provide the application with a service response based on a feedback from the second device, wherein at least two of the first, second and third protocols are different.

In some embodiments, the first IPC is binder, the second IPC is gRPC, and the apparatus further includes: a storage module, configured to store registration information of the remote service, wherein the registration information is used for indicating a local proxy of the remote service; an establishing module, configured to retrieve the registration information in response to the service request initiated by the application; establish, based on the registration information, a binder connection between the application and the local proxy; and establish the connection based on the third IPC protocol between the local proxy and the remote service.

In some embodiments, the first device is an Android device, and the storage module is configured to store the registration information in remote manager service (RMS) separately from package manager service (PMS) of the Android device, the initiation module 2410 is configured to receive, through activity manager service (AMS) , the service request initiated by the application; and determine, through the PMS, that the service request is used for invoking the remote service; and the establishing module is configured to retrieve, through the RMS, the registration information of the remote service for being returned to the AMS.

In some embodiments, the transmission module 2420 is configured to: acquire, through the local proxy, binder request information based on the service request initiated by the application via the binder connection; and transmit the binder request information to the second device through the connection established based on the third IPC protocol.

In some embodiments, the receiving module 2430 is configured to: receive binder response information from the second device through the connection established based on the third IPC protocol; and generate the service response for being provided to the application.

In some embodiments, the third IPC is gRPC, and the transmission module 2420 is configured to: acquire, through the local proxy, binder request information based on the service request initiated by the application via the binder connection; adapt the binder request information to a gRPC call; and transmit the gRPC call to the second device through the connection established based on gRPC.

In some embodiments, the receiving module 2430 is configured to: receive a gRPC response from the second device through the connection established based on gRPC; adapt the gPRC response to binder response information; and generate the service response for being provided to the application.

In some embodiments, the apparatus further includes an acquiring module, configured to acquire, through the local proxy, mapping information by retrieving a local storage or dynamically accessing the second device, wherein the mapping information is used for adapting the binder request information to the gRPC call and/or adapting the gPRC response to the binder response information.

In some embodiments, the registration information includes at least part of following information: an address and a port number for accessing the remote service; a service name of the remote service; and call options of the remote service.

In some embodiments, the first IPC is gRPC, the second IPC is binder, the third IPC is gRPC, and the transmission module 2420 is configured to: initiate, through the connection established based on gRPC, a gRPC call to the second device based on the service request.

In some embodiments, the receiving module 2430 is configured to: receive a gRPC response from the second device through the connection established based on gRPC; and generate the service response for being provided to the application.

In some embodiments, the first IPC is binder, the second IPC is binder, the third IPC is gRPC, the initiation module 2410 is further configured to acquire a remote binder call based on the service request initiated by the application; the transmission module 2420 is further configured to establish a gRPC connection between the first device and the second device; and perform, through the gRPC connection, transmission of the remote binder call to the second device and a remote binder response from the second device.

In some embodiments, the transmission module 2420 is configured to establish a command channel for transmission of command messages and a data channel for transmission of data messages.

Following will describe embodiments from the aspect of an apparatus for implementing the server side which responds to the invoking of a binder/gRPC service. Details and examples for implementation of the apparatus may also refer to the second device in the forgoing embodiments as described above and, thus, will not be repeated herein for brevity.

Reference is now made to FIG. 25, which is a block diagram exemplarily illustrating an apparatus of cross-IPC access according to some embodiments of the disclosure. The apparatus is implemented as the second device provided with the remote service based on the second IPC protocol, and includes: a receiving module 2510, configured to receive a service request from a first device through a connection established based on a third IPC protocol, wherein the first device is provided with an application based on a first IPC protocol, and the service request is initiated by the application and used for invoking the remote service; and a sending module 2520, configured to send a feedback to the first device in response to an invoking result of the remote device, wherein at least two of the first, second and third protocols are different.

In some embodiments, the first IPC is binder, the second IPC is gRPC, and the apapratus further includes: an establishing module, configured to establish the connection based on the third IPC protocol between the remote service and a local proxy provided in the first device, wherein the local proxy is used for establishing a binder connection with the application in the first device.

In some embodiments, the service request includes binder request information, and the apparatus further includes: a proxy module, configured to adapt the binder request information to a gRPC call for the remote service; generate a gRPC response in response to the gRPC call; and adapt the gRPC response to binder response information serving as the feedback to the first device.

In some embodiments, the third IPC is gRPC, the service request is a gRPC call, and the sending module 2520 is configured to: generate, in response to the gRPC call, a gRPC response serving as the feedback to the first device.

In some embodiments, the sending module 2520 is further configured to: send mapping information to the first device, wherein the mapping information is used by the first device for adapting binder request information to the gRPC call and/or adapting the gPRC response to binder response information.

In some embodiments, the first IPC is gRPC, the second IPC is binder, the third IPC is gRPC, the service request is a gRPC call, and the apparatus further includes: a proxy module, configured to adapt the gRPC call to a binder call for the remote service; generate a binder response in response to the binder call; and adapt the binder response to a gRPC response serving as the feedback to the first device.

In some embodiments, the first IPC is binder, the second IPC is binder, the third IPC is gRPC, and the apparatus further includes: an establishing module, configured to establish a gRPC connection between the second device and the first device; and perform, through the gRPC connection, transmission of a remote binder call from the first device and a remote binder response to the first device.

In some embodiments, the establishing module is configured to establish command channel for transmission of command messages and a data channel for transmission of data messages.

FIG. 26 is a block diagram illustrating a cross-IPC accessing device 2600 according to some embodiments of the application. The cross-IPC accessing device 2600 shown in FIG. 26 includes a processor 2610, which can call and run a computer program from a memory to implement the method according to the embodiments of the application.

Optionally, as shown in FIG. 26, the cross-IPC accessing device 2600 may further include a memory 2620. The processor 2610 may call and run the computer program from the memory 2620 to implement the method according to the embodiments of the application.

The memory 2620 may be a separate device independent of the processor 2610, or may be integrated in the processor 2610.

Optionally, as shown in FIG. 26, the cross-IPC accessing device 2600 may further include a transceiver 2630, and the processor 2610 may control the transceiver 2630 to communicate with other devices. Specifically, it may send information or data to other devices, or receive other information, data sent by the device.

The transceiver 2630 may include a transmitter and a receiver. The transceiver 2630 may further include antennas, and the number of antennas may be one or more.

FIG. 27 is a block diagram illustrating a chip according to some embodiments of the application. The chip 2700 shown in FIG. 27 includes a processor 2710, which can call and run a computer program from a memory to implement the method according to the embodiments of the application.

Optionally, as shown in FIG. 27, the chip 2700 may further include a memory 2720. The processor 2710 may call and run the computer program from the memory 2720 to implement the method according to the embodiments of the application.

The memory 2720 may be a separate device independent of the processor 2710, or may be integrated in the processor 2710.

Optionally, the chip 2700 may further include an input interface 2730. The processor 2710 may control the input interface 2730 to communicate with other devices or chips. Specifically, the processor 2710 may acquire information or data sent by other devices or chips.

Optionally, the chip 2700 may further include an output interface 2740. The processor 2710 may control the output interface 2740 to communicate with other devices or chips. Specifically, the processor 2710 may output information or data to the other devices or chips.

Optionally, the chip can be applied to the first/second device according to the embodiments of the application, and the chip can implement the corresponding process implemented by first/second device in the method according to the embodiments of the application. For brevity, details are not described herein.

It should be understood that the chip mentioned in some embodiments of the application may also be referred to as a system-level chip, a system chip, a chip system or a system-on-chip.

It should be understood that the processor in the embodiments of the disclosure may be an integrated circuit chip with signal processing capability. In the implementation process, the steps of the foregoing method embodiments can be completed by hardware integrated logic circuits in the processor or instructions in the form of software. The processor mentioned in some embodiments of the application may be a general-purpose processor, a digital signal processor (DSP) , an application specific integrated circuit (ASIC) , a field programmable gate array (FPGA) , or other programming logic devices, discrete gate or transistor logic devices, discrete hardware components, which can achieve or implement the methods, steps and block diagrams disclosed in embodiments of the disclosure. The general-purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of the method disclosed in the embodiments of the disclosure may be directly embodied as being executed and completed by a hardware decoding processor, or executed and completed by a combination of hardware and software modules in the decoding processor. The software module can be located in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, or electrically erasable programmable memory, registers. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.

The memory mentioned in some embodiments of the application may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memory. In some embodiments, the non-volatile memory may be read-only memory (ROM) , programmable read-only memory (PROM) , erasable programmable read-only memory (erasable PROM, EPROM) , electrical memory erasable programmable read-only memory (EPROM, EEPROM) or flash memory. The volatile memory may be a random access memory (RAM) , which is used as an external cache. By way of exemplary but not restrictive illustration, many forms of RAM are available, for example, static random access memory (static RAM, SRAM) , a dynamic random access memory (dynamic RAM, DRAM) , synchronous dynamic random access memory (synchronous DRAM, SDRAM) , double data rate synchronous dynamic random access memory (double data rate SDRAM, DDR SDRAM) , enhanced synchronous dynamic random access memory (enhanced SDRAM, ESDRAM) , synch link dynamic random access memory (synch link DRAM, SLDRAM) , and direct Rambus random access memory (direct Rambus RAM, DR RAM) and so on. It should be noted that the memories in the systems and methods described herein are intended to include, but are not limited to, these and any other suitable types of memories.

It should be understood that the foregoing memories are exemplary but not restrictive. For example, the memory in the embodiments of the disclosure may also be static random access memory (static RAM, SRAM) , dynamic random access memory (dynamic RAM, DRAM) , Synchronous dynamic random access memory (synchronous DRAM, SDRAM) , double data rate synchronous dynamic random access memory (double data rate SDRAM, DDR SDRAM) , enhanced synchronous dynamic random access memory (enhanced SDRAM, ESDRAM) , synchronous connection Dynamic random access memory (synch link DRAM, SLDRAM) and direct memory bus random access memory (Direct Rambus RAM, DR RAM) , and the like. In other words, the memory in the embodiments of the disclosure is intended to include, but is not limited to, these and any other suitable types of memory.

Embodiments of the disclosure further provide a computer readable storage medium, which is configured to store a computer program.

Optionally, the computer readable storage medium may be applied to the network device in some embodiments of the application, and the computer program causes the computer to execute the corresponding process implemented by the network device in each method in some embodiments of the application. For the sake of brevity, details will not be repeated here.

Optionally, the computer readable storage medium may be applied to the computer/mobile terminal/terminal device in some embodiments of the application, and the computer program causes the computer to execute the corresponding process implemented by the computer/mobile terminal/terminal device in each method in some embodiments of the application. For the sake of brevity, details will not be repeated here.

A computer program product is also provided in some embodiments of the application, including computer program instructions.

Optionally, the computer program product can be applied to the first/second device in some embodiments of the application, and the computer program instruction causes the computer to execute a corresponding process implemented by the first/second device in each method in some embodiments of the application. For the sake of brevity, details will not be repeated here.

Optionally, the computer program product can be applied to the computer/mobile terminal/terminal device, and the computer program instruction causes the computer/mobile terminal/terminal device to execute a corresponding process implemented by the first/second device in each method in some embodiments of the application. For the sake of brevity, details will not be repeated here.

A computer program is also provided in some embodiments of the application.

Optionally, the computer program may be applied to the first/second device in some embodiments of the application. When the computer program is run on a computer, the computer is caused to execute a corresponding process implemented by the first/second device in each method in some embodiments of the application. For the sake of brevity, details will not be repeated here.

Optionally, the computer program may be applied to the computer/mobile terminal/terminal device in some embodiments of the application. When the computer program is run on the computer/mobile terminal/terminal device, the computer/mobile terminal/terminal device is caused to execute a corresponding process implemented by the first/second device in each method in some embodiments of the application. For the sake of brevity, details will not be repeated here.

Those of ordinary skill in the art may realize that the units and algorithm steps of each example described in connection with the embodiments disclosed herein can be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Those of ordinary skill in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices, and units described above can refer to the corresponding processes in the foregoing method embodiments, and are not repeated here.

In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods may be implemented in other ways. For example, the device embodiments as described above are only exemplary. For example, the division of the units is only a logical function division, and there may be other divisions in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not carried out. In addition, the displayed or discussed mutual coupling or direct coupling or communication connection may be indirect coupling or communication connection through some interfaces, devices or units, and may be in electrical, mechanical or other forms.

The units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the objectives of the solutions of the embodiments.

In addition, the functional units in the various embodiments of the disclosure may be integrated into one processing unit, or each unit may exist alone physically, or two or more units may be integrated into one unit.

If the functions are implemented in the form of software functional units and sold or used as an independent product, they can be stored in a computer-readable storage medium. Based on this understanding, an essential part of the technical solution of this application or, in other words, a part thereof that contributes to existing technology, or other parts of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions used for causing a computer device (which may be a personal computer, a server, or a network device, and the like) to perform all or part of the steps of the method described in some embodiments of the application. The foregoing storage medium includes various medium that can store program codes, such as a U disk, a mobile hard disk, a ROM, a RAM, a magnetic disk, or an optical disk.

The above content is only a specific implementation of the embodiments of the application, without limiting the protection scope of the embodiments of the application. Any modification or replacement conceived by those skilled in the art within the technical scope disclosed in some embodiments of the application should be covered within the protection scope of the embodiments of the application. Therefore, the protection scope of the embodiments of the application shall be subject to the protection scope of the claims.

Claims

A method of cross inter-process communication (IPC) access, implemented by a first device provided with an application based on a first IPC protocol, comprising:

receiving a service request initiated by the application, wherein the service request is used for invoking a remote service provided by a second device based on a second IPC protocol;

transmitting the service request to the second device through a connection established based on a third IPC protocol; and

providing the application with a service response based on a feedback from the second device,

wherein at least two of the first, second and third protocols are different.
The method of claim 1, wherein the first IPC is binder, the second IPC is gRPC, and the method further comprises:

storing registration information of the remote service, wherein the registration information is used for indicating a local proxy of the remote service;

retrieving the registration information in response to the service request initiated by the application;

establishing, based on the registration information, a binder connection between the application and the local proxy; and

establishing the connection based on the third IPC protocol between the local proxy and the remote service.
The method of claim 2, wherein the first device is an Android device, and the storing registration information of the remote service comprises:

storing the registration information in remote manager service (RMS) separately from package manager service (PMS) of the Android device,

the method further comprises:

receiving, through activity manager service (AMS) , the service request initiated by the application;

determining, through the PMS, that the service request is used for invoking the remote service; and

retrieving, through the RMS, the registration information of the remote service for being returned to the AMS.
The method of claim 2, wherein the transmitting the service request to the second device through the connection established based on the third IPC protocol comprises:

acquiring, through the local proxy, binder request information based on the service request initiated by the application via the binder connection; and

transmitting the binder request information to the second device through the connection established based on the third IPC protocol.
The method of claim 4, further comprising:

receiving binder response information from the second device through the connection established based on the third IPC protocol; and

generating the service response for being provided to the application.
The method of claim 2, wherein the third IPC is gRPC, and the transmitting the service request to the second device through the connection established based on the third IPC protocol comprises:

acquiring, through the local proxy, binder request information based on the service request initiated by the application via the binder connection;

adapting the binder request information to a gRPC call; and

transmitting the gRPC call to the second device through the connection established based on gRPC.
The method of claim 6, further comprising:

receiving a gRPC response from the second device through the connection established based on gRPC;

adapting the gPRC response to binder response information; and

generating the service response for being provided to the application.
The method of claim 6 or 7, further comprising:

acquiring, through the local proxy, mapping information by retrieving a local storage or dynamically accessing the second device, wherein the mapping information is used for adapting the binder request information to the gRPC call and/or adapting the gPRC response to the binder response information.
The method of any one of claims 2 to 8, wherein the registration information comprises at least part of following information: an address and a port number for accessing the remote service; a service name of the remote service; and call options of the remote service.
The method of claim 1, wherein the first IPC is gRPC, the second IPC is binder, the third IPC is gRPC, and the transmitting the service request to the second device through the connection established based on the third IPC protocol comprises:

initiating, through the connection established based on gRPC, a gRPC call to the second device based on the service request.
The method of claim 10, further comprising:

receiving a gRPC response from the second device through the connection established based on gRPC; and

generating the service response for being provided to the application.
The method of claim 1, wherein the first IPC is binder, the second IPC is binder, the third IPC is gRPC, and the method further comprises:

acquiring a remote binder call based on the service request initiated by the application;

establishing a gRPC connection between the first device and the second device; and

perform, through the gRPC connection, transmission of the remote binder call to the second device and a remote binder response from the second device.
The method of claim 12, wherein the establishing the gRPC connection comprises:

establishing a command channel for transmission of command messages and a data channel for transmission of data messages.
A method of cross-IPC access, implemented by a second device provided with a remote service based on a second IPC protocol, comprising:

receiving a service request from a first device through a connection established based on a third IPC protocol, wherein the first device is provided with an application based on a first IPC protocol, and the service request is initiated by the application and used for invoking the remote service; and

sending a feedback to the first device in response to an invoking result of the remote device,

wherein at least two of the first, second and third protocols are different.
The method of claim 14, wherein the first IPC is binder, the second IPC is gRPC, and the method further comprises:

establishing the connection based on the third IPC protocol between the remote service and a local proxy provided in the first device, wherein the local proxy is used for establishing a binder connection with the application in the first device.
The method of claim 15, wherein the service request comprises binder request information, and the method further comprises:

adapting the binder request information to a gRPC call for the remote service;

generating a gRPC response in response to the gRPC call;

adapting the gRPC response to binder response information serving as the feedback to the first device.
The method of claim 15, wherein the third IPC is gRPC, the service request is a gRPC call, and the method further comprises:

generating, in response to the gRPC call, a gRPC response serving as the feedback to the first device.
The method of claim 17, further comprising:

sending mapping information to the first device, wherein the mapping information is used by the first device for adapting binder request information to the gRPC call and/or adapting the gPRC response to binder response information.
The method of claim 14, wherein the first IPC is gRPC, the second IPC is binder, the third IPC is gRPC, the service request is a gRPC call, and the method further comprises:

adapting the gRPC call to a binder call for the remote service;

generating a binder response in response to the binder call; and

adapting the binder response to a gRPC response serving as the feedback to the first device.
The method of claim 14, wherein the first IPC is binder, the second IPC is binder, the third IPC is gRPC, and the method further comprises:

establishing a gRPC connection between the second device and the first device; and

perform, through the gRPC connection, transmission of a remote binder call from the first device and a remote binder response to the first device.
The method of claim 20, wherein the establishing the gRPC connection comprises:

establishing a command channel for transmission of command messages and a data channel for transmission of data messages.
An apparatus of cross-IPC access, implemented as a first device provided with an application based on a first IPC protocol, comprising:

an initiation module, configured to receive a service request initiated by the application, wherein the service request is used for invoking a remote service provided by a second device based on a second IPC protocol;

a transmission module, configured to transmit the service request to the second device through a connection established based on a third IPC protocol; and

a receiving module, configured to provide the application with a service response based on a feedback from the second device,

wherein at least two of the first, second and third protocols are different.
The apparatus of claim 22, wherein the first IPC is binder, the second IPC is gRPC, and the apparatus further comprises:

a storage module, configured to store registration information of the remote service, wherein the registration information is used for indicating a local proxy of the remote service;

an establishing module, configured to retrieve the registration information in response to the service request initiated by the application; establish, based on the registration information, a binder connection between the application and the local proxy; and establish the connection based on the third IPC protocol between the local proxy and the remote service.
The apparatus of claim 23, wherein the first device is an Android device, and the storage module is configured to store the registration information in remote manager service (RMS) separately from package manager service (PMS) of the Android device,

the initiation module is configured to receive, through activity manager service (AMS) , the service request initiated by the application; and determine, through the PMS, that the service request is used for invoking the remote service; and

the establishing module is configured to retrieve, through the RMS, the registration information of the remote service for being returned to the AMS.
The apparatus of claim 23, wherein the transmission module is configured to:

acquire, through the local proxy, binder request information based on the service request initiated by the application via the binder connection; and

transmit the binder request information to the second device through the connection established based on the third IPC protocol.
The apparatus of claim 25, wherein the receiving module is configured to:

receive binder response information from the second device through the connection established based on the third IPC protocol; and

generate the service response for being provided to the application.
The apparatus of claim 23, wherein the third IPC is gRPC, and the transmission module is configured to:

acquire, through the local proxy, binder request information based on the service request initiated by the application via the binder connection;

adapt the binder request information to a gRPC call; and

transmit the gRPC call to the second device through the connection established based on gRPC.
The apparatus of claim 27, wherein the receiving module is configured to:

receive a gRPC response from the second device through the connection established based on gRPC;

adapt the gPRC response to binder response information; and

generate the service response for being provided to the application.
The apparatus of claim 27 or 28, further comprising:

an acquiring module, configured to acquire, through the local proxy, mapping information by retrieving a local storage or dynamically accessing the second device, wherein the mapping information is used for adapting the binder request information to the gRPC call and/or adapting the gPRC response to the binder response information.
The apparatus of any one of claims 23 to 29, wherein the registration information comprises at least part of following information: an address and a port number for accessing the remote service; a service name of the remote service; and call options of the remote service.
The apparatus of claim 22, wherein the first IPC is gRPC, the second IPC is binder, the third IPC is gRPC, and the transmission module is configured to:

initiate, through the connection established based on gRPC, a gRPC call to the second device based on the service request.
The apparatus of claim 31, wherein the receiving module is configured to:

receive a gRPC response from the second device through the connection established based on gRPC; and

generate the service response for being provided to the application.
The apparatus of claim 22, wherein the first IPC is binder, the second IPC is binder, the third IPC is gRPC,

the initiation module is further configured to acquire a remote binder call based on the service request initiated by the application;

the transmission module is further configured to establish a gRPC connection between the first device and the second device; and perform, through the gRPC connection, transmission of the remote binder call to the second device and a remote binder response from the second device.
The apparatus of claim 33, wherein the transmission module is configured to establish a command channel for transmission of command messages and a data channel for transmission of data messages.
An apparatus of cross-IPC access, implemented as a second device provided with a remote service based on a second IPC protocol, comprising:

a receiving module, configured to receive a service request from a first device through a connection established based on a third IPC protocol, wherein the first device is provided with an application based on a first IPC protocol, and the service request is initiated by the application and used for invoking the remote service; and

a sending module, configured to send a feedback to the first device in response to an invoking result of the remote device,

wherein at least two of the first, second and third protocols are different.
The apparatus of claim 35, wherein the first IPC is binder, the second IPC is gRPC, and the apparatus further comprises:

an establishing module, configured to establish the connection based on the third IPC protocol between the remote service and a local proxy provided in the first device, wherein the local proxy is used for establishing a binder connection with the application in the first device.
The apparatus of claim 36, wherein the service request comprises binder request information, and the apparatus further comprises:

a proxy module, configured to adapt the binder request information to a gRPC call for the remote service; generate a gRPC response in response to the gRPC call; and adapt the gRPC response to binder response information serving as the feedback to the first device.
The apparatus of claim 36, wherein the third IPC is gRPC, the service request is a gRPC call, and the sending module is configured to:

generate, in response to the gRPC call, a gRPC response serving as the feedback to the first device.
The apparatus of claim 38, wherein the sending module is further configured to:

send mapping information to the first device, wherein the mapping information is used by the first device for adapting binder request information to the gRPC call and/or adapting the gPRC response to binder response information.
The apparatus of claim 35, wherein the first IPC is gRPC, the second IPC is binder, the third IPC is gRPC, the service request is a gRPC call, and the apparatus further comprises:

a proxy module, configured to adapt the gRPC call to a binder call for the remote service; generate a binder response in response to the binder call; and adapt the binder response to a gRPC response serving as the feedback to the first device.
The apparatus of claim 35, wherein the first IPC is binder, the second IPC is binder, the third IPC is gRPC, and the apparatus further comprises:

an establishing module, configured to establish a gRPC connection between the second device and the first device; and perform, through the gRPC connection, transmission of a remote binder call from the first device and a remote binder response to the first device.
The apparatus of claim 41, wherein the establishing module is configured to establish command channel for transmission of command messages and a data channel for transmission of data messages.
A device of cross-IPC access, comprising a processor and a memory, wherein the memory is configured to store a computer program, and the processor is configured to call and run the computer program stored in the memory, thereby implementing the method according to any one of claims 1 to 21.
A chip, comprising a processor, wherein the processor is configured to call and run a computer program from a memory, thereby causing an apparatus provided with the chip to implement the method according to any one of claims 1 to 21.
A non-transitory computer readable storage medium, being used for storing a computer program, wherein the computer program causes a computer to implement the method according to any one of claims 1 to 21.
A computer program product, comprising computer program instructions that cause a computer to implement the method according to any one of claims 1 to 21.
A computer program, causing a computer to implement the method according to any one of claims 1 to 21.