Cross-device data processing method and electronic device

Abstract

The invention provides a cross-device data processing method and electronic equipment, and relates to the field of electronic equipment, the method is applied to first electronic equipment, and the method comprises the following steps: responding to a first operation of a user on a first application, under the condition that a first module does not have a module identifier, executing the first operation on the first application; the first electronic equipment determines a first module identifier corresponding to the first module through a Binder module of the first electronic equipment; the first electronic equipment creates a target I Binder object of the first service through the Binder module, and determines a first identifier of the target I Binder object; the target I Binder object is used for calling a first service provided by the first module; the first electronic equipment calls a target service of the second electronic equipment based on a distributed application plug-in corresponding to a target module identifier in the first module identifiers; the second identifier is determined by a second I Binder object created by the first electronic equipment based on the first Binder ID, and the first Binder ID is determined according to the first I Binder object of the target service when the second electronic equipment registers the target service. The scheme can improve the working efficiency.

Description

Technical Field

[0001] The present application relates to the technical field of electronic devices, and in particular to a cross-device data processing method and electronic device. Background Art

[0002] Currently, since different types of electronic devices have different functions, users will use more convenient electronic devices according to different scenarios. For example, since the screen of a computer is larger than that of a mobile phone, users usually use a computer to organize notes for study, while in offline classes, they need to take pictures of the blackboard content and insert them into the computer notes.

[0003] Since there is no rear camera on the computer, the existing solution is to use the mobile phone to shoot the blackboard content, then upload the captured content to the computer, then download and save it to the computer, and finally upload it to the computer's notes. However, in this method, switching back and forth between multiple devices and transmitting data is relatively cumbersome. Summary of the invention

[0004] The embodiments of the present application provide a cross-device data processing method and an electronic device, which can realize cross-device calling of services, reduce the complexity of operations, and improve user work efficiency.

[0005] To achieve the above objectives, the embodiments of the present application adopt the following technical solutions:

[0006] In a first aspect, a cross-device data processing method is provided, which can be applied to a first electronic device, and includes: in response to a first operation of a user on a first application, the first electronic device obtains judgment information; wherein the judgment information is used to indicate whether a module identifier exists in a first module of the first electronic device; when the judgment information indicates that the first module does not have a module identifier, the first electronic device obtains a first module identifier corresponding to the first module through a Binder module of the first electronic device; the first electronic device creates a target IBinder object of a first service through the Binder module, and determines a first identifier of the target IBinder object; wherein the first identifier is associated with the first module identifier, and the target IBinder object is used to call a first service provided by the first module; the first electronic device calls a target service of the second electronic device based on a distributed application plug-in corresponding to the target module identifier in the first module identifier; wherein the target module identifier is associated with a second identifier, and the second identifier is determined by a second IBinder object created by the first electronic device based on the first Binder identifier ID, the first Binder ID is determined according to the first IBinder object of the target service when the second electronic device registers the target service, and is obtained by the first electronic device from the second electronic device, and the first IBinder object and the second IBinder object are used to call the target service.

[0007] By adopting this technical method, the first electronic device completes IPC initialization by calling the Binder module, that is, obtains the module identifier of the corresponding module, so that no additional IPC initialization is required. The various modules of the first electronic device do not need to perceive the underlying IPC communication component framework, and can directly perform Binder calls, which is consistent with the cross-device calls on the Android side.

[0008] Among them, the user can use the first electronic device to send a shooting instruction to the second electronic device. After receiving the shooting instruction, the second electronic device will call up the camera to perform the shooting or scanning task, and after completion, the shooting result or the scanned text will be directly sent back to the first electronic device. This can save the user from uploading the shooting result or the scanned text to the second electronic device, then downloading and saving it to the second electronic device, and then uploading it to the corresponding location of the second electronic device. The operation is simpler and the user's work efficiency is improved.

[0009] In a possible implementation of the first aspect, after the first electronic device obtains judgment information in response to the user's first operation on the first application, it also includes: when the judgment information indicates that the first module has a module identifier, the first electronic device creates a target IBinder object for the first service through the Binder module, and determines the first identifier of the target IBinder object; wherein the first identifier is associated with the first module identifier.

[0010] Optionally, when the judgment information indicates that the first module does not have a module identifier, the target IBinder object of the first service can be created first, and the first identifier of the target IBinder object can be determined. Then, the first module identifier corresponding to the first module is obtained through the Binder module of the first electronic device, and the first identifier is associated with the first module identifier.

[0011] In a possible implementation of the first aspect, the Binder module includes a first Binder management module and a second Binder management module, and the first electronic device determines the first module identifier corresponding to the first module through the Binder module of the first electronic device, including: the first electronic device determines the first module identifier corresponding to the first module through the first Binder management module.

[0012] In a possible implementation of the first aspect, the first electronic device creates a target IBinder object for the first service through a Binder module and determines a first identifier of the target IBinder object, including: the first electronic device creates a target IBinder object for the first service through a first Binder management module, and determines the first identifier of the target IBinder object through a second Binder management module; the first electronic device associates the first identifier with the first module identifier through the second Binder management module.

[0013] In a possible implementation of the first aspect, before the first electronic device determines the first module identifier corresponding to the first module through the first Binder management module, it also includes: the first module of the first electronic device sends a first call request to the first Binder management module, and the first call request is used to request the first Binder management module to create a target IBinder object for the first service. Among them, for the first module, it is only necessary to send a call request to the first Binder management module, and the process of obtaining the module identifier and creating the IBinder object is implemented by the Binder module, so that the first module in the first electronic device does not need to pay attention to the implementation process of IPC communication.

[0014] In a possible implementation of the first aspect, the first electronic device determines a first module identifier corresponding to the first module through a first Binder management module, including: the first Binder management module sends a first acquisition request to an inter-process communication module of the first electronic device in response to a first call request, and the first acquisition request is used to request to obtain the module identifier of the first module; the inter-process communication module assigns a corresponding first module identifier to the first module in response to the first acquisition request, and returns the first module identifier to the first Binder management module.

[0015] In a possible implementation of the first aspect, a first electronic device creates a target IBinder object for a first service through a first Binder management module, and determines a first identifier of the target IBinder object through a second Binder management module, including: the first Binder management module creates a target IBinder object for the first service, and sends a second acquisition request to the second Binder management module, the second acquisition request is used to request to obtain the first identifier of the target IBinder object; wherein the acquisition request includes the first module identifier; the second Binder management module determines the corresponding first identifier based on the target IBinder object in response to the second acquisition request.

[0016] In a possible implementation of the first aspect, before the first electronic device determines the first module identifier corresponding to the first module of the first electronic device through the Binder module of the first electronic device, it also includes: the Binder module of the first electronic device sends an initialization instruction to the inter-process communication module of the first electronic device; the inter-process communication module of the first electronic device determines the module identifier corresponding to the Binder module of the first electronic device.

[0017] In a possible implementation of the first aspect, before the first electronic device calls the target service of the second electronic device based on the distributed application plug-in corresponding to the target module identifier in the first module identifier, it also includes: the first electronic device obtains the first Binder ID from the second electronic device, and creates a second IBinder object based on the first Binder ID; the first electronic device determines the second identifier based on the second IBinder object, and associates the target module identifier based on the second identifier; the first electronic device returns the second IBinder object to the distributed application plug-in based on the target module identifier; the first electronic device sends the second IBinder object from the distributed application plug-in to the first application based on the second module identifier of the first application.

[0018] In a possible implementation of the first aspect, before the first electronic device sends the second IBinder object from the distributed application plug-in to the first application based on the second module identifier of the first application, it also includes: the first application sends a second call request to the first Binder management module, and the second call request is used to request the first Binder management module to create a reference object of the second IBinder object; wherein the reference object is used to call the target service; the first Binder management module responds to the second call request and sends a third acquisition request to the inter-process communication module, and the third acquisition request is used to request to obtain the module identifier of the first application; the inter-process communication module responds to the third acquisition request, allocates the corresponding second module identifier to the first application, and returns the second module identifier to the first Binder management module; the first Binder management module creates a reference object of the second IBinder object, and sends a fourth acquisition request to the second Binder management module, and the fourth acquisition request is used to request to obtain the third identifier of the reference object; wherein the acquisition request contains the second module identifier; the second Binder management module responds to the fourth acquisition request, determines the corresponding third identifier based on the reference object, and associates the third identifier with the second module identifier.

[0019] That is to say, in the process of the first electronic device sending the second IBinder object from the distributed application plug-in to the first application, it needs to be forwarded based on the module identifier of the first application. In fact, the second IBinder object is not returned to the note application, but the reference object of the second IBinder object is returned to the note application. At this time, it is equivalent to the note application of the first electronic device creating an IBinder object for the first time, and the note application has not yet been assigned a corresponding module identifier. Therefore, the note application needs to obtain the module identifier in order to receive messages from other processes through the IPC communication module.

[0020] It is understandable that, since a service call is to be initiated through a distributed application plug-in, the IBinder object of the distributed application management service can be sent to the distributed application plug-in only through the module identifier associated with the distributed application plug-in. In fact, what the distributed application plug-in obtains is not the second IBinder object, but the reference object of the second IBinder object. Therefore, the first identifier associated with the target module identifier of the above-mentioned second IBinder object can be understood as the first identifier associated with the target module identifier corresponding to the reference object of the second IBinder object.

[0021] It should be noted that the IBinder object cannot be directly associated with the module identifier, but a unique identifier needs to be applied for the IBinder object to be associated with the module identifier. The first identifier, the second identifier, and the third identifier all represent unique identifiers, which are only used to distinguish different IBinder objects.

[0022] In a possible implementation of the first aspect, the first electronic device sends the second IBinder object to the first application from a distributed application plug-in based on the second module identifier of the first application, including: the distributed application plug-in sends the reference object to the first application based on the second module identifier.

[0023] In a possible implementation of the first aspect, a first electronic device calls a target service of a second electronic device based on a distributed application plug-in corresponding to a target module identifier in a first module identifier, including: the first application sends a service call request to the distributed application plug-in based on the target module identifier; wherein the service call request includes a reference object; and the distributed application plug-in responds to the service call request and calls the target service based on a second IBinder object corresponding to the reference object.

[0024] In a possible implementation manner of the first aspect, the first module includes a distributed application plug-in, a service collaboration module, and a distributed file module of the first electronic device.

[0025] In a second aspect, the present application provides an electronic device, comprising: a communication module, a display screen, a memory and one or more processors; the communication module, the display screen, the memory and the processor are coupled; the memory is used to store computer program code, the computer program code includes computer instructions, and when the computer instructions are executed by the electronic device, the electronic device executes the method described in the first aspect above.

[0026] In a third aspect, the present application provides a computer-readable storage medium, in which instructions are stored, and when the computer-readable storage medium is run on a computer, the computer can execute any of the methods described in the first aspect.

[0027] In a fourth aspect, the present application provides a computer program product comprising instructions, which, when executed on a computer, enables the computer to execute any of the methods described in the first aspect.

[0028] It can be understood that the electronic device described in the second aspect provided above, the computer-readable storage medium described in the third aspect and the computer program product described in the fourth aspect are all used to execute the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding methods provided above, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Figure 1 A schematic diagram of a scenario for inserting blackboard content into an offline classroom provided in an embodiment of the present application;

[0030] Figure 2 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present application;

[0031] Figure 3 A schematic diagram of a software structure of a first electronic device provided in an embodiment of the present application;

[0032] Figure 4 A schematic diagram of the software structure of a second electronic device provided in an embodiment of the present application;

[0033] Figure 5 A schematic diagram of creating an IBinder object by a service collaboration module provided in an embodiment of the present application;

[0034] Figure 6 A schematic diagram of creating an IBinder object for a distributed application plug-in provided in an embodiment of the present application;

[0035] Figure 7 A schematic diagram of a cross-device data processing method provided in an embodiment of the present application;

[0036] Figure 8A timing diagram of registering a distributed application management service and obtaining a service provided in an embodiment of the present application;

[0037] Fig. 9 A schematic diagram of a note-taking application obtaining a module identifier provided in an embodiment of the present application;

[0038] Fig.10 A schematic diagram of an interface display of a note-taking application provided in an embodiment of the present application;

[0039] Fig.11 A schematic diagram of a first electronic device turning on a camera of a second electronic device provided in an embodiment of the present application;

[0040] Fig.12 A timing diagram of a File Provider object for obtaining notes provided in an embodiment of the present application;

[0041] Fig.13 A timing diagram of obtaining a file handle of a note provided in an embodiment of the present application;

[0042] Fig.14 A schematic diagram of creating a distributed file provided in an embodiment of the present application;

[0043] Fig.15 A schematic diagram of a PC Binder mechanism for cross-device calls provided in an embodiment of the present application;

[0044] Fig.16 A schematic diagram of the structure of a chip system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0045] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all of the embodiments. The following terms "first", "second", etc. are used for descriptive purposes only and cannot be understood as indicating or implying relative importance or implicitly indicating the number of indicated technical features. Thus, features defined as "first", "second", etc. may explicitly or implicitly include one or more of the features.

[0046] In addition, the terms "including" and "having" and any variations thereof mentioned in the description of this application are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or modules is not limited to the listed steps or modules, but may optionally include other steps or modules that are not listed, or may optionally include other steps or modules that are inherent to these processes, methods, products or devices.

[0047] In addition, in the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary" or "for example" in the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present concepts in a specific way.

[0048] For ease of understanding, the following terms are introduced in this application:

[0049] Binder: Binder is the medium for communication between the client and the server. The server will return a Binder object containing the service call of the server. The client can obtain the services or data provided by the server through this Binder object.

[0050] Among them, the Binder mechanism supports both intra-process calls and inter-process calls. Remote calls (i.e. cross-process calls) can be implemented through IBinder. IBinder is a basic interface for remote calls. The main application programming interface (API) of IBinder is transact(), and the corresponding method is Binder.onTransact(). The first method enables the local end to send calls to the remote IBinder object, and the second method enables the local remote object to respond to the received calls.

[0051] Currently, in order to make learning more convenient, users usually use tablets (Pads) or personal computers (PCs) to record and organize notes. Then users need to obtain the blackboard content in offline classes and insert it into the notes on the tablet or personal computer. Or, when users organize their thesis ideas on a tablet or personal computer, they often need to use the obtained textbook content to insert references into the tablet or personal computer.

[0052] However, since there is no rear camera on personal computers, users usually use their mobile phones to take pictures or scan the contents of the blackboard or textbooks in offline classes, upload them to their personal computers, download and save them to their personal computers, and finally upload them to the corresponding location of their notes. The number of user operations is relatively high, and switching back and forth between multiple devices and transferring data is relatively cumbersome.

[0053] Alternatively, you can take a photo of the blackboard content with a tablet, but the tablet is bulky. At the same time, due to the limitations of device parameters, students in the back row (too far away) and students in the front row (too close to the blackboard and need to use a wide-angle function to capture the full view of the blackboard content) may not be able to take photos of the blackboard that meet user needs.

[0054] Therefore, the present application provides a cross-device data processing method, whereby a user can use a first electronic device (such as a personal computer) to send a shooting command to a second electronic device (such as a mobile phone or tablet). After receiving the shooting command, the mobile phone or tablet activates the camera to perform a shooting or scanning task, and after completion, directly transmits the shooting result or the scanned text back to the personal computer.

[0055] like Figure 1 As shown, the main device may include a tablet and a personal computer, and the auxiliary device may include a mobile phone. The note application of the main device responds to the user's operation and sends a shooting instruction or a scanning instruction to the auxiliary device. After receiving the shooting instruction or the scanning instruction, the auxiliary device calls up the camera to perform the shooting task or the scanning task. After the shooting or scanning is completed, the auxiliary device returns the shooting result (photo) or the scanning result (extracted text) to the note application of the main device.

[0056] Compared with the existing methods, different functions can be realized on the above multiple devices respectively through remote calls between the above devices, so as to reduce the manual switching between multiple devices when realizing the above multiple functions. For example, it can save the user the steps of uploading the shooting results or the scanned extracted text to the personal computer, then downloading and saving it to the personal computer, and then uploading it to the corresponding location of the personal computer. The operation is simpler and the user's work efficiency is improved. In addition, by using a mobile phone to perform shooting operations, photos of the blackboard content that can meet the user's needs can be taken.

[0057] Generally speaking, Windows is installed on PCs, and Android is installed on mobile phones. Cross-device calls between PCs and mobile phones refer to cross-device calls between Windows and Android systems. Therefore, in order to make the cross-device call solution between Windows and Android more universal, it is necessary to unify the architecture design of Windows system->Android system and Android system->Android system, and the access method must also be consistent. Windows system->Android system means that Windows calls Android, such as PC calls mobile phone; Android system->Android system means that Android calls Android, such as tablet calls mobile phone.

[0058] Therefore, PC Binder capabilities need to be built on the PC side (Windows system side) to support Binder calls on the PC side. The Binder framework on the Android side needs to be ported and the corresponding capabilities need to be adapted on the Windows platform. After building the PCBinder capabilities on the PC side, a component framework similar to the Android side will also be built to support cross-device Activity components, Service component binding, Provider access and other capabilities. Among them, the component framework built on the PC side is similar to that on the Android side. Due to system differences, the ability to call the underlying system may be different, and the interface provided by the system needs to be improved.

[0059] At present, in the existing scheme on the PC side, each module in the client needs to interact with the IPC communication component to perform IPC initialization before calling Binder. The embodiment of the present application provides a cross-device data processing method, which can perform IPC initialization through the Binder module corresponding to each module when each module creates an IBinder object for the provided service for the first time, avoiding the additional step of initializing the IPC communication component, so that each module of the client does not need to perceive the underlying IPC communication component framework, and can directly call Binder, which is consistent with the cross-device call on the Android side.

[0060] Exemplarily, the electronic device in the embodiments of the present application may be a tablet computer, a mobile phone, a desktop computer, a laptop computer, a handheld computer, a notebook computer, an ultra-mobile personal computer (UMPC), a netbook, a cellular phone, a personal digital assistant (PDA), an augmented reality (AR) device, a virtual reality (VR) device, a vehicle-mounted device, or the like. The embodiments of the present application do not impose any special restrictions on the specific form of the electronic device.

[0061] In the embodiments of the present application, electronic devices can be divided into private devices and public devices. It is understandable that private devices are used to indicate devices that can only be used by the owner (i.e., the owner of the device). For example, private devices can be mobile phones, smart watches, smart glasses, headphones and other devices. Public devices are used to indicate devices that can be used by any user. In other words, there may be multiple accounts logged in to a public device, and there may be associations between multiple different accounts. For example, a public device can be a TV, a stereo, a tablet computer, etc.

[0062] The execution subject of the cross-device service calling method provided in the present application may be a cross-device data processing device, and the execution device may be Figure 2The electronic device shown. At the same time, the execution device can also be a central processing unit (CPU) of the electronic device, or a control module for cross-device data processing in the electronic device. In the embodiment of the present application, an electronic device executing a cross-device data processing method is taken as an example to illustrate the cross-device data processing method provided by the embodiment of the present application.

[0063] The following will describe the implementation of the embodiment of the present application in detail with reference to the accompanying drawings. Taking the above-mentioned electronic device as a mobile phone as an example, the hardware structure of the electronic device (such as the electronic device 300) is introduced. Figure 2 The electronic device 300 shown is merely one example of an electronic device, and the electronic device 300 may have more or fewer components than shown in the figure, may combine two or more components, or may have a different configuration of components. Figure 2 The various components shown in the EMBODIMENTS 2000 may be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and / or application specific integrated circuits.

[0064] See also Figure 2 , Figure 2 A schematic diagram of the structure of an electronic device is shown. Figure 2 As shown, the electronic device 300 may include: a processor 310, an external memory interface 320, an internal memory 321, a USB interface 330, a charging management module 340, a power management module 341, a battery 342, an antenna 1, an antenna 2, a mobile communication module 350, a wireless communication module 360, an audio module 370, a speaker 370A, a receiver 370B, a microphone, an earphone interface, a sensor module 380, a button 390, a motor 391, an indicator 392, a camera 393, a display screen 394, and a subscriber identification module (SIM) card interface 395, etc.

[0065] Among them, the above-mentioned sensor module 380 may include sensors such as pressure sensor, gyroscope sensor, air pressure sensor, magnetic sensor, acceleration sensor, distance sensor, proximity light sensor, fingerprint sensor, temperature sensor, touch sensor, ambient light sensor and bone conduction sensor.

[0066] It is to be understood that the structure illustrated in this embodiment does not constitute a specific limitation on the electronic device 300. In other embodiments, the electronic device 300 may include more or fewer components than shown in the figure, or combine some components, or split some components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.

[0067] The processor 310 may include one or more processing units, for example, the processor 310 may include an application processor (AP), a modem processor, a graphics processor (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0068] The controller may be the nerve center and command center of the electronic device 300. The controller may generate an operation control signal according to the instruction operation code and the timing signal to complete the control of fetching and executing instructions.

[0069] The processor 310 may also be provided with a memory for storing instructions and data. In some embodiments, the memory in the processor 310 is a cache memory. The memory may store instructions or data that the processor 310 has just used or cyclically used. If the processor 310 needs to use the instruction or data again, it may be directly called from the memory. This avoids repeated access, reduces the waiting time of the processor 310, and thus improves the efficiency of the system.

[0070] In some embodiments, the processor 310 may include one or more interfaces. The interface may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0071] It is understandable that the interface connection relationship between the modules shown in this embodiment is only a schematic illustration and does not constitute a structural limitation on the electronic device 300. In other embodiments, the electronic device 300 may also adopt different interface connection methods in the above embodiments, or a combination of multiple interface connection methods.

[0072] The charging management module 340 is used to receive charging input from a charger. In the embodiment of the present application, the charger may be a wired charger, and the charging management module 340 may receive charging input from the wired charger through the USB interface 330 (i.e., the above-mentioned charging interface). While the charging management module 340 is charging the battery 342, it may also power the electronic device through the power management module 341.

[0073] The power management module 341 is used to connect the battery 342, the charging management module 340 and the processor 310. The power management module 341 receives input from the battery 342 and / or the charging management module 340, and supplies power to the processor 310, the internal memory 321, the external memory, the display screen 394, the camera 393, and the wireless communication module 360. The power management module 341 can also be used to monitor parameters such as battery capacity, battery cycle number, battery health status (leakage, impedance), etc. In some other embodiments, the power management module 341 can also be set in the processor 310. In other embodiments, the power management module 341 and the charging management module 340 can also be set in the same device.

[0074] The wireless communication function of the electronic device 300 can be implemented through the antenna 1, the antenna 2, the mobile communication module 350, the wireless communication module 360, the modem processor and the baseband processor.

[0075] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in the electronic device 300 can be used to cover a single or multiple communication frequency bands. Different antennas can also be reused to improve the utilization of the antennas. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In some other embodiments, the antenna can be used in combination with a tuning switch.

[0076] The mobile communication module 350 can provide solutions for wireless communications including 2G / 3G / 4G / 5G, etc., applied to the electronic device 300. The mobile communication module 350 may include at least one filter, a switch, a power amplifier, a low noise amplifier (LNA), etc. The mobile communication module 350 can receive electromagnetic waves from the antenna 1, and filter, amplify, etc. the received electromagnetic waves, and transmit them to the modulation and demodulation processor for demodulation.

[0077] The mobile communication module 350 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation through the antenna 1. In some embodiments, at least some functional modules of the mobile communication module 350 can be set in the processor 310. In some embodiments, at least some functional modules of the mobile communication module 350 can be set in the same device as at least some modules of the processor 310.

[0078] The wireless communication module 360 ​​can provide wireless communication solutions including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR), etc., which are applied to the electronic device 300. For example, in the embodiment of the present application, the electronic device 300 can access the Wi-Fi network through the wireless communication module 360.

[0079] The wireless communication module 360 ​​may be one or more devices integrating at least one communication processing module. The wireless communication module 360 ​​receives electromagnetic waves via the antenna 2, modulates the electromagnetic wave signal and performs filtering, and sends the processed signal to the processor 310. The wireless communication module 360 ​​may also receive a signal to be sent from the processor 310, modulate the signal, amplify the signal, and convert it into an electromagnetic wave for radiation via the antenna 2.

[0080] In some embodiments, the antenna 1 of the electronic device 300 is coupled to the mobile communication module 350, and the antenna 2 is coupled to the wireless communication module 360, so that the electronic device 300 can communicate with the network and other devices through wireless communication technology. The wireless communication technology may include global system for mobile communications (GSM), general packet radio service (GPRS), code division multiple access (CDMA), wideband code division multiple access (WCDMA), time-division code division multiple access (TD-SCDMA), long term evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technology, etc. The GNSS may include a global positioning system (GPS), a global navigation satellite system (GLONASS), a Beidou navigation satellite system (BDS), a quasi-zenith satellite system (QZSS) and / or a satellite based augmentation system (SBAS).

[0081] The electronic device 300 implements the display function through a GPU, a display screen 394, and an application processor. The GPU is a microprocessor for image processing, which connects the display screen 394 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 310 may include one or more GPUs, which execute program instructions to generate or change display information.

[0082] The display screen 394 is used to display images, videos, etc. The display screen 394 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode or an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), Miniled, MicroLed, Micro-oLed, a quantum dot light-emitting diode (QLED), etc.

[0083] The electronic device 300 can realize the shooting function through ISP, camera 393, video codec, GPU, display screen 394 and application processor. ISP is used to process the data fed back by camera 393. Camera 393 is used to capture static images or videos. In some embodiments, the electronic device 300 may include 1 or N cameras 393, where N is a positive integer greater than 1. The digital signal processor is used to process digital signals. In addition to processing digital image signals, it can also process other digital signals. For example, when the electronic device 300 is in frequency selection, the digital signal processor is used to perform Fourier transform on the frequency energy. The video codec is used to compress or decompress digital video. NPU is a neural network (NN) computing processor. By drawing on the structure of biological neural networks, such as the transmission mode between neurons in the human brain, it can quickly process input information and can also continuously self-learn. Through NPU, applications such as intelligent cognition of the electronic device 100 can be realized, such as image recognition, face recognition, speech recognition, text understanding, etc.

[0084] The external memory interface 320 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 300. The external memory card communicates with the processor 310 through the external memory interface 320 to implement a data storage function, such as storing music, video and other files in the external memory card.

[0085] The internal memory 321 may be used to store computer executable program codes, which include instructions. The processor 310 executes various functional applications and data processing of the electronic device 300 by running the instructions stored in the internal memory 321. For example, in an embodiment of the present application, the processor 310 may execute the instructions stored in the internal memory 321, and the internal memory 321 may include a program storage area and a data storage area.

[0086] The program storage area may store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc. The data storage area may store data created during the use of the electronic device 300 (such as audio data, a phone book, etc.), etc. In addition, the internal memory 321 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc.

[0087] The electronic device 300 can implement audio functions such as music playing and recording through the audio module 370, the speaker 370A, the receiver 370B, the microphone, the headphone interface, and the application processor.

[0088] The audio module 370 is used to convert digital audio information into analog audio signal output, and is also used to convert analog audio input into digital audio signals. The audio module 370 can also be used to encode and decode audio signals. In some embodiments, the audio module 370 can be arranged in the processor 310, or some functional modules of the audio module 370 can be arranged in the processor 310. The speaker 370A, also known as the "speaker", is used to convert audio electrical signals into sound signals. The receiver 370B, also known as the "earpiece", is used to convert audio electrical signals into sound signals. The microphone, also known as the "microphone" or "microphone", is used to convert sound signals into electrical signals.

[0089] The headphone jack is used to connect a wired headphone, and the headphone jack may be a USB interface 330, or a 3.5 mm open mobile terminal platform (OMTP) standard interface or a cellular telecommunications industry association of the USA (CTIA) standard interface.

[0090] The button 390 includes a power button, a volume button, etc. The button 390 can be a mechanical button. It can also be a touch button. The motor 391 can generate a vibration prompt. The motor 391 can be used for incoming call vibration prompts, and can also be used for touch vibration feedback. The indicator 392 can be an indicator light, which can be used to indicate the charging status, power changes, messages, missed calls, notifications, etc. The SIM card interface 395 is used to connect the SIM card. The SIM card can be inserted into the SIM card interface 395, or pulled out from the SIM card interface 395 to achieve contact and separation with the electronic device 300. The electronic device 300 can support 1 or N SIM card interfaces, where N is a positive integer greater than 1. The SIM card interface 395 can support Nano SIM cards, Micro SIM cards, SIM cards, etc.

[0091] although Figure 2 Not shown, the electronic device 300 may also be a flashlight, a micro-projection device, a near field communication (NFC) device, etc., which will not be described in detail here.

[0092] After introducing the hardware structure of the electronic device, the system architecture of the electronic device provided by the present application is introduced. The system architecture of the electronic device can adopt a layered architecture, an event-driven architecture, a micro-core architecture, a micro-service architecture, or a cloud architecture. The embodiment of the present application takes a system with a layered architecture as an example to exemplify the software structure of the electronic device.

[0093] The layered architecture divides the software into several layers, each with clear roles and division of labor. The layers communicate with each other through software interfaces. In some embodiments, the PC-side system can be divided into an application layer, a distributed application plug-in, a service collaboration layer, a PC Binder module, a communication module and a device Profile layer, and an inter-process communication (IPC) module from top to bottom.

[0094] The application layer may include a series of application packages. Application packages may include: notes, camera, mail, schedule. Application packages may also include gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, short message and other applications.

[0095] like Figure 3 As shown, the distributed application plug-in is used to process service calls between distributed applications on the PC side to meet the calling requirements of the distributed application framework.

[0096] like Figure 3As shown, the service collaboration layer is used to provide remote service management capabilities, is responsible for forwarding service calls between devices, and converts local resource references (anonymous Binder objects, file descriptors, etc.) into resource references between devices. Among them, the service collaboration layer can include a distributed service management module, a distributed Binder management module, a distributed file management module, a transmission management module, and a device management module.

[0097] The distributed service management module includes a service management module and a service acquisition module. The service management module is used to manage multiple remote devices when there are multiple remote devices. The service acquisition module is used to obtain the target service of device 2 by the service acquisition module of device 1 after the target service of device 2 is fully registered in the scenario where device 1 calls the target service of device 2.

[0098] Among them, the services listed in the distributed service management module are all known services, all system services, that is, all real-name services, and the corresponding Binder objects are all real-name Binders. When the server registers the service provided, it will register the service in the distributed service management module.

[0099] The distributed Binder management module includes a Binder management mapping module and a Binder access authentication module.

[0100] The binders in the distributed binder management module, except for the real-name binders, are all anonymous binders, so their scope is wider than that of the binders in the distributed service management module. Among them, anonymous binders refer to binders that are not registered in the distributed service management module and are binders created by the application itself.

[0101] The Binder management mapping module is used to manage Binder objects, which involves the mapping between the local Binder and the remote Binder.

[0102] The distributed file management module is responsible for reading and writing files across devices. The distributed file management module manages distributed files, mainly operations such as creating files and opening files, which also involves the transmission of messages between devices, and will perform serialization and deserialization.

[0103] The distributed file management module mainly refers to the scenario of taking photos. For example, the PC needs to call the camera function of the mobile phone. In fact, the photo cache file is created by the PC. Then, after taking the photo, the mobile phone needs to obtain the file handle of the photo cache file on the PC side. After obtaining the file handle, write operations need to be performed on this photo cache file. This is where cross-device reading and writing are involved. The distributed file management module can provide access to files across devices. Among them, the file handle is a relatively complex object, similar to the Binder object.

[0104] The transmission management module refers to the channel (session) created between devices, through which messages are transmitted.

[0105] The device management module refers to the connected devices. The devices may be online or offline. Offline means that the device has been connected and then offline, that is, it is no longer connected. Then all resources related to the device must be cleaned up or other operations must be performed. Among them, one or more devices may be connected.

[0106] like Figure 3 As shown, the PC Binder module includes an IPC Client module, a PC Binder software development kit (Software Development Kit, SDK) module (PC Binder SDK module), a PC Binder manager (Manager) module, and a Binder server (Server) module.

[0107] Among them, the client and the server need to initialize the IPC Message component when performing cross-process access. The IPCMessage component is equivalent to the server. Each application needs to use the IPC Message component during cross-process communication, and it needs to generate an IPC Client module internally.

[0108] The Binder SDK module is used to provide interfaces for various businesses, create Binders, and delete Binders.

[0109] The PC Binder management module is used to manage local binder resources. The Binder Server module is used to implement binder calls.

[0110] like Figure 3 As shown, the communication module and device Profile (Device Profile) layer includes a communication module, a device Profile module and a distributed file module.

[0111] The communication module is responsible for transmission, including device discovery and connection services and data transmission services, providing a cross-device transmission interface, supporting automatic networking within a trust ring, one-to-many connections, and awakening dormant devices. In the cross-device call scenario, information is transmitted between devices through the communication module.

[0112] The device Profile module is used to provide device information, service registration interfaces supported by the device, and interfaces for other device query services.

[0113] The distributed file module, namely the distributed file management mentioned above, is responsible for reading and writing files across devices.

[0114] The IPC module includes IPC Message, which is a component of inter-process communication and can be called an IPC communication module. The PC side will rely on the above IPC Message when building the cross-process communication capability.

[0115] In some embodiments, the system on the Android side can be divided into five layers, from top to bottom, namely, application layer, system application framework layer, collaborative service and scheduling layer, communication module and device Profile layer, and kernel layer.

[0116] The application layer may include a series of application packages. Figure 4 As shown, the application package may include: notes, camera, mail, schedule. The application package may also include gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, short message and other applications.

[0117] like Figure 4As shown, the system application framework layer may include an activity management service (ActivityManagerService, AMS), a distributed activity management service (DistributedActivityManagerService, DAMS), a package management service (PackageManagerService, PMS), a distributed package management service (DistributedPackageManagerService, DPMS), a service management module (Service Manager, SM), a distributed service management module (Service Manager, DSM), and a system Binder framework. Among them, AMS, PMS and SM are existing system services in the Android system, and the related functions are not specifically introduced here. Among them, DAMS, DPMS and DSM are system functions newly added to the distributed system in the embodiment of the present application, and together they are a distributed application framework for processing service calls between distributed applications in the present application. Among them, the distributed application framework can provide a distributed application management service for registering in the distributed service management module to realize service calls and management between distributed applications.

[0118] like Figure 4 As shown, the collaborative service and scheduling layer is used to provide remote service management capabilities, including remote service registration and remote service acquisition. It is responsible for forwarding service calls between devices and converting local resource references (anonymous Binder objects, file descriptors, etc.) into resource references between devices. Among them, the collaborative service and scheduling layer can include a distributed service management module, a distributed Binder management module, a distributed file management module, a transmission management module, and a device management module.

[0119] The distributed service management module includes a service registration module, a service management module, a service acquisition module and a service life cycle module. The service management module is used to manage multiple remote devices when there are multiple remote devices.

[0120] The service registration module is used to register the target service of device 2 before device 1 calls the target service of device 2. The service acquisition module is used to obtain the target service of device 2 by the service acquisition module of device 1 after the target service of device 2 is fully registered in the scenario where device 1 calls the target service of device 2.

[0121] The service lifecycle module is used to call the services provided by device A and device B if device 1 can call the services provided by device A and device B. There may be two services on device A and two services on device B. When a service on device A or device B becomes abnormal or disappears, that is, after the service exits, the service lifecycle module of device 1 needs to process the service that has exited. The lifecycle can be understood as a process of creation and closing.

[0122] Among them, the services listed in the distributed service management module are all known services, all system services, that is, all real-name services, and the corresponding Binder objects are all real-name Binders. When the server registers the service provided, it will register the service in the distributed service management module.

[0123] The distributed Binder management module includes a Binder management mapping module, a Binder access authentication module, and a Binder life cycle module.

[0124] The binders in the distributed binder management module, except for the real-name binders, are all anonymous binders, so their scope is wider than that of the binders in the distributed service management module. Among them, anonymous binders refer to binders that are not registered in the distributed service management module and are binders created by the application itself.

[0125] The Binder management mapping module is used to manage Binder objects, which involves mapping between local Binder and remote Binder. The Binder access authentication module is used to manage the distributed Binder access authentication capabilities in cross-device or distributed scenarios.

[0126] The distributed file management module is responsible for reading and writing files across devices. The distributed file management module manages distributed files, mainly operations such as creating files and opening files, which involves the transmission of messages between devices, and will be serialized and deserialized. Among them, the distributed file management module mainly refers to the scenario of taking pictures. For example, the PC needs to call the camera capability of the mobile phone, and the actual photo cache file is created by the PC. Then, after taking the photo, the mobile phone side needs to obtain the file handle of the photo cache file on the PC side. After obtaining the file handle, write operations need to be performed in this photo cache file. That is, reading and writing across devices are involved here. The distributed file management module can provide access to files across devices. Among them, the file handle is a relatively complex object, similar to the Binder object.

[0127] The transmission management module refers to the channel (session) created between devices, through which messages are transmitted. The device management module refers to the connected devices, which may have operations such as online or offline. Offline means that the device has been connected and then offline, that is, it is no longer connected, so all resources related to the device must be cleaned up or other operations must be performed. Among them, one or more devices may be connected.

[0128] like Figure 4 As shown, the communication module and device Profile (Device Profile) layer include a communication module, a device Profile module and a distributed file module. Among them, the communication module is the module responsible for transmission, including device discovery connection services and data transmission services, etc. It provides a cross-device transmission interface, supports automatic networking within a trust ring, one-to-many connections, and awakening dormant devices. In the scenario of cross-device calls, information is transmitted between devices through the communication module. The device Profile module is used to provide device information, provide a service registration interface supported by the device, and an interface for other device query services. The distributed file module, that is, the distributed file management mentioned above, is responsible for reading and writing files across devices.

[0129] like Figure 4 As shown, the kernel layer includes a Binder driver module, which is mainly used for cross-device communication.

[0130] In the embodiment of the present application, the first electronic device is taken as the main device and the second electronic device is taken as the auxiliary device. The first electronic device can call the service of the second electronic device, wherein the first electronic device can be a personal computer, a computer, etc., and the second electronic device can be a tablet, a mobile phone, etc. Among them, in the scenario where the first electronic device calls the service of the second electronic device, the first electronic device can be a client, and the second electronic device can be a server. The server refers to the end that provides the service, and the client refers to the end that uses the service provided by the server.

[0131] A cross-device data processing method provided in an embodiment of the present application can be applied to a scenario in which a first electronic device calls a photo taking service of a second electronic device.

[0132] In the embodiment of the present application, when the first electronic device is started, the PC Binder module (also called Binder module), the service collaboration module and the distributed application plug-in of the first electronic device can be started in sequence, and corresponding IBinder objects need to be created for the services provided respectively. On the PC side, when the module creates an IBinder object for the first time, the corresponding module identifier needs to be obtained first.

[0133] Among them, after the electronic device is started, the IPC communication module is started first. After the IPC communication module is started, the PCBinder module is started. At this time, the PC Binder module initiates a request to the IPC communication module to request to obtain the module identification corresponding to the PCBinder module. In the embodiment of the present application, the PC Binder module is a common module, and each module of the first electronic device can call the PC Binder module, so the PC Binder module can run in the process corresponding to the module that calls the PCBinder module. After the PC Binder module obtains the module identification, that is, after the initialization is completed, the service collaboration module and the distributed application plug-in are started in sequence.

[0134] See also Figure 5 , Figure 5 A schematic diagram of a service collaboration module creating an IBinder object provided in an embodiment of the present application. The service collaboration module creates a corresponding IBinder object by calling the PC Binder SDK module (first Binder management module). At this time, the PC Binder SDK module determines whether there is a module identifier for the service collaboration module. For example, the PCBinder SDK module identifies the process number contained in the received call request, identifies the process corresponding to the process number, that is, identifies which module's process sends the call request, and then searches the stored module identifier list for a module identifier corresponding to the module. Then, the PC Binder SDK module generates judgment information, which is used to indicate whether there is a module identifier for the service collaboration module of the first electronic device.

[0135] If the PC Binder SDK module does not store the module identifier corresponding to the module, that is, if the above judgment information indicates that the service collaboration module does not have a module identifier, the corresponding module identifier is allocated through the IPC communication module.

[0136] Specifically, Figure 5As shown, the service collaboration module of the first electronic device sends a request to the PC Binder SDK module to create a corresponding IBinder object. After receiving the request, the PC Binder SDK module sends a request to the IPC communication module to request the module identifier of the service collaboration module. After receiving the request, the IPC communication module allocates an available module identifier to the service collaboration module. Then, the IPC communication module returns the module identifier to the PC Binder SDK module. After receiving the module identifier corresponding to the service collaboration module, the PCBinder SDK module creates an IBinder object corresponding to the service provided by the service collaboration module, and sends the IBinder object and the module identifier to the PC Binder management (second Binder management module) module. The PC Binder management module applies for a unique identifier for the IBinder object corresponding to the service collaboration module, and associates the unique identifier with the module identifier.

[0137] See also Figure 6 , Figure 6 A schematic diagram of a distributed application plug-in creating an IBinder object provided in an embodiment of the present application. Figure 6 As shown, the distributed application plug-in of the first electronic device sends a request to the PC Binder SDK module to request the creation of an IBinder object corresponding to the service provided by the distributed application plug-in. After receiving the request, the PC Binder SDK module sends a request to the IPC communication module to request the module identifier of the distributed application plug-in. After receiving the request, the IPC communication module allocates an available module identifier to the distributed application plug-in. Then, the IPC communication module returns the module identifier to the PC Binder SDK module. After receiving the module identifier corresponding to the distributed application plug-in, the PC Binder SDK module creates an IBinder object corresponding to the distributed application plug-in, and sends the IBinder object and the module identifier to the PCBinder management module. The PC Binder management module applies for a unique identifier for the IBinder object corresponding to the distributed application plug-in, and associates the unique identifier with the module identifier.

[0138] In other words, the service collaboration module and the distributed application plug-in do not need to obtain the module identifier in advance. Instead, they will obtain the corresponding module identifier through the IPC communication module when they need to create an IBinder object, and then create the corresponding IBinder object and associate it with the corresponding module identifier so that it can be forwarded to the corresponding module based on the module identifier through the IPC communication module when used.

[0139] In the embodiment of the present application, in addition to starting the first module of the first electronic device when the first electronic device is started, when the first electronic device receives the user's operation, it can be considered that the user has the intention of cross-device call, and at this time, the first module of the first electronic device is started. The first module is a module required for cross-device call, and the first module includes the above-mentioned service collaboration module and distributed application plug-in.

[0140] Taking the example of the note application of the first electronic device calling the camera application of the second electronic device to take a photo, the first electronic device responds to the user's first operation on the note application (first application) to start the first module of the first electronic device, and needs to create corresponding IBinder objects for the services provided by each first module. The above-mentioned first operation can be a touch operation. For example, the first operation includes clicking a button on the display interface of the first application, and after displaying the list available for cross-device calls, clicking the target device and target service in the list.

[0141] For details, please refer to Figure 7 In the step of, in response to the user's first operation on the first application, the first electronic device obtains judgment information; wherein the judgment information is used to indicate whether the first module of the first electronic device has a module identifier. In the case where the judgment information indicates that the first module does not have a module identifier, the first electronic device obtains the first module identifier corresponding to the first module through the Binder module (PC Binder module) of the first electronic device. After the first electronic device obtains the first module identifier corresponding to the first module, the first electronic device creates a target IBinder object for the first service through the Binder module, and determines the first identifier of the target IBinder object; wherein the first identifier is associated with the first module identifier, and the target IBinder object is used to call the first service provided by the first module.

[0142] Then, the first electronic device can call the target service of the second electronic device based on the distributed application plug-in corresponding to the target module identifier in the first module identifier. Therefore, the cross-device data processing method provided by the embodiment of the present application can perform IPC initialization through the Binder module corresponding to each module when each module creates an IBinder object for the provided service for the first time, avoiding the additional steps of initializing the IPC communication component, so that each module of the client does not need to perceive the underlying IPC communication component framework, and can directly perform Binder calls. The above-mentioned first module does not interact directly with the IPC communication module, but interacts with the IPC communication module through the corresponding Binder module to complete the initialization of the IPC. For the first module, there is no need to pay attention to the process of IPC communication, only to send a call message to the Binder module, and the rest of the process is in the Binder module, which is implemented through the interaction between the Binder module and the IPC communication module.

[0143] The specific process of the first electronic device calling the target service of the second electronic device is described in detail below.

[0144] Taking the scenario where the note application of the first electronic device calls the photo service of the camera application of the second electronic device as an example, the second electronic device first registers the distributed application management service (target service) in the device itself, and the first electronic device obtains the distributed application management service registered by the second electronic device. After the first electronic device successfully obtains the distributed application management service of the second electronic device, the note application of the first electronic device pulls up the camera application of the second electronic device. After the camera application takes a photo of the specified content, the second electronic device obtains the photo data and transmits it to the note application of the first electronic device.

[0145] Therefore, in the embodiment of the present application, the overall process of the cross-device data processing method mainly includes service registration of the second electronic device, acquisition of the service by the first electronic device, and transmission of the service data (photographing data) of the second electronic device back to the first electronic device.

[0146] First, the service registration process of the second electronic device is introduced. The service registered by the second electronic device at this time is the distributed application management service.

[0147] The application (e.g., camera application) is an interface provided by the distributed application framework, which is in the system application framework. After the first electronic device obtains the distributed application management service registered by the second electronic device, it can call the camera application of the second electronic device through the distributed application framework to obtain the service provided by the camera application.

[0148] Among them, the distributed application management service is in the system application framework. When the second electronic device is turned on, the system application framework will be started, that is, the distributed application management service will be started. After the second electronic device is turned on, the communication module is started. After the communication module is started, the service collaboration module is started. Therefore, after the service collaboration module is started, the second electronic device can register the distributed application management service in the service collaboration module.

[0149] The service registration process of the second electronic device is also the registration process of the distributed application management service of the second electronic device, which specifically includes:

[0150] The distributed application management service of the second electronic device is registered in the distributed service management module (Distributed Service Manager) (refer to Figure 8 Step 1) wherein the distributed application management service is in the system application framework of the second electronic device, and after the second electronic device is turned on, the distributed application management service is started.

[0151] The service name (e.g., "DisApp") and IBinder object (e.g., "IBinder S1") of the distributed application management service are stored in the distributed service management module (refer to Figure 8 Then, the service name and the IBinder object are sent to the distributed Binder management module. The distributed Binder management module caches the IBinder object (the above-mentioned IBinder S1) and assigns a BinderId (for example, "Binder S1") to the IBinder object. That is, a mapping relationship is established between IBinder S1 and Binder S1 (refer to Figure 8 Then, the distributed Binder management module returns the registration result to the system application framework (refer to Figure 8 Step 1.3).

[0152] Among them, the service name and IBinder are parameters, and an IBinder object can call a target service. After the first electronic device obtains the IBinder object of the target service of the second electronic device, the IBinder object can be used to call the interface of the corresponding target service, that is, to call the capabilities that the target service can provide. In an embodiment of the present application, after the first electronic device obtains the IBinder object of the distributed application management service of the second electronic device, it can call the distributed application management service of the second electronic device.

[0153] Each service is set with a corresponding service name (ServiceName), such as distributed application management service, AMS service, camera service, audio service, etc. Among them, the service name will be registered in the service management module. If it is a distributed service scenario, the service name can be registered in the distributed service management module.

[0154] In the embodiment of the present application, a unique identifier (BinderId) can be assigned to the IBinder object, each IBinder object has a BinderId, and the BinderId can establish a mapping relationship with the IBinder object. In other words, there is a BinderId for the service registered in the server, and when the client obtains the corresponding service, the BinderId can identify the relationship between the two. Among them, the mapping relationship can be understood as a key-value pair.

[0155] The BinderId may be allocated according to the device. For example, when multiple second electronic devices are connected, the second electronic device first sets the device identifier (DeviceId), and then allocates the BinderId to the service on each second electronic device. The device identifier may be pre-set.

[0156] Specifically, BinderId can be assigned in a certain order. For example, the second electronic device A can provide service a (IBinder a) and service b (IBinder b), and the second electronic device B can provide service c (IBinder c). Then, the BinderId corresponding to IBinder a can be Binder1, the BinderId corresponding to IBinder b can be Binder2, and the BinderId corresponding to IBinder c can be Binder3. The form of BinderId is not limited to numbers, but can also be letters, text, etc. When using numbers as BinderId, it does not necessarily start from 1, but can also start from a specific number and increase sequentially.

[0157] In the embodiment of the present application, the second electronic device stores the service name and IBinder object of the distributed application management service, and the second electronic device assigns a BinderId to the IBinder object. Then, in the subsequent steps, the distributed application management service can be obtained through the corresponding service name. The specific acquisition process is to determine the IBinder object through the service name, and after determining the IBinder object, the corresponding BinderId can be determined. The IBinder object and the BinderId are one-to-one corresponding.

[0158] It is understandable that for real-name services, what is stored on the server side is the service name, IBinder object and BinderId. The above relationship is stored in the distributed service management module on the server side. Among them, the system service will have a corresponding service name, and the service name will be registered in the distributed service management module. Therefore, the system services are all real-name services.

[0159] The storage method may be a list method, as shown in Table 1:

[0160] Service Name IBinder Object BinderId Service S1 IBinder S1 BinderId S1 Service S2 IBinder S2 BinderId S2

[0161] Table 1

[0162] The storage can also be divided into two lists, that is, the service name and IBinder object can be stored in one list, and the IBinder object and BinderId can be stored in another list. There is a one-to-one correspondence between the three.

[0163] In the embodiment of the present application, after the distributed Binder management module of the second electronic device assigns a BinderId to the IBinder object and establishes a mapping relationship, it indicates that the distributed application management service of the second electronic device has been successfully registered. The distributed Binder management module of the second electronic device can send a notification message of successful registration to the system application framework of the second electronic device. At this time, the first electronic device can obtain the distributed application management service registered by the second electronic device.

[0164] Next, the process of the first electronic device acquiring a service is introduced. After the second electronic device successfully registers the distributed application management service, the first electronic device can acquire the distributed application management service registered by the second electronic device.

[0165] It is understandable that before obtaining the distributed application management service, the first electronic device has already opened the note application, and the first electronic device calls out the device list and capability list in response to the user's touch operation on the call entry of the note application interface. In other words, when the first electronic device receives the user's operation, it can be considered that the user has the intention of cross-device call, and therefore needs to obtain the distributed application management service provided by the second electronic device.

[0166] Among them, the application of the first electronic device can obtain a list of devices within a set range through interactions between devices. The distributed application framework of each device can determine whether the device has a service collaboration module. If a device does not have a service collaboration module, the device does not have the ability to call across devices, and an empty message is sent to the application of the first electronic device. Then the application interface of the first electronic device will not display the device name of the device, or it will display the device name of the device, but distinguish it from other devices with cross-device calling capabilities through specific identifiers.

[0167] In the embodiment of the present application, a calling entry is provided in the note application of the first electronic device. Fig. 9 As shown, an insert button 502 is provided on the display interface 501 of the note application of the computer. After the computer responds to the user's touch operation on the insert button 502, the display interface 502 displays the second electronic device that can provide services and the capability list corresponding to the device. The displayed devices may be a mobile phone 1 and a tablet 1. The capability list includes the services that the second electronic device can provide, such as Fig. 9 Among them, mobile phone 1 corresponds to taking pictures, scanning, etc., and tablet 1 corresponds to taking pictures, scanning, etc.

[0168] In some embodiments of the present application, the display interface of the note application can display all devices with cross-device calling capabilities within a set range. For example, if all devices with cross-device calling capabilities within the set range are mobile phone 1 and tablet 1. Fig. 9 As shown, the displayed devices are a mobile phone 1 and a tablet 1, and the mobile phone 1 and the tablet 1 can provide photo taking, scanning, etc. respectively.

[0169] In some embodiments of the present application, the display interface of the note application can also display all devices within a set range, and distinguish whether the device has the cross-device calling capability through a set identifier. For example, devices that do not have the cross-device calling capability can be displayed in gray, and other devices that have the cross-device calling capability can be displayed normally.

[0170] In some embodiments of the present application, the capability list corresponding to the device may also display all possible services, distinguish whether the service is provided by the device through the set identification information, or only display the services that the device can provide.

[0171] In some embodiments of the present application, the display interface of the note-taking application may first display a device list, and then, in response to a touch operation on a device in the device list, display a capability list corresponding to the device.

[0172] In the embodiment of the present application, in response to an opening operation of an application on the first electronic device, the application interface is displayed, and then in response to a touch operation on a target button (such as Fig. 9 ), then the application interface of the first electronic device will display a device list and a corresponding capability list.

[0173] In some other embodiments of the present application, in response to an opening operation of an application on the first electronic device, an application interface is displayed, and the application interface directly displays a device list and a corresponding capability list.

[0174] That is, before the first electronic device obtains the service, the device list and the capability list are displayed, and then in response to the user's touch operation on a certain item in the list, for example, after the first electronic device responds to the user's touch operation on the camera service option of mobile phone 1 in a list of a certain application, it can be determined that the corresponding second electronic device is mobile phone 1, and the target service is the distributed application management service. At this time, the first electronic device can start to obtain the distributed application management service of mobile phone 1.

[0175] Please refer to Figure 8 , the note application of the first electronic device can obtain the distributed context of the second electronic device, that is, obtain the "DisApp" service of the second electronic device (refer to Figure 8 Step 2). Specifically, the process of the first electronic device obtaining the service includes: the note application of the first electronic device sends a request for obtaining the "DisApp" service to the distributed application plug-in of the first electronic device. The request here is an IPC call request, and the first electronic device needs to communicate between various modules through the IPC communication component (IPC communication module). It can be understood that the note application and the distributed application plug-in are different processes, and when communicating, it is also necessary to obtain the module identification of the distributed application plug-in and forward it through the IPC communication module.

[0176] Then, the distributed application plug-in initiates a request to obtain services from the distributed service management module of the first electronic device. Specifically, the distributed application plug-in initiates a request to obtain services from the IPC communication module of the first electronic device, and the request carries the device identifier (DeviceId) and the service name (ServiceName). The service name carried here is "DisApp" (refer to Figure 8 Step 2.1).

[0177] After receiving the request, the IPC communication module sends the request for obtaining the service to the distributed service management module of the first electronic device. The IPC communication module can forward the request to the distributed service management module based on the module identifier of the distributed service management module. Then, the distributed service management module of the first electronic device sends a request for obtaining the "DisApp" service to the message center (Message Center)-communication module of the first electronic device (refer to Figure 8Step 2.2). The service collaboration module of the first electronic device includes a distributed service management module and a distributed Binder management module, and the distributed service management module and the distributed Binder management module are in the same process. Therefore, the module identifiers of the distributed service management module and the distributed Binder management module are the module identifier of the service collaboration module.

[0178] It is understandable that for a request to obtain a service, the IPC communication module will forward the request to the distributed service management module based on the content of the request, rather than the distributed Binder management module. After the distributed service management module obtains the BinderId corresponding to the service, it will call the distributed Binder management module to create a local IBinder object.

[0179] After receiving the request for obtaining the "DisApp" service, the communication module of the first electronic device creates a channel (session) with the second electronic device (refer to Figure 8 Step 2.2.1).

[0180] In some embodiments of the present application, the first electronic device may establish a connection with the second electronic device according to the device identification in the request. After the connection is established, the corresponding service is searched from the second electronic device according to the service name in the request.

[0181] The specific step of the first electronic device searching for a service from the second electronic device includes: creating a session between the first electronic device and the second electronic device. After the session is successfully created, the first electronic device searches for a corresponding service from the second electronic device according to the service name.

[0182] The specific steps of creating a channel include: after the communication module of the first electronic device and the communication module of the second electronic device successfully create a channel, the communication module of the second electronic device sends a channel creation success instruction to the distributed Binder management module of the second electronic device, and the communication module of the first electronic device sends a channel creation success instruction to the distributed Binder management module of the first electronic device. The distributed Binder management module here is used to manage Binder objects.

[0183] Among them, the specific steps of the first electronic device searching for the corresponding service from the second electronic device according to the service name include: the first electronic device sends the service name to be obtained to the target device through a message. After the second electronic device receives the message, it parses the service name according to the message content. Then search for the target service corresponding to the service name from the distributed service management module. The distributed service management module stores the correspondence between the service name and the IBinder object.

[0184] If the corresponding target service is found, the IBinder object corresponding to the target service is determined, and then the IBinder object is returned to the first electronic device.

[0185] Among them, the communication module is a message receiving module with the function of receiving messages. After the communication module of the second electronic device receives the message, the message can be parsed. If the message contains a service name, then the message can be considered to be a query-type instruction message. Then, based on the service name in the message, the corresponding target service can be queried in the distributed service management module. If the distributed service management module stores a service name that is the same as the service name in the message, it means that the corresponding target service is found. The second electronic device returns the IBinder object corresponding to the target service to the communication module of the second electronic device.

[0186] It is understandable that the distributed Binder management module of the second electronic device establishes a mapping relationship between the IBinder object and the BinderId. After the mapping relationship is successfully established, the distributed Binder management module of the second electronic device sends the mapping relationship to the distributed service management module, and the distributed service management module saves the mapping relationship. Figure 4 The communication module of the second electronic device performs a query in the distributed service management module according to the mapping relationship.

[0187] Among them, after the second electronic device finds the corresponding IBinder object according to the service name in the distributed service management module, it sends the IBinder object back to the distributed Binder management module of the second electronic device. The distributed Binder management module of the second electronic device determines the BinderId corresponding to the IBinder object based on the established mapping relationship between the IBinder object and the BinderId. Then, the determined BinderId is sent to the communication module of the second electronic device.

[0188] That is to say, when the two devices actually interact, what the communication module of the second electronic device sends to the communication module of the first electronic device is BinderId.

[0189] It should be noted that the IBinder object of the target service generated by the second electronic device is not actually sent to the client. This is because the IBinder object has a system boundary and is only meaningful on the second electronic device. The IBinder object can be understood as a pointer or address. There is no practical meaning in sending the IBinder object to the first electronic device. Therefore, the second electronic device sends the BinderId to the first electronic device.

[0190] Specifically, after receiving the BinderId of the target service, the communication module of the second electronic device assembles the message and sends the message to the communication module of the first electronic device. In other words, the message carries the BinderId of the target service.

[0191] See also Figure 8 After receiving the message, the communication module of the second electronic device parses the message and obtains an instruction to obtain the "DisApp" service (refer to Figure 8 The communication module of the second electronic device sends the instruction to the distributed Binder management module of the second electronic device (refer to Figure 8 Step 2.2.4).

[0192] After receiving the instruction, the distributed Binder management module of the second electronic device searches for the "DisApp" service in the distributed service management module. Among them, it can be seen from step 1.1 that the distributed service management module of the second electronic device stores the service name and the corresponding IBinder object. Therefore, the distributed Binder management module of the second electronic device can search whether the service is stored in the distributed service management module according to the service name ("DisApp") in the above instruction. If the service ("DisApp" service) is found, the corresponding IBinder object (IBinder S1) is determined.

[0193] Then, the distributed service management module of the second electronic device returns the IBinder object (IBinder S1) to the distributed Binder management module of the second electronic device. The distributed Binder management module of the second electronic device determines the BinderId (BinderId S1) corresponding to the IBinder object (IBinder S1) according to the established mapping relationship between the IBinder object and the BinderId (refer to Figure 8 Then, the BinderId (BinderId S1) is sent to the communication module of the second electronic device (refer to Figure 8 Step 2.2.5).

[0194] After receiving the BinderId (BinderId S1) of the "DisApp" service, the communication module of the second electronic device assembles it into a message (the message carries BinderId S1) and sends the message to the communication module of the first electronic device.

[0195] The communication module of the first electronic device receives the message, that is, receives the BinderId of the target service carried in the message. Specifically, the communication module of the first electronic device receives the message and parses the information content to obtain the BinderId (BinderId S1) of the "DisApp" service. The communication module of the first electronic device sends the BinderId (BinderId S1) of the "DisApp" service to the distributed service management module of the first electronic device (refer to Figure 8 (Step 2.2.6).

[0196] In the embodiment of the present application, the first electronic device will create a local IBinder object according to the received BinderId. The distributed service management module of the first electronic device creates a corresponding local IBinder object (set to IBinderC1) according to the received BinderId S1, and establishes a mapping relationship with BinderId S1 (refer to Figure 8 Step 2.2.7). Specifically, the distributed service management module of the first electronic device sends a creation request to the distributed Binder management module of the first electronic device, and the creation request includes the BinderId (BinderId S1) of the "DisApp" service; the distributed Binder management module of the first electronic device newly creates a corresponding local IBinder object (IBinder C1) according to BinderId S1, that is, the distributed Binder management module creates a mapping relationship between BinderId S1 and IBinder C1, and stores the mapping relationship (refer to Figure 8 (as in step 2.2.7.1).

[0197] Then, after the first electronic device creates a local IBinder object, it applies for a unique identifier (set as the first identifier) ​​for the local IBinder object. And, the identifier is associated with the module identifier 3. Specifically, the distributed Binder management module of the first electronic device sends a creation success instruction to the PC Binder SDK module of the first electronic device. After receiving the creation success instruction, the PC Binder SDK module of the first electronic device sends a request to the PCBinder management module of the first electronic device to request the application for the unique identifier (first identifier) ​​of IBinder C1 and associate it with the module identifier (moduleId3) of the service collaboration module, that is, to create a mapping relationship between IBinder C1 and moduleId3, and store the mapping relationship (refer to Figure 8Step 2.2.7.2). Among them, IBinder C1 is created in the distributed Binder management module of the service collaboration module, so the unique identifier of IBinder C1 needs to be associated with the module identifier (moduleId3) of the service collaboration module.

[0198] It should be noted that the first identifier applied for the newly created local IBinder object is different from the obtained Binder identifier (BinderId) in terms of function and meaning. If the first electronic device makes a cross-device call on the Android system, it is not necessary to re-apply for the first identifier for the locally created IBinder object.

[0199] Among them, the cross-process communication on the PC side needs to rely on the IPC message module. The IPC message module can forward the call message to the corresponding module according to the obtained module identifier.

[0200] It is understandable that in the process of sending IBinder C1 from the service collaboration module to the distributed application plug-in, what the distributed application plug-in actually obtains is not the IBinder C1 object, but the reference object of IBinder C1. Since the reference object of the above-mentioned IBinder C1 needs to be sent to the distributed application plug-in, the first identifier corresponding to the reference object of the above-mentioned IBinderC1 needs to be associated with the module identifier of the distributed application plug-in. Therefore, the IPC communication module can send the reference object of IBinder C1 to the distributed application plug-in based on the module identifier of the distributed application plug-in.

[0201] In an embodiment of the present application, the distributed application plug-in of the first electronic device is used to process service calls between distributed applications. Therefore, service call messages across devices need to be sent to the distributed application plug-in.

[0202] After the PC Binder management module of the first electronic device creates the mapping relationship between IBinder C1 and the module identifier 3, the PC Binder management module returns the newly created IBinder object to the note application 1 of the first electronic device. Specifically, the PC Binder management module of the first electronic device returns IBinderC1 to the PC Binder SDK module of the first electronic device. The PC Binder SDK module of the first electronic device then returns IBinderC1 to the distributed Binder management module of the first electronic device (refer to Figure 8 Step 2.2.7.3).

[0203] Then, the distributed Binder management module of the first electronic device returns the service name ("DisApp") and the corresponding IBinder object (IBinder C1) to the distributed service management module of the first electronic device. The distributed service management module of the first electronic device stores the service name ("DisApp") and the corresponding IBinder object (IBinder C1) (refer to Figure 8 (Step 2.2.8).

[0204] The distributed service management module of the first electronic device returns the distributed context to the distributed application plug-in and note application of the first electronic device, that is, the local IBinder object created in the above process, the mapping relationship, etc. (refer to Figure 8 Step 2.3).

[0205] Among them, for different modules of the first electronic device, if they belong to different processes, the IBinder object actually obtained by each process is not an entity, but a reference object of the entity object. Then, in the process of creating a reference object, it is necessary to associate the unique identifier of the reference object with the module identifier of the module to be sent to, so that the IPC communication module can send the reference object to the corresponding module based on the module identifier.

[0206] Therefore, the distributed application plug-in of the first electronic device actually receives the first reference object of IBinder C1, and the note application of the first electronic device actually receives the reference object of the first reference object, that is, the second reference object of IBinderC1. Then, the distributed service management module of the first electronic device returns IBinder C1 to the distributed application plug-in of the first electronic device. The specific process is to create the first reference object of IBinder C1 in the PC Binder module, associate the first identifier of the first reference object with the module identifier of the distributed application plug-in, and forward the first reference object to the distributed application plug-in by the IPC communication module.

[0207] In the process of the above-mentioned distributed application plug-in returning the created local IBinder object to the note application, it is not actually returning the local IBinder object (IBinder C1) to the note application, but returning the second reference object of IBinder C1 to the note application. At this time, it is equivalent to the note application of the first electronic device creating an IBinder object for the first time, and the note application has not yet been assigned a corresponding module identifier. Therefore, the note application needs to obtain the module identifier in order to receive messages from other processes through the IPC communication module.

[0208] Specifically, Fig.10As shown, the note application of the first electronic device sends a request to the PC Binder SDK module of the first electronic device to request to obtain the module identifier of the note application. The PC Binder SDK module of the first electronic device initiates a request to the IPC communication module of the first electronic device. After receiving the request, the IPC communication module of the first electronic device assigns a module identifier to the note application, and then returns the module identifier to the PC Binder SDK module.

[0209] Then, the PC Binder SDK module creates a second reference object of IBinder C1 and applies for a unique identifier for the second reference object. Specifically, the PC Binder SDK module sends a request to the PC Binder management module, which, after receiving the request, applies for a unique identifier for the second reference object and associates it with the module identifier of the note application.

[0210] Thus, the IPC communication module sends the reference object to the note application based on the module identifier of the note application.

[0211] It is understandable that the newly created IBinder object of the first electronic device is created based on the BinderId carried in the received message, that is, the BinderId transmitted from the second electronic device to the first electronic device. Among them, the BinderId is unchanged. Then, the first electronic device creates a corresponding IBinder object based on the BinderId. In other words, in the first electronic device, a mapping relationship is also established between the BinderId and the new IBinder object.

[0212] That is to say, in the embodiment of the present application, in order to enable the first electronic device to call the second electronic device, a virtual IBinder object is created for the first electronic device and then corresponds to the received BinderId.

[0213] It should be noted that, since the IBinder object cannot be directly identified on the Windows system, it is necessary to apply for a unique first identifier for the locally created IBinder object and associate it with the module identifier in order to achieve transmission between the modules of the first device. For example, if the IPC message module is required to forward the call message related to the newly created local IBinder object to the distributed application plug-in, the first identifier is associated with the module identifier of the distributed application plug-in. If the IPC message module is required to forward the call message related to the newly created local IBinder object to other modules, the first identifier is associated with the module identifiers of other modules.

[0214] In some embodiments of the present application, the first electronic device may be calling the camera service of the second electronic device for the first time, or there may be multiple calls. Then, after the first electronic device obtains the camera service of the camera for the first time, the obtained call information of the camera service can be cached locally. Therefore, the first electronic device can first search for the second electronic device and the distributed application management service from the local cache. If it is found, it will be directly returned to the note application. If it is not found, it can be searched from the second electronic device. For example, application 1 of computer 1 has called the scanning service of mobile phone 1 once, so the next time application 1 of computer 1 is to make a scanning service call, it can directly search the name of mobile phone 1, the name of the distributed application management service, and the IBinder object corresponding to the distributed application management service, the first identifier, the module identifier and other information from the local cache of computer 1.

[0215] In some embodiments of the present application, if the target service is not found in the local cache, that is, the device name and the corresponding service name are not stored in the local cache, then the first electronic device may search for the corresponding target service in the second electronic device.

[0216] In some embodiments, after the first electronic device obtains the target service registered by the second electronic device, the first electronic device can call the service interface of the second electronic device. That is, after the first electronic device obtains the service provided by the application of the second electronic device, it calls the interface of the service through the IBinder object. Among them, when the client calls the service interface of the server, it sends a service call request (request) to the server; after the server receives the request, it calls the corresponding service interface, and then returns a reply (reply) containing the call result to the client.

[0217] The request may contain an anonymous IBinder object or may not contain an anonymous IBinder object. An anonymous IBinder object is an IBinder object that has not been submitted to the distributed service management module for registration. An anonymous IBinder object can call an anonymous service. When the client calls a service registered by the server, if a simple instruction is transmitted during the request, there are no instructions that need to be further called (equivalent to the request not containing an anonymous IBinder object). If the returned result can be used directly, there are no instructions that need to be further called (equivalent to the reply not containing an anonymous IBinder object). If the returned result cannot be used directly, the returned result must be used for further access or call (equivalent to the reply containing an anonymous IBinder object).

[0218] For example, if the service provided by the second electronic device is a computing service, such as a simple adder (a+b). For the application of the first electronic device, the input parameters are two numbers a and b. By calling the interface of the service, the result c can be directly obtained. The result c is a number and does not contain anything else. The above situation is equivalent to the request not containing the IBinder object, and the reply (reply) does not contain the IBinder object.

[0219] For another example, if the service provided by the second electronic device is the camera photography service. For the application of the second electronic device (i.e., the camera), after taking a photo, when the photo data needs to be transmitted back to the application of the first electronic device (such as the note application), it is necessary to first obtain the file handle of the photo cache file of the note, and then write the photo data back to the photo cache file of the application of the first electronic device. Since the file handle is a local resource of the first electronic device, it cannot be directly obtained. Therefore, the file handle is hosted in a certain service (such as the Provider service), and the second electronic device obtains the FileProvider object of the note, and then obtains the file handle through the object. The above situation is equivalent to the request not containing an anonymous IBinder object, and the reply containing an anonymous IBinder object. It can be understood that in the process of the camera obtaining the FileProvider object of the note, it is equivalent to the camera obtaining the service of the note. Therefore, in the process of the camera obtaining the FileProvider object of the note, the camera acts as the client at this time, and the note acts as the server at this time. The camera sends a request to the note (i.e., obtains the FileProvider object of the note), and the camera receives the reply returned by the client (i.e., the FileProvider object of the note). Among them, the note obtains its own FileProvider object, which is not registered in the distributed application management service module, which is equivalent to an anonymous IBinder object.

[0220] For another example, if the request sent by the client to the server contains an anonymous IBinder object, then after the server obtains the IBinder object, it can call the interface provided by the IBinder object in the client.

[0221] In an embodiment of the present application, in a scenario where a first electronic device calls a camera application of a second electronic device, after the first electronic device obtains the "DisApp" service registered by the second electronic device, the first electronic device can directly open the camera application of the second electronic device.

[0222] The specific process of the note application of the first electronic device opening the camera application of the second electronic device is as follows:

[0223] like Fig.11 As shown, the note application makes an IPC call through the locally created IBinder C1. Specifically, the note application sends a start activity for result (intent) message to the distributed application plug-in of the first electronic device (refer to Fig.11 Step 1), the intent includes uri and device information. The distributed application plug-in sends the call message to the PC Binder SDK module of the first electronic device (refer to Fig.11 Step 1.1). The PC Binder SDK module sends the call message to the PC Binder management module of the first electronic device, and obtains the unique identifier (set as Id1) corresponding to IBinder C1 (refer to Fig.11 Step 1.2). The PC Binder management module of the first electronic device finds the corresponding module identifier (moduleId3) according to the unique identifier (refer to Fig.11 Step 1.3).

[0224] It is understandable that what is created in the distributed Binder management module is the IBinder C1 object, and what is obtained in the distributed application plug-in is the reference object of the IBinder C1 object. Therefore, the distributed application plug-in actually initiates a call based on the reference object of the IBinder C1 object. The distributed application plug-in wants to send the call message to the distributed Binder management module. Then, in the PC Binder management module, it is necessary to first find IBinder C1 by the reference object, and then determine the unique identifier of IBinder C1. Then, the PC Binder management module finds the corresponding module identifier based on the association relationship of the unique identifier, that is, the module identifier (moduleId3) of the distributed Binder management module.

[0225] The PC Binder management module of the first electronic device may forward the call message to the module corresponding to moduleId3 through the IPC communication module of the first electronic device (refer to Fig.11 Step 1.4). Specifically, the distributed application plug-in initiates a call to the distributed Binder management module, that is, sends a call message to the IPC communication module, and the call message contains the module identifier 3. After receiving the call message, the IPC communication module forwards the call message to the corresponding distributed Binder management module based on the module identifier 3. The above process is equivalent to the distributed application plug-in of the first electronic device calling the onTransact method (refer to Fig.11 Step 1.5), sending the call message to the distributed Binder management module of the first electronic device.

[0226] The distributed Binder management module of the first electronic device sends the call message to the communication module of the second electronic device through the communication module of the first electronic device. The communication module of the second electronic device then forwards the call message to the distributed Binder management module in the service collaboration module of the second electronic device, and the distributed Binder management module of the second electronic device forwards the call message to the system application framework of the second electronic device.

[0227] The system application framework of the second electronic device sends a start activity message to the camera application, and calls the start activity method through the locally created IBinder S1 to start the camera. Then, the system application framework assembles the result data (camera on) returned by the camera application into a result message and sends it to the distributed Binder management module in the service collaboration module of the second electronic device.

[0228] The service collaboration module of the second electronic device sends the result message to the service collaboration module of the first electronic device. Specifically, the communication module of the second electronic device sends the result message to the communication module of the first electronic device. The communication module of the first electronic device then forwards the result message to the distributed Binder management module in the service collaboration module of the first electronic device.

[0229] The distributed Binder management module of the first electronic device sends the result message to the distributed application plug-in module of the first electronic device. At this time, the camera is turned on successfully.

[0230] In the embodiment of the present application, the messages transmitted between the above modules can be encapsulated in a parcel package, and each message is transmitted by transmitting the parcel package in each module. For example, the above call message and result message can be encapsulated in a parcel package and transmitted between each module of the first electronic device and the second electronic device.

[0231] After the first electronic device obtains the "DisApp" service registered by the second electronic device and the camera application of the second electronic device is opened, the user uses the camera application to take a photo of the information that needs to be sent back to the notes, and the camera application responds to the user's operation and sends the acquired photo data back to the notes. For example, insert the blackboard content of an offline class into the note application, then after the camera application is opened, the user uses the camera to take a photo of the blackboard content, and the camera responds to the user's click on the photo button to obtain a blackboard photo (photographed data of the blackboard content). Then, the camera sends the blackboard photo back to the notes.

[0232] The camera obtains the photo in response to the user's click operation on the photo button, and then can confirm whether the photo meets the user's requirements. The camera obtains the confirmed photo in response to the user's click operation on the confirmation button, that is, after confirming that the photo meets the user's requirements. The camera returns the confirmed photo to the note. That is, after the camera responds to the user's click operation on the confirmation button, the camera returns the photo data to the note of the first electronic device.

[0233] Among them, for the camera, after taking a photo, when the photo data needs to be transmitted back to the note application, it is necessary to first obtain the file handle of the photo cache file of the note, and then write the photo data back to the photo cache file of the client application. Since the file handle is a local resource of the first electronic device, it cannot be directly obtained. Therefore, the file handle can be hosted in a certain service (such as a Provider service), and the camera obtains the File Provider object (file provider object) of the note, and then obtains the file handle through the object. It can be understood that what the camera application sends to the note application is a simple acquisition instruction (request), and the result (reply) returned by the note application to the camera application is an object that needs to be further called. The above situation is equivalent to the request not containing an anonymous IBinder object, and the reply containing an anonymous IBinder object.

[0234] Therefore, the specific steps of transmitting the service data (photographing data) of the second electronic device back to the first electronic device include: the camera application obtains the IContent Provider object (i.e., the File Provider object) of the note application, the camera application obtains the file handle of the photo cache file of the note application, and the camera application writes the photographing data back to the first electronic device. The photographing data refers to the result of the second electronic device executing the distributed application management service.

[0235] The note application of the first electronic device can create a photo cache file (File Provider) with a Uniform Resource Identifier (URI). Specifically, the photo cache file has a File Provider (equivalent to an IBinder object), and the note application registers the File Provider in the distributed application plug-in. The note application can create a photo cache file in response to a user's touch operation on a camera option, or it can create a photo cache file at any time before obtaining the file handle of the photo cache file.

[0236] See also Fig.12 , Fig.12This is a sequence diagram of the File Provider object for obtaining notes provided in the embodiment of the present application. Fig.12 As shown, when the camera application uses IBinder S1 to call the corresponding interface of the note application, it enters the distributed Binder management module of the service collaboration module (refer to Fig.12 Step 1.1), the input parameters in the interface call (by calling the transact method) can be encapsulated in a Parcel package (that is, the request parcel) (refer to Fig.12 Step 1.2).

[0237] The distributed Binder management module of the service collaboration module processes the request parcel (set to reqA) (refer to Fig.12 Step 1.3). Specifically, first determine whether reqA contains an anonymous IBinder object. By parsing reqA, it can be determined that reqA does not contain an anonymous IBinder object. It can be understood that since reqA is only used to obtain the File Provider object of the note and does not need to be further called, reqA does not contain an anonymous IBinder object. Then, the distributed Binder management module can directly serialize reqA.

[0238] After the distributed Binder management module serializes reqA, it forwards the call request (reqA byte stream) to the communication module of the second electronic device (refer to Fig.12 Step 1.4). The communication module of the second electronic device sends the reqA byte stream to the communication module of the first electronic device by assembling the message, and the message includes the BinderId S1 of the "DisApp" service (refer to Fig.12 as in step 1.5).

[0239] The communication module of the first electronic device receives and parses the message, determines that the message carries a Binder call request, and then sends the message to the distributed Binder management module of the first electronic device. The distributed Binder management module of the first electronic device parses the message to obtain the reqA byte stream (i.e., the serialized reqA), deserializes the reqA byte stream, and obtains reqA. The distributed Binder management module of the first electronic device finds the corresponding local IBinder object (IBinder C1) according to the received BinderId S1 (refer to Fig.12Step 1.5.1), and then call the transact method based on IBinder C1 to make the actual service call (that is, to obtain the FileProvider object of the note) (refer to Fig.12 as in step 1.5.2).

[0240] Specifically, the distributed Binder management module of the first electronic device sends a call message to the PC Binder SDK module of the first electronic device, and the call message includes the IBinder C1 object. Based on the received call message, the PC Binder SDK module of the first electronic device sends a request to the PC Binder management module of the first electronic device to request to obtain the unique identifier (first identifier) ​​corresponding to the IBinder C1 object (refer to Fig.12 After obtaining the first identifier corresponding to the IBinder C1 object, the PC Binder management module of the first electronic device searches for the associated module identifier (moduleId2) according to the first identifier (refer to Fig.12 Step 1.5.4), and then send the module identification 2 to the IPC communication module of the first electronic device. The IPC communication module of the first electronic device forwards the call message to the corresponding distributed application plug-in according to the module identification 2 (refer to Fig.12 as in step 1.5.5).

[0241] In the above process, since the distributed Binder management module sends the call message, the steps in the PC Binder module also include finding the reference object of the IBinder C1 object in the distributed application plug-in according to the IBinder C1 object in the call message sent by the distributed Binder management module. Then, according to the association relationship of the unique identifier of the reference object in the distributed application plug-in, the corresponding module identifier, that is, the module identifier 2 of the distributed application plug-in, is determined. Based on the module identifier 2, the IPC communication module can forward the call message to the distributed application plug-in.

[0242] The distributed application plug-in of the first electronic device obtains the File Provider object of the created note application (refer to Fig.12Step 1.5.6), and then send the File Provider object to the PC Binder SDK module of the first electronic device. The PC Binder SDK module of the first electronic device sends a request to the PC Binder management module of the first electronic device to request the unique identifier (first identifier) ​​of the File Provider object and associate it with the module identifier (moduleId2) of the distributed application plug-in, that is, to create a mapping relationship between the File Provider and moduleId2, and store the mapping relationship (refer to Fig.12 After the File Provider is successfully associated with moduleId2, a notification is sent to the PC BinderSDK module and the distributed application plug-in.

[0243] The distributed application plug-in of the first electronic device writes the File Provider object of the note application into the Parcel package, namely the Reply Parcel (set as repB) (refer to Fig.12 Step 1.5.8), and then repB is returned to the camera application of the second electronic device. Specifically, the distributed application plug-in of the first electronic device calls on transact (refer to Fig.12 Step 1.6). The distributed Binder management module of the first electronic device processes repB. Specifically, it checks that repB contains IFile Pc (equivalent to the IBinder object), and then allocates BinderId2 to the IFile Pc object (that is, establishes a mapping relationship between the IFilePc object and BinderId2). Then, the distributed Binder management module serializes repB (refer to Fig.12 Step 1.6.1). Before serialization, replace the IFile Pc object in repB with BinderId2, set the generated new Reply Parcel to repB1, and fill the other spaces belonging to the IFile Pc object with placeholders (refer to Fig.12 as in step 1.6.2).

[0244] Then, the first electronic device sends the serialized repB1 (i.e., the repB1 byte stream) to the second electronic device. Specifically, the distributed Binder management module of the first electronic device constructs a message that carries the repB1 byte stream. The distributed Binder management module of the first electronic device sends the constructed message to the communication module of the first electronic device, and then the communication module of the first electronic device sends the message to the communication module of the second electronic device.

[0245] After receiving the message, the communication module of the second electronic device parses the message to obtain a message corresponding to repB1. Then, the communication module of the second electronic device sends the parsed message to the distributed Binder management module of the second electronic device for processing.

[0246] That is, the distributed Binder management module of the second electronic device processes the repB1 byte stream (refer to Fig.12 Specifically, the repB1 byte stream is first deserialized to obtain the repB1 object. Then, since the second electronic device can determine that repB1 contains an IBinder object, that is, by parsing repB1, it can be determined that the corresponding BinderId2 is written into repB1 (refer to Fig.12 Step 1.7.1). Therefore, the second electronic device can obtain the BinderId2 of the first electronic device, and then create the IBinder object of the second electronic device (set to IFilePs), where BinderId2 establishes a mapping relationship with the IFilePs object of the second electronic device. Then, the distributed Binder management module of the second electronic device writes the created IFilePs object into the reply package (set to repB2) and returns it to the camera application (refer to Fig.12 as in step 1.8).

[0247] At this time, the second electronic device obtains the File Provider object of the note application. Then, the second electronic device can obtain the file handle of the photo cache file of the note through the File Provider object.

[0248] See also Fig.13 , Fig.13 The timing diagram of obtaining the file handle of the photo cache file of the note provided in the embodiment of the present application. Fig.13 As shown in the figure, when the camera application uses the IFilePs object to call the corresponding interface of the note application, it enters the distributed Binder management module of the service collaboration module. The input parameters in the interface call (by calling the transact method) can be encapsulated in the Parcel package (that is, the request parcel) (refer to Fig.13 Steps 1.1-1.2).

[0249] The distributed Binder management module of the service collaboration module processes the request parcel (set to reqD) reqD (refer to Fig.13Step 1.3). Specifically, first determine whether reqD contains an anonymous IBinder object. By parsing reqD, it can be determined that reqD does not contain an anonymous IBinder object. It can be understood that since reqD is only used to obtain the file handle of the note, no further call is required, and it can be determined that reqD does not contain an anonymous IBinder object. Then, the distributed Binder management module can directly serialize reqD.

[0250] After the distributed Binder management module serializes reqD, it forwards the call request (reqD byte stream) to the communication module of the second electronic device (refer to Fig.13 Step 1.4). The communication module of the second electronic device sends the reqD byte stream to the communication module of the first electronic device by assembling a message, wherein the message includes BinderId2.

[0251] The communication module of the first electronic device receives the message and parses it, determines that the message carries a Binder call request, and then sends the message to the distributed Binder management module of the first electronic device (refer to Fig.13 Step 1.5). The distributed Binder management module of the first electronic device parses the message to obtain the serialized reqD (reqD byte stream), deserializes the reqD byte stream to obtain reqD. The distributed Binder management module of the first electronic device finds the corresponding local IBinder object (IFilePc) according to the received BinderId2 (refer to Fig.13 as in step 1.5.1).

[0252] Then, the distributed Binder management module of the first electronic device sends a call message to the PC Binder SDK module of the first electronic device, and the call message includes an IFilePc object. Based on the received call message, the PC Binder SDK module of the first electronic device requests to obtain the unique identifier (first identifier) ​​corresponding to the IFilePc object. The PC Binder management module of the first electronic device obtains the first identifier corresponding to the IFilePc object according to the request, and finds the associated module identifier (moduleId2) according to the first identifier, and then sends the module identifier 2 to the IPC communication module of the first electronic device. The IPC communication module of the first electronic device forwards the call message to the corresponding distributed application plug-in according to the received module identifier 2.

[0253] The distributed application plug-in of the first electronic device calls the transact method based on the IFilePc object to perform the actual service call (ie, obtain the file handle of the note) (refer to Fig.13 Step 1.5.2). The note application of the first electronic device pre-registers the file descriptor object Fdc to the distributed application plug-in. The distributed application plug-in writes the File Descriptor object Fdc into the Parcel package, namely the Reply Parcel (set to repE) (refer to Fig.13 Step 1.5.3), and then repE is returned to the camera application of the second electronic device. Specifically, the note application calls onTransact (refer to Fig.13 Step 1.6). The distributed Binder management module of the first electronic device processes repE. Specifically, check that repE contains Fdc (equivalent to IBinder object) (refer to Fig.13 Step 1.6.1), and then send an instruction to create a distributed file to the distributed file module of the first electronic device (refer to Fig.13 The name of the created distributed file is "DisPicture".

[0254] The distributed file module of the first electronic device sends a request to the PC Binder SDK module of the first electronic device to create an IBinder object of the distributed file service provided by the distributed file module. Since the distributed file module calls the PC Binder SDK module of the first electronic device for the first time to create the IBinder object of the distributed file service, the module identifier corresponding to the distributed file module is not stored in the PCBinder SDK module at this time. Then, the PCBinder SDK module of the first electronic device sends a request to obtain the module identifier of the distributed file module to the IPC communication module of the first electronic device. After receiving the request, the IPC communication module of the first electronic device allocates an available module identifier to the distributed file module of the first electronic device, and returns the corresponding module identifier through the PC Binder SDK module. Then, the PC Binder SDK module creates the IBinder object of the distributed file service, and applies for the unique identifier of the IBinder object through the PC Binder management module of the first electronic device and associates the corresponding module identifier. After the association is successful, the notification is returned to the distributed file module of the first electronic device. At this time, the distributed file module can create a distributed file, and the name of the created distributed file is set to "DisPicture".

[0255] It is understandable that after the first electronic device receives the user's operation on the first application, it can be considered that the first electronic device has the intention of cross-device call, so the process of the distributed file module obtaining the module identifier can also be performed when the first electronic device responds to the user's operation on the first application. That is, the above-mentioned first module can include a distributed file module.

[0256] In the embodiment of the present application, the distributed Binder management module of the first electronic device needs to send a command to the distributed file module to create a distributed file, so that before the distributed file module creates the distributed file, the distributed Binder management module actually needs to bind the distributed file service provided by the distributed file module. Fig.14 , Fig.14 A schematic diagram of creating a distributed file provided in an embodiment of the present application. Fig.14 As shown, the distributed Binder management module sends a bind service instruction to the distributed application framework (refer to Fig.14 Step 1), after receiving the instruction, the Service component of the distributed application framework sends an instruction to the distributed file module to start the distributed file service according to the parameters contained in the instruction (the service name of the service to be bound) (refer to Fig.14 Step 1.1). After the distributed file module receives the instruction from the distributed application framework, it will generate an IBinder object (set to BBinder1) of the distributed file service in the process of pulling up the distributed file service (refer to Fig.14 Step 1.2), and return the reference object of the IBinder object to the distributed application framework (set to BpBinder1) (refer to Fig.14 Step 1.3). The Service component of the distributed application framework stores the BpBinder1, and then returns the result of the binding service to the distributed Binder management module, that is, returns the reference object of the IBinder object (set to BpBinder2) to the distributed Binder management module (refer to Fig.14 as in step 1.4).

[0257] Among them, after each module of the first electronic device creates or obtains a new IBinder object, it is necessary to apply for a unique identifier (first identifier) ​​for the IBinder object from the PC Binder module of the first electronic device, and associate the first identifier with the module identifier according to the call requirement. For example, the PC Binder module stores the first identifier corresponding to BBinder1 (set to Id1), the first identifier corresponding to BpBinder1 (set to Id2), and the first identifier corresponding to BpBinder2 (set to Id3). Among them, BBinder1 runs in a distributed file module, and the first identifier Id1 corresponding to BBinder1 is associated with the module identifier muduleId5 corresponding to the distributed file module.

[0258] After the distributed Binder management module of the first electronic device binds the distributed file service provided by the distributed file module, that is, obtains the reference object (BpBinder2) of the distributed file service, the distributed Binder management module can obtain the interface for creating a file (CreateFile) provided by the distributed file service through BpBinder2 (refer to Fig.14 Step 2). According to the mapping relationship stored in the PC Binder module, the distributed Binder management module of the first electronic device finds the IBinder object BBinder1 corresponding to BpBinder2, the first identifier Id1 corresponding to BBinder1, and the module identifier muduleId5 corresponding to the distributed file module. The distributed Binder management module of the first electronic device forwards the request to create a distributed file to the distributed file module corresponding to muduleId5 through the IPC communication module. The distributed file module of the first electronic device calls the CreateFile interface for processing according to the request, that is, creates a distributed file.

[0259] It is understandable that files can be accessed through file handles, such as opening files, closing files, reading and writing files, etc. Therefore, after the camera obtains the file handle, the photo data can be written into the actual file. Since the actual file is on the device side where the note application is located, and the camera application performs cross-device reading and writing, a distributed file can be created (the distributed file module can provide cross-device file access) to ensure that the data is written across devices on the camera side to the file on the device side where the note is located.

[0260] After the distributed file is successfully created, the distributed file module of the first electronic device sends a successful creation instruction to the distributed Binder management module (refer to Fig.13The distributed Binder management module writes the name of the distributed file to the location of the original Fdc in repE and generates repE1 (refer to Fig.13 Then, the distributed Binder management module serializes repE1.

[0261] Then, the first electronic device sends the serialized repE1 (i.e., repE1 byte stream) to the second electronic device. Specifically, the distributed Binder management module of the first electronic device constructs a message, which carries repE1. The distributed Binder management module of the first electronic device sends the constructed message to the communication module of the first electronic device (refer to Fig.13 Step 1.6.5), and then the communication module of the first electronic device sends the message to the communication module of the second electronic device.

[0262] After receiving the message, the communication module of the second electronic device parses the message and obtains the message corresponding to repE1 (refer to Fig.13 Then, the communication module of the second electronic device sends the parsed message to the distributed Binder management module of the second electronic device for processing.

[0263] That is, the distributed Binder management module of the second electronic device processes the repE1 byte stream. Specifically, the distributed Binder management module of the second electronic device deserializes the repE1 byte stream to obtain the repE1 object (refer to Fig.13 Then, the distributed Binder management module can detect that repE1 contains the name of the distributed file, that is, repE1 contains the relevant information of the corresponding file handle. The second electronic device can read the name of the distributed file in repE1 ("DisPicture") and open the corresponding distributed file (refer to Fig.13 as in step 1.7.2).

[0264] Then, the distributed file module of the second electronic device returns the file handle VFd of the distributed file to the distributed Binder management module of the second electronic device (refer to Fig.13 The distributed Binder management module writes the file handle VFd into the reply package (set to repE2) and returns it to the camera application (refer to Fig.13 Steps 1.7.4-1.8).

[0265] At this time, the second electronic device obtains the file handle VFd of the note application. Then, the camera application can write the photo data back to the first electronic device, that is, the camera application writes the photo data to the distributed file of the second electronic device through the file handle, and then transfers it to the distributed file of the first electronic device, and finally returns it to the note application of the first electronic device.

[0266] That is to say, a channel can be created between the distributed file module of the first electronic device and the second electronic device. After the camera application calls the data writing interface of the distributed file of the second electronic device through the file handle, it writes the photo data, transfers it to the distributed file of the first electronic device through the channel created above, and then returns it to the note.

[0267] In summary, in the above-mentioned cross-device data processing method, the user can use the first electronic device to send a shooting instruction to the second electronic device. After receiving the shooting instruction, the second electronic device activates the camera to perform a shooting or scanning task, and after completion, directly transmits the shooting result or the scanned extracted text back to the first electronic device. This can save the user the steps of uploading the shooting result or the scanned extracted text to the first electronic device, then downloading and saving it to the first electronic device, and then uploading it to the corresponding location of the first electronic device. The operation is simpler and the user's work efficiency is improved.

[0268] See also Fig.15 , Fig.15 A schematic diagram of a PC Binder mechanism for cross-device calls provided for the implementation of this application. Fig.15 As shown, the client is the first electronic device, the server is the second electronic device, and the client calls the service of the server. First, the server registers the target service in the service collaboration module of the server (refer to Fig.15 Step 1), that is, obtain the IBinder object of the target service (set to IBinder1), and assign a Binder identifier to IBinder1 (set to BinderId1). The service collaboration module on the server side stores the service name of the target service and the corresponding Binder identifier. The service collaboration module on the client side obtains the name of the target service and the corresponding BinderId from the service collaboration module on the server side (refer to Fig.15 Step 2), and create a local IBinder object IBinder2 according to BinderId1. The client applies for a unique identifier for the IBinder2 in the PC Binder module and establishes a mapping relationship with the module identifier.

[0269] The client's distributed application framework obtains the target service from the service collaboration module (refer to Fig.15 Step 2), and then when calling the target service (refer to Fig.15In step 3), the mapping relationship between the unique identifier of the IBinder object of the target service obtained in the PC Binder module and the module identifier is forwarded to the corresponding module (service collaboration module) by the IPC communication component, and then the onTransact method is called.

[0270] The mapping relationship between the unique identifier of each IBinder object and the corresponding module identifier can be stored in the PC Binder module of the first electronic device. Among them, the IBinder object here includes an entity object and a reference object. After a module creates an entity of an IBinder object, the reference object of the IBinder object is obtained in the module in other processes. In other words, after creating a corresponding reference object in the PC Binder module and associating the unique identifier of the reference object with the module identifier, the reference object can be forwarded to the module corresponding to the module identifier through the IPC communication component.

[0271] It should be noted that when different modules (different processes) of the first electronic device communicate with each other, the module identification of the corresponding module needs to be obtained before it can be forwarded to the corresponding module through the IPC communication component, that is, communication between processes is realized.

[0272] In an embodiment of the present application, a PC Binder mechanism is constructed on a PC, and the first electronic device completes the IPC Message initialization by calling the Binder SDK interface (i.e., Binder lib), so that the IPC Message does not need to be initialized additionally. Among them, the purpose of the above-mentioned IPC initialization is to specify the module identifier of the first electronic device so that the other end can access it through the specified module identifier. Since the Binder SDK module is used for Binder calls on the PC side, this process can be completed in the BinderSDK module, so that the application on the PC side can only focus on the calling process like the Binder call on the Android side, without having to pay attention to the implementation of IPC cross-process communication.

[0273] In some embodiments, the above-mentioned cross-device data processing method can also be applied to cross-device calls to other capabilities, such as handwriting board, recording, scanning, etc., and different scenarios need to be adapted in the cross-end calling service. For example, if a computer service is called, after the first electronic device obtains the distributed context of the service of the second electronic device, the relevant application of the first electronic device can directly initiate a call to the service of the second electronic device. It can be understood that in the above-mentioned cross-device calling scenarios, the communication between different processes is all through the association of the module identifier with the unique identifier of the IBinder object, and is forwarded to the corresponding module by the IPC communication component based on the module identifier.

[0274] In some embodiments, the cross-device service call message can also be communicated within the same process, then different module identifiers can be set for different modules within the same process, and the process communication can be based on the module identifier. Alternatively, different modules can be distinguished by other means so that the call message can be forwarded to different modules to realize cross-device service calls.

[0275] The present application also provides a chip system, such as Fig.16 As shown, the chip system 90 includes at least one processor 901 and at least one interface circuit 902. The processor 901 and the interface circuit 902 can be interconnected via lines. For example, the interface circuit 902 can be used to receive signals from other devices (such as a memory of an electronic device). For another example, the interface circuit 902 can be used to send signals to other devices (such as processor 901). Exemplarily, the interface circuit 902 can read instructions stored in the memory and send the instructions to the processor 901. When the instructions are executed by the processor 901, the electronic device can execute the various steps in the above embodiments. Of course, the chip system may also include other discrete devices, which are not specifically limited in the embodiments of the present application.

[0276] An embodiment of the present application also provides a computer storage medium, which includes computer instructions. When the computer instructions are executed on the above-mentioned electronic device, the electronic device executes each function or step executed by the mobile phone in the above-mentioned method embodiment.

[0277] The embodiment of the present application also provides a computer program product. When the computer program product is run on a computer, the computer is enabled to execute each function or step executed by the mobile phone in the above method embodiment.

[0278] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0279] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the modules or units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0280] The units described as separate components may or may not be physically separated, and the components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple different places. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0281] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0282] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium, including several instructions to enable a device (which can be a single-chip microcomputer, chip, etc.) or a processor (processor) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read only memory (ROM), random access memory (RAM), disk or optical disk and other media that can store program code.

[0283] The above contents are only specific implementation methods of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present application shall be included in the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A cross-device data processing method, applied to a first electronic device, characterized in that: The method comprises: In response to a first operation of a user on a first application, the first electronic device acquires judgment information; wherein the judgment information is used to indicate whether a module identifier exists in a first module of the first electronic device; When the judgment information indicates that the first module does not have a module identifier, the first electronic device obtains a first module identifier corresponding to the first module through a Binder module of the first electronic device; The first electronic device creates a target IBinder object of the first service through the Binder module, and determines a first identifier of the target IBinder object; wherein the first identifier is associated with the first module identifier, and the target IBinder object is used to call the first service provided by the first module; The first electronic device calls a target service of a second electronic device based on a distributed application plug-in corresponding to a target module identifier in the first module identifier; wherein the target module identifier is associated with a second identifier, the second identifier is determined by a second IBinder object created by the first electronic device based on a first Binder identifier ID, the first Binder ID is determined according to the first IBinder object of the target service when the second electronic device registers the target service, and is obtained by the first electronic device from the second electronic device, and the first IBinder object and the second IBinder object are used to call the target service.

2. The cross-device data processing method according to claim 1, characterized in that: The Binder module includes a first Binder management module and a second Binder management module, and the first electronic device determines a first module identifier corresponding to the first module through the Binder module of the first electronic device, including: The first electronic device determines, through the first Binder management module, a first module identifier corresponding to the first module; The first electronic device creates a target IBinder object of the first service through the Binder module and determines a first identifier of the target IBinder object, including: The first electronic device creates a target IBinder object for the first service through the first Binder management module, and determines a first identifier of the target IBinder object through the second Binder management module; The first electronic device associates the first identifier with the first module identifier through the second Binder management module.

3. The cross-device data processing method according to claim 2, characterized in that: Before the first electronic device determines the first module identifier corresponding to the first module through the first Binder management module, the method further includes: The first module of the first electronic device sends a first call request to the first Binder management module, where the first call request is used to request the first Binder management module to create a target IBinder object for the first service; The first electronic device determines the first module identifier corresponding to the first module through the first Binder management module, including: In response to the first call request, the first Binder management module sends a first acquisition request to the inter-process communication module of the first electronic device, where the first acquisition request is used to request to acquire a module identifier of the first module; The inter-process communication module allocates a corresponding first module identifier to the first module in response to the first acquisition request, and returns the first module identifier to the first Binder management module; The first electronic device creates a target IBinder object for the first service through the first Binder management module, and determines a first identifier of the target IBinder object through the second Binder management module, including: The first Binder management module creates a target IBinder object for the first service, and sends a second acquisition request to the second Binder management module, where the second acquisition request is used to request to acquire a first identifier of the target IBinder object; wherein the acquisition request includes the first module identifier; The second Binder management module determines the corresponding first identifier based on the target IBinder object in response to the second acquisition request.

4. The cross-device data processing method according to any one of claims 1 to 3, characterized in that: Before the first electronic device determines the first module identifier corresponding to the first module of the first electronic device through the Binder module of the first electronic device, the method further includes: The Binder module of the first electronic device sends an initialization instruction to the inter-process communication module of the first electronic device; The inter-process communication module of the first electronic device determines a module identifier corresponding to a Binder module of the first electronic device.

5. The cross-device data processing method according to any one of claims 1 to 4, characterized in that: Before the first electronic device calls the target service of the second electronic device based on the distributed application plug-in corresponding to the target module identifier in the first module identifier, the method further includes: The first electronic device obtains the first Binder ID from the second electronic device, and creates the second IBinder object based on the first Binder ID; The first electronic device determines the second identifier based on the second IBinder object, and associates the target module identifier based on the second identifier; The first electronic device returns the second IBinder object to the distributed application plug-in based on the target module identifier; The first electronic device sends the second IBinder object to the first application from the distributed application plug-in based on the second module identifier of the first application.

6. The cross-device data processing method according to claim 5, characterized in that: Before the first electronic device sends the second IBinder object to the first application from the distributed application plug-in based on the second module identifier of the first application, the method further includes: The first application sends a second call request to the first Binder management module, where the second call request is used to request the first Binder management module to create a reference object of the second IBinder object; wherein the reference object is used to call the target service; In response to the second call request, the first Binder management module sends a third acquisition request to the inter-process communication module, where the third acquisition request is used to request to acquire a module identifier of the first application; The inter-process communication module allocates a corresponding second module identifier to the first application in response to the third acquisition request, and returns the second module identifier to the first Binder management module; The first Binder management module creates a reference object of the second IBinder object, and sends a fourth acquisition request to the second Binder management module, wherein the fourth acquisition request is used to request to obtain a third identifier of the reference object; wherein the acquisition request includes the second module identifier; The second Binder management module determines the corresponding third identifier based on the reference object in response to the fourth acquisition request, and associates the third identifier with the second module identifier; The first electronic device sending the second IBinder object from the distributed application plug-in to the first application based on the second module identifier of the first application includes: The distributed application plug-in sends the reference object to the first application based on the second module identifier.

7. The cross-device data processing method according to claim 6, characterized in that: The first electronic device calls a target service of the second electronic device based on the distributed application plug-in corresponding to the target module identifier in the first module identifier, including: The first application sends a service call request to the distributed application plug-in based on the target module identifier; wherein the service call request includes the reference object; The distributed application plug-in responds to the service call request and calls the target service based on the second IBinder object corresponding to the reference object.

8. The cross-device data processing method according to any one of claims 1 to 7, characterized in that: The first module includes a distributed application plug-in, a service collaboration module and a distributed file module of the first electronic device.

9. An electronic device, characterized in that: The electronic device comprises: a communication module, a display screen, a memory and one or more processors; the communication module, the display screen, the memory and the processor are coupled; the memory is used to store computer program code, and the computer program code comprises computer instructions, and when the computer instructions are executed by the electronic device, the electronic device executes the method as described in any one of claims 1-8.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores instructions, and when the instructions are executed in an electronic device, the electronic device executes the method according to any one of claims 1 to 8.

Images