Inter-core communication method and apparatus, electronic device, and storage medium

Abstract

The application provides a method and device for inter-core communication, an electronic device and a storage medium. The method comprises the following steps: obtaining a service call request sent by a second electronic device; querying a second processor to which a target service to be called belongs in a first electronic device according to identification information of the target service to be called carried in the service call request; calling an inter-core communication subclass corresponding to a management service in the first processor; sending the service call request to the target service in the second processor; calling the inter-core communication subclass; and obtaining a service call result obtained by the target service based on the service call request. An interface in the inter-core communication subclass is fused with a heterogeneous multi-core standard interface and an interface of an Android device basic communication component RPC, the capability of the device basic communication component RPC is enhanced, the service call capability between the heterogeneous multi-cores is completed based on the fusion of the existing interfaces, a separate custom interface is not required, the development efficiency is improved, and better universality is achieved.

Description

Technical Field

[0001] This application relates to the field of wireless communication technology, and in particular to an inter-core communication method, apparatus, electronic device, and storage medium. Background Technology

[0002] With the development of electronic technology, heterogeneous multi-core processors (CPUs) are built into electronic devices. These processors typically run multiple different operating systems and work together to achieve higher overall performance.

[0003] In related technologies, communication between heterogeneous multi-core processors usually involves developing their own communication mechanisms. These mechanisms are closed, meaning they are only applicable to specific operating systems, making them difficult to develop and lacking in versatility. Summary of the Invention

[0004] This application aims to at least partially address one of the technical problems in the related art.

[0005] To this end, this application proposes an inter-core communication method, device, electronic device, and storage medium. The inter-core communication subclass is based on the RpMsg Socket communication method and inherits the native Android system's RPC Binder interface. When performing inter-core communication, the RPC Binder interface can be directly called to realize the transmission of inter-core data, thereby improving versatility.

[0006] One embodiment of this application proposes an inter-core communication method applied to a first processor in a first electronic device, the method comprising:

[0007] Obtain the service call request sent by the second electronic device;

[0008] Based on the identification information of the target service to be invoked carried in the service invocation request, query the second processor to which the target service to be invoked belongs in the first electronic device;

[0009] The inter-core communication subclass corresponding to the management service in the first processor is invoked to send the service call request to the target service in the second processor; the inter-core communication subclass inherits the interface of RPCBinder, the inter-process communication of remote procedure calls, and the interface of RpMsg, the inter-core communication standard.

[0010] Invoke the inter-core communication subclass to obtain the service call result obtained by the target service based on the service call request.

[0011] Another embodiment of this application proposes an inter-core communication device, in which a first processor disposed in a first electronic device includes:

[0012] The first acquisition module is used to acquire service call requests sent by the second electronic device;

[0013] The query module is used to query the second processor in the first electronic device to which the target service to be called belongs, based on the identification information of the target service to be called carried in the service call request.

[0014] The sending module is used to call the inter-core communication subclass corresponding to the management service in the first processor to send the service call request to the target service in the second processor; the inter-core communication subclass inherits the interface of the remote procedure call inter-process communication RPC Binder and the interface of the inter-core communication standard RpMsg.

[0015] The second acquisition module is used to call the inter-core communication subclass to obtain the service call result obtained by the target service based on the service call request.

[0016] Another embodiment of this application provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, it implements the method described in the foregoing aspect.

[0017] Another embodiment of this application proposes a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in the foregoing aspect.

[0018] Another embodiment of this application proposes a computer program product having a computer program stored thereon, which, when executed by a processor, implements the method described in the foregoing aspect.

[0019] The inter-core communication method, apparatus, electronic device, and storage medium proposed in this application acquire a service call request sent by a second electronic device. Based on the identifier information of the target service to be called carried in the service call request, the method queries the second processor to which the target service belongs in the first electronic device. It then calls the inter-core communication subclass corresponding to the management service in the first processor, sends the service call request to the target service in the second processor, calls the inter-core communication subclass again, and obtains the service call result obtained by the target service based on the service call request. The relevant interfaces in the inter-core communication subclass RpMsgsockeadress corresponding to the management service integrate the heterogeneous multi-core RpMsg standard interface and the interface of the Android electronic device basic communication component RPCBinder, enhancing the RPC capabilities of the electronic device's basic communication component. Furthermore, by integrating existing interfaces to complete the service call capability between heterogeneous multi-core devices, it eliminates the need for separately customized interfaces, improving development efficiency and providing better versatility.

[0020] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0021] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein:

[0022] Figure 1 A flowchart illustrating an inter-core communication method provided in an embodiment of this application;

[0023] Figure 2 A flowchart illustrating another inter-core communication method provided in an embodiment of this application;

[0024] Figure 3 A schematic diagram of a communication scenario provided in an embodiment of this application.

[0025] Figure 4A A schematic diagram of an inter-core communication architecture provided for an embodiment of this application;

[0026] Figure 4B This is a schematic diagram of the underlying implementation of inter-core communication in an embodiment of this application;

[0027] Figure 5 This application provides a schematic diagram of an inter-core communication scenario.

[0028] Figure 6 This is a schematic diagram of the structure of an inter-core communication device provided in an embodiment of this application;

[0029] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0030] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0031] The following description, with reference to the accompanying drawings, describes an inter-core communication method, apparatus, electronic device, and storage medium according to embodiments of this application.

[0032] Figure 1 This is a flowchart illustrating an inter-core communication method provided in an embodiment of this application.

[0033] The execution subject of the inter-core communication method in this application embodiment is an inter-core communication device. This device can be located in a processor of a first electronic device including a multi-core processor, referred to as the first processor. The electronic device can be a smartphone, a smart wearable device, a handheld computer, a desktop computer, etc., and is not limited in this embodiment.

[0034] like Figure 1 As shown, the method may include the following steps:

[0035] Step 101: Obtain the service call request sent by the second electronic device.

[0036] In one implementation of this application, the multi-core processor in the first electronic device includes at least two processors, each with one processor core. Each processor is capable of executing different tasks simultaneously.

[0037] The second electronic device is different from the first electronic device. An application on the second electronic device needs to call a service within an application on the first electronic device. For example, if the first electronic device is a computer and the second is a mobile phone, the service to be called is a function within the application. A service call request is a request to call a service on a processor other than the first processor on the first electronic device. It carries the identification information of the service to be called, such as the service's port number (Port A), and the data or operation requested from the service. One implementation method is based on Android's RPC InetSocket, which allows the remote second electronic device to send the service call request to the first processor of the first electronic device, achieving communication between remote devices. The RPC InetSocket method locates the electronic device to which the service belongs by using the device's IP address and the service's port number. RPC (Remote Procedure Call) refers to the mechanism by which operating systems on processors running on different devices communicate to complete procedure calls. InetSocket is an IP socket that locates the target service on the target device by using the device's IP address and the service's port number.

[0038] Step 102: Based on the identification information of the target service to be invoked carried in the service invocation request, query the second processor to which the target service to be invoked belongs in the first electronic device.

[0039] In this embodiment, the multi-core processor system of the first device includes multiple services, which are deployed on different processors. For ease of management, a main processor is set up among the multiple processors, and a management service is set up in the main processor. The management service is used to manage all services in the first device. As one implementation, the management service maintains the identification information of each service and the correspondence between the processor to which each service belongs. Thus, when the identification information of the target service to be called is obtained, the processor to which the target service belongs can be queried. Since the processors included in the first device can be determined, it can be determined whether the target service belongs to other processors besides the first processor, thereby determining whether it is a service call between different processors in the first electronic device, that is, whether it belongs to inter-core communication.

[0040] Step 103: Invoke the inter-core communication subclass corresponding to the management service in the first processor and send the service call request to the target service in the second processor.

[0041] In this embodiment, if it is determined that the target service to be invoked belongs to the second processor among multiple processors of the first electronic device, and it is also determined that the current service call belongs to a call between different processors within the same electronic device, i.e., inter-core communication, then the relevant interface in the inter-core communication subclass RpMsg Socke Address corresponding to the management service is invoked to send the service call request to the target service in the second processor. This allows the target service in the second processor to generate a service call result based on the action or task requested to be performed by the target service carried in the service call request. As one implementation, the connection interface in the inter-core communication subclass corresponding to the management service is invoked to establish an RpMsg connection between the management service and the target service. Then, the data sending interface in the inter-core communication subclass corresponding to the management service is invoked to send the service call request to the target service in the second processor.

[0042] The inter-core communication subclass, RpMsg Socket Address, conforms to the RpMsg inter-core communication standard. RpMsg stands for Remote Processor Messaging, which defines the standard binary interface used for communication between cores in an Asymmetric Multiprocessing (AMP) system. This subclass is based on the RpMsg Socket communication standard and inherits the interface of the Remote Procedure Call (RPC) Binder. In other words, the relevant interfaces in the RpMsg SockeAdress subclass of the management service integrate the heterogeneous multi-core RpMsg standard interface and the Android device basic communication component RPC interface to complete the service call capability between heterogeneous multi-cores, enhance the capability of the Android device basic communication component RPC, and based on the integration of existing interfaces, there is no need to customize interfaces separately, which improves the universality of the interfaces used, improves development efficiency, and has better versatility. In addition, it provides a new approach to the use of the native heterogeneous multi-core RpMsg standard interface in AndroidBinder.

[0043] Step 104: Call the inter-core communication subclass to obtain the service call result obtained by the target service based on the service call request.

[0044] In this embodiment of the application, the data receiving interface in the inter-core communication subclass is called to receive the service call result sent by the target service, thereby realizing the inter-core communication between different processors inside the first electronic device. This inter-core communication method is also known as CPC (Cross-PE Communication), which refers to the mechanism of communication between different processors on a single device to complete the procedure call.

[0045] In the inter-core communication method of this application embodiment, a service call request sent by a second electronic device is obtained. Based on the identifier information of the target service to be called carried in the service call request, the second processor to which the target service to be called belongs in the first electronic device is queried. The inter-core communication subclass corresponding to the management service in the first processor is called, and the service call request is sent to the target service in the second processor. The inter-core communication subclass is then called to obtain the service call result obtained by the target service based on the service call request. The relevant interfaces in the inter-core communication subclass RpMsg Socke Address corresponding to the management service integrate the heterogeneous multi-core RpMsg standard interface and the interface of the Android device basic communication component RPC Binder, enhancing the capabilities of the Android device basic communication component RPC. Furthermore, the service call capability between heterogeneous multi-core devices is completed based on the integration of existing interfaces, eliminating the need for separately customized interfaces, improving development efficiency, and providing better versatility.

[0046] Based on the above embodiments, Figure 2 A flowchart illustrating another inter-core communication method provided in this application embodiment is shown below. Figure 2 As shown, the method includes the following steps:

[0047] Step 201: Obtain the service call request sent by the second electronic device.

[0048] Step 201 can be explained in the foregoing embodiments, as the principle is the same, and will not be repeated here.

[0049] As an example, Figure 3This diagram illustrates a communication scenario provided in an embodiment of this application. An Android tablet is the second device, and an Android phone is the first device. CPU0 in the phone is the first processor, and CPU1 is the second processor. On a remote device, such as a tablet, the tablet discovers the IP address of the remote phone through interconnection. The phone then announces its own IP address to the tablet. After obtaining the phone's IP address and the port number provided by the service app 1, the tablet directly calls the native Android RPC Binder interface and requests the capabilities of the service app 1 on the phone side via Android RPC InetSocket communication. In essence, the application on CPU1 of the phone provides service 1, while the main CPU on the phone that provides direct network service access is CPU0. Internally, the management service corresponding to main CPU0 records service 1 and the processor to which it belongs is CPU1. This achieves proxy mapping of service capability 1 on heterogeneous CPU1 within main CPU0. The purpose is that when service 2 of an application in a remote second electronic device needs to request service 1 from CPU1 on the first electronic device, service 2 in application 1 of the second electronic device accesses the service on main CPU0 of the first electronic device. Internally, through inter-core calls (CPC), main CPU0 can access the actual CPU1 providing service capability 1. CPU1 processes the service call request and returns the result. In other words, service 1, which is then relayed to the actual CPU1 providing capability, is completed by the CPC service between CPU0 and CPU1 within the phone. This is unknown to the external tablet; from the external tablet's perspective, it appears as if it can directly access the multi-core services within the phone remotely, without the user's awareness.

[0050] One implementation method is to obtain the service capabilities deployed on different cores of the Android device (i.e., the tablet) and directly call the interface provided by RPC. Specifically, the tablet directly calls the RPC Binder interface, session->setupInetClient(Internet Protocol (IP) address of the remote service provider, port number bound to this service of the remote service provider), and sends the service call request to the phone's CPU0.

[0051] Step 202: Obtain the service list.

[0052] The service list includes the correspondence between the processor to which each service belongs and its identification information.

[0053] The service list can be generated in the following ways:

[0054] In one implementation of this application, before the device leaves the factory, since the number of processors included in the device and the services included in the applications of each processor are determinable, a service list can be generated at the time of leaving the factory to achieve management of all services in the first electronic device.

[0055] In another implementation of this application, when a new application or a new service in an application needs to be registered, the new service includes a target service. Taking the target service as an example, the inter-core communication method of this application is used, that is, the management service in the first processor calls the data receiving interface in the inter-core communication subclass to receive the identification information of the target service and the processor to which it belongs. Based on the identification information of the target service and the second processor to which it belongs, a correspondence between the identification information of the target service and the second processor to which it belongs is established in the service list. Similarly, a correspondence between the identification information of each service and the second processor to which it belongs can be established in the service list.

[0056] Step 203: Based on the identification information of the target service to be invoked in the service invocation request, query the service list to determine that the target service to be invoked belongs to the second processor in the first electronic device.

[0057] In this embodiment, the service list includes information about services in all processors of the first electronic device. Based on the identification information of the target service to be called in the service call request, such as port information, the service list is queried to determine the second processor to which the target service to be called belongs among the multiple processors in the first electronic device, thereby locating the processor that actually provides the service.

[0058] Step 204: Based on the identifier of the management service, the identifier of the first processor to which it belongs, and the socket communication type corresponding to the management service, add a new inter-core communication subclass corresponding to the management service in Android's RPC Binder.

[0059] As an example, such as Figure 4A As shown, in related technologies, Android's RPC Binder includes three types of Socket classes: Inet Socket, VM Socket, and Domain Socket. None of these three Socket classes can enable calls between different processors within a single device, i.e., inter-core calls. Therefore, this application extends RPCBinder to obtain RpMsg Socket, and uses classes based on RpMsg Socket to implement inter-processor communication, i.e., inter-core communication. The different Socket class methods in Android Binder represent different implementations of the Socket transport layer interface.

[0060] Specifically, integrating RpMsg with Android Binder requires extending the original RPC interface of Android Binder. RpMsg Socket also has concrete implementations of these interfaces. We only need to replace the constructors of each specific Class XX Socket Address in the original Socket Address class of Android Binder with the corresponding Socket Address type of RpMsg Socket. For example, we can add a new RpMsg Socket class type and construct a constructor for this new class based on the RpMsg Socket Address structure type. The core of RpMsgSocket communication is the service identifier, the processor identifier, and the socket communication type corresponding to the service. The processor identifier Rp_cpu is used to distinguish which processor core it belongs to, and the service identifier Rp_name is used to define which service runs on that processor core. The socket communication type Rp_family corresponding to the service defines the socket communication type as PF_RpMsg, which is equivalent to other types such as PF_INET in related technologies.

[0061] The class `RpMsg Socket Address:public RPC Socket Address` inherits from the parent class `RPC SocketAddress`. Some API interfaces of the RPC Binder itself can be directly called in the new `RpMsg Socket`, enabling the use of common interfaces. The interface calls for the AIDL communication process are all inherited from the common interfaces of the parent class `RPCSocket Address`.

[0062] Optionally, a communication channel for RpMsg can also be established. After the RpMsg communication channel is established, the Socket can be expanded, specifically... Figure 4A The process will not be elaborated here. Figure 4A The Binder obtained through this extension relies on OpenAMP's multi-core processor communication framework technology at its underlying level. Figure 4B This is a schematic diagram of the underlying architecture of inter-core communication in the embodiments of this application. In the AMP (Asymmetric Multiprocessing) configuration, different software environments are run on different processing cores and their respective code programs are executed. The cores work together to improve processor performance. The OpenAMP software framework provides the necessary API functions for developing the AMP system.

[0063] Thus, the communication method of Android CPC encapsulated by RpMsg Socket is integrated, enabling inter-core calls.

[0064] Step 205: Invoke the inter-core communication subclass corresponding to the management service in the first processor and send the service call request to the target service in the second processor.

[0065] Among them, the inter-core communication subclass inherits the interface of RPC Binder for inter-process communication of remote procedure calls and the interface of RpMsg for inter-core communication, that is, it is based on the RpMsg Socket communication method for inter-core communication, and inherits the interface of RPC Binder for inter-process communication of remote procedure calls.

[0066] Step 206: Call the inter-core communication subclass to obtain the service call result obtained by the target service based on the service call request.

[0067] Steps 205 and 206 can be explained in the foregoing embodiments, as the principle is the same, and will not be repeated here.

[0068] Step 207: Send the service call result to the second electronic device through the RPC Binder interface.

[0069] In this embodiment, since the service call request is issued by the service in the processor of the second electronic device, when the first processor obtains the service call result from the second processor that actually provides the service, it needs to send the service call result to the service that issued the request on the second electronic device. Since the first electronic device and the second electronic device are different electronic devices, communication between remote devices is realized based on RPC communication in related technologies. Specifically, the service call result is sent to the second electronic device by calling the RPC Binder interface.

[0070] The inter-core communication method implemented in this application extends a new underlying communication method using RpMsg Socket. For the upper layer, it shares the same interface as other RPC communication methods, meaning it's already integrated under the RPC interface. There's no need to worry about whether it's RPC's Inet Socket or RpMsg Socket capabilities. Within the RPC Binder module, this is invisible to the upper-layer application, reducing development difficulty. During inter-core communication, the RPC Binder interface can be directly called to achieve inter-core data transmission, improving versatility.

[0071] Based on the above embodiments, this application integrates the RPC interface, enabling the device's service capabilities to directly call the native Binder interface using the Binder AIDL mechanism. Specifically, it automatically generates the BBinder Class for the service side (the service in the calling processor) and the BpBinder Class for the user client side (the service in the called processor) through the Android Interface Definition Language (AIDL). By extending Binder capabilities, it enhances the native Android IPC communication capabilities, automatically generates relevant code, and reduces development difficulty. Furthermore, on distributed multi-core devices, the inter-core communication mechanism of this application facilitates later application development and provides a new inter-core communication capability.

[0072] Based on the above embodiments, this application provides a schematic diagram of inter-core communication scenario interaction, such as... Figure 5 As shown,

[0073] In the first device, such as a mobile phone, there are two processors, CPU1 and CPU0. Service B on CPU1 registers with the main core CPU0 via CPC Binder. CPU0, as the main core, manages all Binder services through the Service Manage service. Meanwhile, services on CPU1 other than CPU0 use CPC Binder for inter-core communication.

[0074] If the second device, namely the remote device C, wants to request access to the service Server_B, then the remote device C will remotely connect to CPU0 via the RPC Inet Binder method, using the network IP address AAAA presented to the outside world by the main processor and the port PortA corresponding to service B, and call the RPC Binder interface to send the service access request to the main core CPU0.

[0075] The process managing the Service Manager service on CPU0 queries the requested service Server_B. If it determines that Service Server_B is a proxy service mapped in CPU0, that is, if it finds that Service Server_B is Service Server_B in processor CPU1, it calls the local inter-core communication method CPC Binder to forward the remote service call request to Service Server_B on the real service provider CPU1.

[0076] CPU1 calls service B to obtain the service call result and returns the result to CPU0, thus realizing inter-core communication. Then, CPU0 returns the service call result to the remote device C through the RPC Binder interface.

[0077] To implement the above embodiments, this application also proposes an inter-core communication device, which is a first processor disposed in a first electronic device.

[0078] Figure 6 This is a schematic diagram of the structure of an inter-core communication device provided in an embodiment of this application.

[0079] like Figure 6 As shown, the device may include:

[0080] The first acquisition module 61 is used to acquire the service call request sent by the second electronic device;

[0081] The query module 62 is used to query the second processor to which the target service to be called belongs in the first electronic device based on the identification information of the target service to be called carried in the service call request;

[0082] The sending module 63 is used to call the inter-core communication subclass corresponding to the management service in the first processor to send the service call request to the target service in the second processor; wherein, the inter-core communication subclass inherits the interface of the remote procedure call inter-process communication RPC Binder and the interface of the inter-core communication standard RpMsg.

[0083] The second acquisition module 64 is used to call the inter-core communication subclass to obtain the service call result obtained by the target service based on the service call request.

[0084] Furthermore, in one implementation of this application embodiment, the apparatus further includes:

[0085] A new module is added to add an inter-core communication subclass corresponding to the management service in Android's RPC Binder based on the identifier of the management service, the identifier of the first processor to which it belongs, and the socket communication type corresponding to the management service.

[0086] In one implementation of this application embodiment, the query module 62 is specifically used for:

[0087] Obtain a service list; wherein, the service list includes the correspondence between the processor to which each service belongs and its identification information;

[0088] Based on the identifier information of the target service to be invoked in the service invocation request, the service list is queried to determine that the target service to be invoked belongs to the second processor in the first electronic device.

[0089] In one implementation of this application embodiment, the query module 62 is specifically used for:

[0090] The data receiving interface in the inter-core communication subclass is invoked to receive the registration request sent by the target service; wherein the registration request carries the identification information of the target service and the second processor to which it belongs;

[0091] Based on the identification information of the target service and the second processor to which it belongs, a correspondence is established between the identification information of the target service and the second processor to which it belongs in the service list.

[0092] In one implementation of this application embodiment, the sending module 63 is further configured to:

[0093] The service call result is sent to the second electronic device via the RPC Binder interface.

[0094] It should be noted that the foregoing explanation of the method embodiments also applies to the apparatus of this embodiment, and will not be repeated here.

[0095] The inter-core communication device proposed in this application obtains a service call request sent by a second electronic device. Based on the identifier information of the target service to be called carried in the service call request, it queries the second processor to which the target service belongs in the first electronic device. It then calls the inter-core communication subclass corresponding to the management service in the first processor, sends the service call request to the target service in the second processor, and calls the inter-core communication subclass to obtain the service call result obtained by the target service based on the service call request. The relevant interfaces in the inter-core communication subclass RpMsg SockeAdress corresponding to the management service integrate the heterogeneous multi-core RpMsg standard interface and the interface of the electronic device's basic communication component RPC Binder, enhancing the capabilities of the electronic device's basic communication component RPC. Furthermore, by integrating existing interfaces to complete the service call capability between heterogeneous multi-core devices, it eliminates the need for separately customized interfaces, improving development efficiency and providing better versatility.

[0096] To implement the above embodiments, this application also proposes an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, it implements the method described in the foregoing method embodiments.

[0097] To implement the above embodiments, this application also proposes a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the method described in the foregoing method embodiments.

[0098] To implement the above embodiments, this application also proposes a computer program product having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the method described in the foregoing method embodiments.

[0099] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. For example, the electronic device 800 may be a mobile phone, computer, digital broadcasting terminal, messaging device, game console, tablet device, medical device, fitness equipment, personal digital assistant, etc.

[0100] Reference Figure 7 The electronic device 800 may include one or more of the following components: processing component 802, memory 804, power component 806, multimedia component 808, audio component 810, input / output (I / O) interface 812, sensor component 814, and communication component 816.

[0101] Processing component 802 typically controls the overall operation of electronic device 800, such as operations associated with display, telephone calls, data communication, camera operation, and recording operations. Processing component 802 may include one or more processors 820 to execute instructions to complete all or part of the steps of the methods described above. Furthermore, processing component 802 may include one or more modules to facilitate interaction between processing component 802 and other components. For example, processing component 802 may include a multimedia module to facilitate interaction between multimedia component 808 and processing component 802.

[0102] Memory 804 is configured to store various types of data to support the operation of electronic device 800. Examples of this data include instructions for any application or method operating on electronic device 800, contact data, phonebook data, messages, pictures, videos, etc. Memory 804 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0103] Power component 806 provides power to various components of electronic device 800. Power component 806 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to electronic device 800.

[0104] Multimedia component 808 includes a screen that provides an output interface between the electronic device 800 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors may sense not only the boundaries of the touch or swipe action but also the duration and pressure associated with the touch or swipe operation. In some embodiments, multimedia component 808 includes a front-facing camera and / or a rear-facing camera. When the electronic device 800 is in an operating mode, such as a shooting mode or a video mode, the front-facing camera and / or the rear-facing camera may receive external multimedia data. Each front-facing camera and rear-facing camera may be a fixed optical lens system or have focal length and optical zoom capabilities.

[0105] Audio component 810 is configured to output and / or input audio signals. For example, audio component 810 includes a microphone (MIC) configured to receive external audio signals when electronic device 800 is in an operating mode, such as call mode, recording mode, and voice recognition mode. The received audio signals may be further stored in memory 804 or transmitted via communication component 816. In some embodiments, audio component 810 also includes a speaker for outputting audio signals.

[0106] I / O interface 812 provides an interface between processing component 802 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to, home buttons, volume buttons, power buttons, and lock buttons.

[0107] Sensor assembly 814 includes one or more sensors for providing state assessments of various aspects of electronic device 800. For example, sensor assembly 814 can detect the on / off state of electronic device 800, the relative positioning of components such as the display and keypad of electronic device 800, changes in position of electronic device 800 or a component of electronic device 800, the presence or absence of user contact with electronic device 800, orientation or acceleration / deceleration of electronic device 800, and temperature changes of electronic device 800. Sensor assembly 814 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. Sensor assembly 814 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, sensor assembly 814 may also include an accelerometer, gyroscope, magnetometer, pressure sensor, or temperature sensor.

[0108] Communication component 816 is configured to facilitate wired or wireless communication between electronic device 800 and other devices. Electronic device 800 can access wireless networks based on communication standards, such as WiFi, 4G, or 5G, or combinations thereof. In one exemplary embodiment, communication component 816 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, communication component 816 also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on radio frequency identification (RFID) technology, Infrared Data Association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0109] In an exemplary embodiment, the electronic device 800 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the methods described above.

[0110] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 804 including instructions, which can be executed by a processor 820 of an electronic device 800 to perform the above-described method. For example, the non-transitory computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0111] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0112] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0113] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0114] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0115] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0116] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0117] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0118] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application.

Claims

1. A method for inter-core communication, characterized in that, A first processor used in a first electronic device includes: Obtain the service call request sent by the second electronic device; Based on the identification information of the target service to be invoked carried in the service invocation request, query the second processor to which the target service to be invoked belongs in the first electronic device; If the second processor is different from the first processor, the inter-core communication subclass corresponding to the management service in the first processor is invoked to send the service call request to the target service in the second processor; wherein, the inter-core communication subclass inherits the interface of the remote procedure call inter-process communication RPC Binder and the interface of the inter-core communication standard RpMsg; Invoke the inter-core communication subclass to obtain the service call result obtained by the target service based on the service call request.

2. The method as described in claim 1, characterized in that, Before invoking the inter-core communication subclass corresponding to the management service in the first processor and sending the service invocation request to the target service in the second processor, the following steps are included: Based on the identifier of the management service, the identifier of the first processor to which it belongs, and the socket communication type corresponding to the management service, a new inter-core communication subclass corresponding to the management service is added to the Android RPC Binder.

3. The method as described in claim 1, characterized in that, The step of querying the second processor in the first electronic device to which the target service to be invoked belongs, based on the identifier information of the target service to be invoked carried in the service invocation request, includes: Obtain a service list; wherein, the service list includes the correspondence between the processor to which each service belongs and its identification information; Based on the identifier information of the target service to be invoked in the service invocation request, the service list is queried to determine that the target service to be invoked belongs to the second processor in the first electronic device.

4. The method as described in claim 3, characterized in that, Before obtaining the service list, the following is also included: The data receiving interface in the inter-core communication subclass is invoked to receive the registration request sent by the target service; wherein the registration request carries the identification information of the target service and the second processor to which it belongs; Based on the identification information of the target service and the second processor to which it belongs, a correspondence is established between the identification information of the target service and the second processor to which it belongs in the service list.

5. The method according to any one of claims 1-4, characterized in that, After obtaining the service call result of the target service based on the service call request, the method further includes: The service call result is sent to the second electronic device via the RPC Binder interface.

6. An inter-nuclear communication device, characterized in that, A first processor disposed in a first electronic device includes: The first acquisition module is used to acquire service call requests sent by the second electronic device; The query module is used to query the second processor in the first electronic device to which the target service to be called belongs, based on the identification information of the target service to be called carried in the service call request. The sending module is used to, if the second processor is different from the first processor, call the inter-core communication subclass corresponding to the management service in the first processor to send the service call request to the target service in the second processor; wherein, the inter-core communication subclass inherits the interface of the remote procedure call inter-process communication RPC Binder and the interface of the inter-core communication standard RpMsg. The second acquisition module is used to call the inter-core communication subclass to obtain the service call result obtained by the target service based on the service call request.

7. The apparatus as claimed in claim 6, characterized in that, The device further includes: A new module is added to add an inter-core communication subclass corresponding to the management service in Android's RPC Binder based on the identifier of the management service, the identifier of the first processor to which it belongs, and the socket communication type corresponding to the management service.

8. The apparatus as claimed in claim 6, characterized in that, The query module is specifically used for: Obtain a service list; wherein, the service list includes the correspondence between the processor to which each service belongs and its identification information; Based on the identifier information of the target service to be invoked in the service invocation request, the service list is queried to determine that the target service to be invoked belongs to the second processor in the first electronic device.

9. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, it implements the method as described in any one of claims 1-5.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-5.

Images