A cross-device data processing method and an electronic device

Abstract

The application provides a cross-device data processing method and an electronic device, relates to the field of electronic devices, and is applied to a first electronic device. The method comprises the following steps: in response to a first operation of a user on a first application, when a module identifier does not exist in a first module, the first electronic device determines 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 I Binder object of a first service through the Binder module, and determines a first identifier of the target I Binder object; the target I Binder object is used to call a 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; the second identifier is determined by a second I Binder object created by the first electronic device based on a first Binder ID; and the first Binder ID is determined by the second electronic device according to a first I Binder object of the target service when the second electronic device registers the target service. The scheme can improve work efficiency.

Description

Technical Field

[0001] This application relates to the field of electronic equipment technology, and in particular to a cross-device data processing method and electronic equipment. Background Technology

[0002] Currently, because different types of electronic devices have different functions, users will choose the more convenient electronic device according to different scenarios. For example, because computer screens are larger than mobile phones, users usually use computers to organize notes for learning, while in offline classrooms, it is necessary to photograph the blackboard content and insert it into the computer's notes.

[0003] Since computers lack a rear camera, the current solution is to photograph the whiteboard content with a mobile phone, upload the photographed content to the computer, download and save it to the computer, and finally upload it to the computer's notes. However, this method involves switching between multiple devices and transferring data, making the process rather cumbersome. Summary of the Invention

[0004] This application provides a cross-device data processing method and electronic device, which can realize cross-device service invocation, reduce the complexity of operation, and improve the user's work efficiency.

[0005] To achieve the above objectives, the embodiments of this 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. The method includes: in response to a user's first operation on a first application, the first electronic device obtains judgment information; wherein the judgment information is used to indicate whether a first module of the first electronic device has a module identifier; if 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 the Binder module of the first electronic device; the first electronic device creates a target IBinder object for a first service through the Binder module and determines a first identifier of the target IBinder object; wherein the first identifier is associated with a 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 the distributed application plugin corresponding to the 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 the first Binder identifier ID, the first Binder ID is determined by the second electronic device based on the first IBinder object of the target service when registering 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. This can achieve IPC initialization without additional initialization. Each module of the first electronic device does not need to be aware of the underlying IPC communication component framework and can directly make Binder calls, which is consistent with cross-device calls on Android.

[0008] This system allows users to send a shooting command from a first electronic device to a second electronic device. Upon receiving the command, the second electronic device activates its camera to take a picture or perform a scan. After completion, the captured image or scanned text is directly sent back to the first electronic device. This eliminates the need for users to manually upload the captured image or scanned text to the second electronic device, download and save it there, and then upload it again. The operation is simpler and improves user efficiency.

[0009] In one possible implementation of the first aspect, after the first electronic device obtains the judgment information in response to the user's first operation on the first application, it further includes: if the judgment information indicates that the first module has a module identifier, the first electronic device creates a target IBinder object of 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, if the information indicates that the first module does not have a module identifier, a target IBinder object for 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 one possible implementation of the first aspect, the Binder module includes a first Binder management module and a second Binder management module. 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 one 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 for 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 a first identifier for the target IBinder object through a second Binder management module; the first electronic device associates the first identifier with a first module identifier through the second Binder management module.

[0013] In one 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, the method further includes: the first module of the first electronic device sending a first invocation request to the first Binder management module. The first invocation request requests the first Binder management module to create a target IBinder object for the first service. For the first module, it only needs to send the invocation request to the first Binder management module; the processes of obtaining the module identifier and creating the IBinder object are both implemented through the Binder module, so that the first module in the first electronic device does not need to concern itself with the implementation process of IPC communication.

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

[0015] In one possible implementation of the first aspect, the first electronic device creates a target IBinder object for the 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 the target IBinder object for the first service and sends a second acquisition request to the second Binder management module, the second acquisition request being used to request the acquisition of the first identifier of the target IBinder object; wherein, the acquisition request includes a first module identifier; the second Binder management module responds to the second acquisition request and determines the corresponding first identifier based on the target IBinder object.

[0016] In one 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, the method further includes: the Binder module of the first electronic device sending an initialization instruction to the inter-process communication module of the first electronic device; and the inter-process communication module of the first electronic device determining the module identifier corresponding to the Binder module of the first electronic device.

[0017] In one 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 plugin corresponding to the target module identifier in the first module identifier, the method further includes: the first electronic device obtaining a first Binder ID from the second electronic device and creating a second IBinder object based on the first Binder ID; the first electronic device determining a second identifier based on the second IBinder object and associating it with the target module identifier based on the second identifier; the first electronic device returning the second IBinder object to the distributed application plugin based on the target module identifier; and the first electronic device sending the second IBinder object to the first application by the distributed application plugin based on the second module identifier of the first application.

[0018] In one possible implementation of the first aspect, before the first electronic device sends the second IBinder object to the first application via a distributed application plugin based on the second module identifier of the first application, the method further includes: the first application sending a second invocation request to a first Binder management module, the second invocation request being 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 invoke a target service; the first Binder management module responding to the second invocation request sending a third acquisition request to an inter-process communication module, the third acquisition request being used to request acquisition of the module identifier of the first application; the inter-process communication module responding to the third acquisition request allocating a corresponding second module identifier to the first application and returning the second module identifier to the first Binder management module; the first Binder management module creating a reference object of the second IBinder object and sending a fourth acquisition request to the second Binder module, the fourth acquisition request being used to request acquisition of a third identifier of the reference object; wherein, the acquisition request includes the second module identifier; the second Binder management module responding to the fourth acquisition request determining a corresponding third identifier based on the reference object and associating the third identifier with the second module identifier.

[0019] In other words, when the first electronic device sends the second IBinder object to the first application via the distributed application plugin, it needs to forward the request based on the module identifier of the first application. In reality, it doesn't return the second IBinder object to the note-taking application, but rather returns a reference to the second IBinder object. At this point, it's equivalent to the note-taking application of the first electronic device creating the IBinder object for the first time, and the note-taking application hasn't yet been assigned a corresponding module identifier. Therefore, the note-taking application needs to obtain the module identifier in order to receive messages from other processes through the IPC communication module.

[0020] Understandably, since service calls need to be initiated through the distributed application plugin, the IBinder object of the distributed application management service needs to be sent to the distributed application plugin via a module identifier associated with the plugin. In reality, the distributed application plugin doesn't obtain the second IBinder object, but rather a reference to it. Therefore, the association of the first identifier of the second IBinder object with the target module identifier can be understood as the association of the first identifier of the reference to the second IBinder object with the target module identifier.

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

[0022] In one possible implementation of the first aspect, the first electronic device sends a second IBinder object to the first application via a distributed application plugin based on a second module identifier of the first application, including: the distributed application plugin sending a reference object to the first application based on the second module identifier.

[0023] In one possible implementation of the first aspect, the first electronic device invokes the target service of the second electronic device based on the distributed application plugin corresponding to the target module identifier in the first module identifier, including: the first application sending a service invocation request to the distributed application plugin based on the target module identifier; wherein the service invocation request includes a reference object; and the distributed application plugin responding to the service invocation request by invoking the target service based on the second IBinder object corresponding to the reference object.

[0024] In one possible implementation of the first aspect, the first module includes a distributed application plugin, a service collaboration module, and a distributed file module for the first electronic device.

[0025] In a second aspect, this 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 processors are coupled; the memory is used to store computer program code, the computer program code including computer instructions, which, when executed by the electronic device, cause the electronic device to perform the method described in the first aspect.

[0026] Thirdly, this application provides a computer-readable storage medium storing instructions that, when executed on a computer, enable the computer to perform the method described in any one of the first aspects above.

[0027] Fourthly, this application provides a computer program product containing instructions that, when run on a computer, enable the computer to perform the method described in any one of the first aspects above.

[0028] It is understood that the electronic device described in the second aspect, the computer-readable storage medium described in the third aspect, and the computer program product described in the fourth aspect are all used to perform the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here. Attached Figure Description

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

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

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

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

[0033] Figure 5 A schematic diagram illustrating the creation of an IBinder object by a service collaboration module, as provided in an embodiment of this application;

[0034] Figure 6 A schematic diagram illustrating the creation of an IBinder object by a distributed application plugin, as provided in an embodiment of this application;

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

[0036] Figure 8A sequence diagram illustrating the registration of a distributed application management service and the acquisition of a service is provided in this embodiment of the application.

[0037] Figure 9 A schematic diagram illustrating a note-taking application for obtaining module identifiers, provided as an embodiment of this application;

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

[0039] Figure 11 A schematic diagram illustrating how a first electronic device turns on the camera of a second electronic device, as provided in an embodiment of this application;

[0040] Figure 12 A sequence diagram for obtaining a File Provider object for notes, provided in an embodiment of this application;

[0041] Figure 13 A timing diagram for obtaining a file handle to a note, provided as an embodiment of this application;

[0042] Figure 14 This application provides a schematic diagram of creating a distributed file according to an embodiment of the present application;

[0043] Figure 15 A schematic diagram illustrating a cross-device PC Binder mechanism provided in an embodiment of this application;

[0044] Figure 16 This is a schematic diagram of a chip system provided in an embodiment of this application. Detailed Implementation

[0045] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first," "second," etc., may explicitly or implicitly include one or more of that feature.

[0046] Furthermore, the terms "comprising" and "having," and any variations thereof, used in the description of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or modules is not limited to the steps or modules listed, but may optionally include other steps or modules not listed, or may optionally include other steps or modules inherent to such process, method, product, or device.

[0047] Furthermore, in the embodiments of this application, the words "exemplary" or "for example" are used to indicate that they are examples, illustrations, or descriptions. Any embodiment or design that is described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design options. Specifically, the use of the words "exemplary" or "for example" is intended to present concepts in a concrete manner.

[0048] For ease of understanding, the terminology used in this application is described herein:

[0049] Binder: Binder is the medium for communication between the client and the server. The server returns a Binder object containing the server's business logic calls, which the client can use to obtain services or data provided by the server.

[0050] The Binder mechanism supports both intra-process and inter-process calls. Remote calls (i.e., cross-process calls) can be implemented using IBinder. IBinder is a basic interface used for remote calls. The main Application Programming Interface (API) of IBinder is `transact()`, and its corresponding method is `Binder.onTransact()`. The first method allows the local device to send a call to the remote IBinder object, and the second method allows the remote object on the local device to respond to the received call.

[0051] Currently, for easier learning, users typically use tablets or personal computers (PCs) to take and organize notes. Therefore, users often need to access the blackboard content from offline classes and insert it into their tablet or PC notes. Similarly, when organizing their thoughts for a paper on a tablet or PC, users frequently need to access and cite content from textbooks.

[0052] However, since personal computers lack a rear camera, users typically use their phones to photograph or scan the blackboard or textbook content in offline classrooms, then upload it to their personal computers, download and save it, and finally upload it to the corresponding location in their notes. This involves numerous steps, switching between multiple devices for data transfer, making the process rather cumbersome.

[0053] Alternatively, one could take a photo of the blackboard content using a tablet, but tablets are relatively bulky. Furthermore, due to device limitations, students in the back row (too far away) and those in the front row (too close to the blackboard, requiring a wide-angle lens to capture the full view of the content) may not be able to take photos that meet their needs.

[0054] Therefore, this application provides a cross-device data processing method, which allows a user to send a shooting command from a first electronic device (such as a personal computer) to a second electronic device (such as a mobile phone or tablet). After receiving the shooting command, the mobile phone or tablet activates its camera to perform a photo or scan task, and then directly sends the shooting result or the scanned text back to the personal computer.

[0055] like Figure 1 As shown, the main device can include tablets and personal computers, while the secondary device can include mobile phones. The main device's note-taking application responds to user actions by sending a shooting or scanning command to the secondary device. Upon receiving the command, the secondary device activates its camera to perform the photo or scan task. After the shooting or scanning is complete, the secondary device sends the photo (photo) or scan result (extracted text) back to the main device's note-taking application.

[0056] Compared to existing methods, remote calling between these devices allows for the implementation of different functions on multiple devices, reducing the need for manual switching between devices. For example, it eliminates the need for users to upload captured images or scanned text to their personal computers, download and save them, and then upload them again, simplifying the process and improving user efficiency. Furthermore, using a mobile phone to take photos allows for capturing images of the whiteboard content that meet the user's needs.

[0057] Generally, PCs run Windows, while mobile phones run Android. Cross-device communication between PCs and phones refers to cross-device communication between Windows and Android systems. Therefore, to make cross-device communication solutions between Windows and Android devices more universal, a unified architecture design is needed for Windows -> Android and Android -> Android calls, and the access methods must also be consistent. Windows -> Android refers to a Windows device calling an Android device, such as a PC calling a mobile phone; Android -> Android refers to an Android device calling another Android device, such as a tablet calling a mobile phone.

[0058] Therefore, on the PC side (Windows system), a PC Binder capability needs to be built to support Binder calls on the PC side. This requires porting the Android Binder framework and adapting it for the Windows platform. After building the PC Binder capability on the PC side, a component framework similar to that on the Android side will also be built to support cross-device Activity and Service component binding, Provider access, and other capabilities. While the component framework built on the PC side is similar to that on the Android side, due to system differences, the calls to underlying system capabilities may differ, requiring improvements to the interfaces provided by the system.

[0059] Currently, in existing solutions on the PC side, each module in the client needs to interact with the IPC communication component to perform IPC initialization before it can make Binder calls. This application provides a cross-device data processing method that allows IPC initialization to be performed through the corresponding Binder module when each module first creates an IBinder object for the service it provides. This avoids the additional step of initializing the IPC communication component, enabling each module in the client to directly make Binder calls without needing to be aware of the underlying IPC communication component framework, thus maintaining consistency with cross-device calls on Android.

[0060] For example, the electronic device in this application embodiment may be a tablet computer, mobile phone, desktop computer, laptop computer, handheld computer, notebook computer, ultra-mobile personal computer (UMPC), netbook, as well as cellular phone, personal digital assistant (PDA), augmented reality (AR) / virtual reality (VR) device, vehicle device, etc. This application embodiment does not impose any special restrictions on the specific form of the electronic device.

[0061] In this application embodiment, electronic devices can be divided into private devices and public devices. It is understood that a private device refers to a device that can only be used by the owner (i.e., the device's owner). For example, a private device can be a mobile phone, smartwatch, smart glasses, headphones, etc. A public device refers to a device that can be used by any user. That is, a public device may have multiple accounts logged in, and these different accounts may be associated with each other. For example, a public device can be a television, stereo, tablet computer, etc.

[0062] The execution entity of the cross-device service invocation method provided in this application can be a cross-device data processing device, and the execution device can be... Figure 2The illustrated electronic device. The execution device can also be the central processing unit (CPU) of the electronic device, or a control module within the electronic device for cross-device data processing. This application embodiment uses an electronic device performing a cross-device data processing method as an example to illustrate the cross-device data processing method provided by this application embodiment.

[0063] The embodiments of this application will now be described in detail with reference to the accompanying drawings. Taking a mobile phone as an example, the hardware structure of the electronic device (such as electronic device 300) will be described. Figure 2 The electronic device 300 shown is merely an example of an electronic device, and the electronic device 300 may have more or fewer components than those shown in the figure, may combine two or more components, or may have different component configurations. Figure 2 The various components shown can 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] Please see Figure 2 , Figure 2 A schematic diagram of the electronic device is shown, such as... 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, a headphone jack, a sensor module 380, buttons 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] The aforementioned sensor module 380 may include sensors such as pressure sensors, gyroscope sensors, barometric pressure sensors, magnetic sensors, accelerometers, distance sensors, proximity sensors, fingerprint sensors, temperature sensors, touch sensors, ambient light sensors, and bone conduction sensors.

[0066] It is 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 illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0067] Processor 310 may include one or more processing units, such as: application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, memory, video codec, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU), etc. The different processing units may be independent devices or integrated into one or more processors.

[0068] The controller can be the nerve center and command center of the electronic device 300. The controller can generate operation control signals according to the instruction opcode and timing signals to complete the control of instruction fetching and execution.

[0069] The processor 310 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 310 is a cache memory. This memory can store instructions or data that the processor 310 has just used or that are used repeatedly. If the processor 310 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, 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. Interfaces 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 understood that the interface connection relationships between the modules illustrated in this embodiment are merely illustrative and do not constitute a structural limitation on the electronic device 300. In other embodiments, the electronic device 300 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0072] The charging management module 340 is used to receive charging input from the charger. In this embodiment, the charger is a wired charger, and the charging management module 340 can receive the charging input from the wired charger via the USB interface 330 (i.e., the charging interface mentioned above). While charging the battery 342, the charging management module 340 can also supply power to the electronic device via the power management module 341.

[0073] The power management module 341 connects 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, providing power to the processor 310, internal memory 321, external memory, display screen 394, camera 393, and wireless communication module 360. The power management module 341 can also monitor parameters such as battery capacity, battery cycle count, and battery health status (leakage current, impedance). In some other embodiments, the power management module 341 may also be located within the processor 310. In other embodiments, the power management module 341 and the charging management module 340 may be housed in the same device.

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

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

[0076] The mobile communication module 350 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied to the electronic device 300. The mobile communication module 350 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 350 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem 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 via the antenna 1. In some embodiments, at least some functional modules of the mobile communication module 350 can be housed in the processor 310. In some embodiments, at least some functional modules of the mobile communication module 350 and at least some modules of the processor 310 can be housed in the same device.

[0078] The wireless communication module 360 ​​can provide solutions for wireless communication applications on the electronic device 300, 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), and infrared (IR) technologies. For example, in this embodiment, the electronic device 300 can access a Wi-Fi network through the wireless communication module 360.

[0079] The wireless communication module 360 ​​can be one or more devices integrating at least one communication processing module. The wireless communication module 360 ​​receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signal, and sends the processed signal to processor 310. The wireless communication module 360 ​​can also receive signals to be transmitted from processor 310, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0080] In some embodiments, antenna 1 of electronic device 300 is coupled to mobile communication module 350, and antenna 2 is coupled to wireless communication module 360, enabling electronic device 300 to communicate with networks and other devices via 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 technologies, etc. The GNSS may include the Global Positioning System (GPS), the Global Navigation Satellite System (GLONASS), the BeiDou Navigation Satellite System (BDS), the Quasi-Zenith Satellite System (QZSS), and / or satellite-based augmentation systems (SBAS).

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

[0082] Display screen 394 is used to display images, videos, etc. 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 (AMOLED), a flexible light-emitting diode (FLED), a Mini LED, a MicroLED, a Micro-OLED, a quantum dot light-emitting diode (QLED), etc.

[0083] Electronic device 300 can achieve shooting functions through ISP, camera 393, video codec, GPU, display screen 394, and application processor. The ISP is used to process data fed back by camera 393. Camera 393 is used to capture still images or videos. In some embodiments, electronic device 300 may include one or N cameras 393, where N is a positive integer greater than 1. The digital signal processor is used to process digital signals, including digital image signals and other digital signals. For example, when electronic device 300 selects a frequency point, the digital signal processor is used to perform Fourier transforms on the frequency point energy. The video codec is used to compress or decompress digital video. The NPU (Neural-Network Processing Unit) is a neural network (NN) computing processor that, by borrowing from the structure of biological neural networks, such as the transmission patterns between neurons in the human brain, can quickly process input information and continuously learn itself. The NPU enables intelligent cognitive applications of electronic device 100, such as image recognition, face recognition, speech recognition, and text understanding.

[0084] The external storage 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 storage interface 320 to perform data storage functions. For example, music, video, and other files can be saved on the external memory card.

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

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

[0087] Electronic device 300 can implement audio functions such as music playback and recording through audio module 370, speaker 370A, receiver 370B, microphone, headphone jack, and application processor.

[0088] Audio module 370 is used to convert digital audio information into analog audio signal output, and also to convert analog audio input into digital audio signal. Audio module 370 can also be used for encoding and decoding audio signals. In some embodiments, audio module 370 may be located in processor 310, or some functional modules of audio module 370 may be located in processor 310. Speaker 370A, also called a "loudspeaker," is used to convert audio electrical signals into sound signals. Receiver 370B, also called a "handset," is used to convert audio electrical signals into sound signals. Microphone, also called a "microphone" or "voice transducer," is used to convert sound signals into electrical signals.

[0089] The headphone jack is used to connect wired headphones. The headphone jack can be a USB 330 interface or a 3.5mm Open Mobile Terminal Platform (OMTP) standard interface, or a CTIA (Cellular Telecommunications Industry Association of the USA) standard interface.

[0090] Buttons 390 include a power button, volume buttons, etc. Buttons 390 can be mechanical buttons or touch-sensitive buttons. Motor 391 can generate vibration alerts. Motor 391 can be used for incoming call vibration alerts or for touch vibration feedback. Indicator 392 can be an indicator light, used to indicate charging status, battery level changes, messages, missed calls, notifications, etc. SIM card interface 395 is used to connect a SIM card. The SIM card can be inserted into or removed from the SIM card interface 395 to achieve contact and separation with the electronic device 300. The electronic device 300 can support one or N SIM card interfaces, where N is a positive integer greater than 1. SIM card interface 395 can support Nano SIM cards, Micro SIM cards, SIM cards, etc.

[0091] although Figure 2 As not shown, electronic device 300 may also be a flash, a miniature 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 in this application will be described. The system architecture of the electronic device can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This application embodiment uses a layered architecture system as an example to illustrate the software structure of the electronic device.

[0093] A layered architecture divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the PC system can be divided into, from top to bottom, the application layer, distributed application plugins, service collaboration layer, PC Binder module, communication module and device profile layer, and inter-process communication (IPC) module.

[0094] The application layer can include a series of application packages. These application packages can include: notes, camera, email, and calendar. They can also include applications such as gallery, calendar, calling, maps, navigation, WLAN, Bluetooth, music, video, and SMS.

[0095] like Figure 3 As shown, the distributed application plugin is used to handle service calls between distributed applications on the PC, meeting the calling requirements of the distributed application framework.

[0096] like Figure 3As shown, the service coordination layer provides management capabilities for remote services, is responsible for forwarding service calls between devices, and converts local resource references (anonymous Binder objects, file descriptors, etc.) into inter-device resource references. This service coordination layer may 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 manages multiple remote devices when multiple remote devices exist. The service acquisition module retrieves the target service from device 2 after device 2 has completed its registration, in a scenario where device 1 calls a target service from device 2.

[0098] The distributed service management module lists services with known names; these are all system services, meaning they are all named services, and their corresponding Binder objects are all named Binders. When a server registers its services, it registers the services with the distributed service management module.

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

[0100] In the distributed Binder management module, all Binders except for those with real names are anonymous Binders. Therefore, the scope is broader than that of the Binders in the distributed service management module. Anonymous Binders refer to Binders that are not registered in the distributed service management module and are created by the application itself.

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

[0102] The distributed file management module is responsible for reading and writing files across devices. It manages distributed files, primarily creating and opening files, which involves message transmission between devices, including serialization and deserialization.

[0103] The distributed file management module primarily refers to scenarios like taking photos. For example, when a PC needs to access a phone's camera, the actual photo cache file is created by the PC. Then, after taking a photo, the phone needs to obtain the file handle of the photo cache file from the PC. After obtaining the file handle, it needs to perform write operations on this photo cache file. This involves cross-device read and write operations. The distributed file management module can provide cross-device file access. The file handle is a relatively complex object, similar to a 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. Devices may be brought online or taken offline. Taking a device offline means it has been connected and then taken offline, meaning it will no longer be connected. In this case, all resources related to that device need to be cleaned up or other operations performed. One or more devices may be connected.

[0106] like Figure 3 As shown, the PC Binder module includes the IPC Client module, the PC Binder Software Development Kit (SDK) module (PC Binder SDK module), the PC Binder Manager module, and the Binder Server module.

[0107] When the client and server perform cross-process access, the IPC Message component needs to be initialized. The IPC Message component is equivalent to the server. Each application that needs to use the IPC Message component for cross-process communication needs to generate an IPC Client module internally.

[0108] The Binder SDK module is used to provide interfaces for various business functions, including creating and deleting 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 layer include 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. It provides cross-device transmission interfaces and supports automatic networking within the trust ring, one-to-many connections, and wake-up of dormant devices. In cross-device scenarios, devices transmit information through the communication module.

[0112] The Device Profile module provides device information, an interface for registering services supported by the device, and an interface for querying other device services.

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

[0114] The IPC module includes IPC Messages, which are components of inter-process communication and can be referred to as the IPC communication module. The PC side relies on these IPC Messages when building cross-process communication capabilities.

[0115] In some embodiments, the Android system can be divided into five layers, from top to bottom: application layer, system application framework layer, coordination service and scheduling layer, communication module and device profile layer, and kernel layer.

[0116] The application layer can include a series of application packages. For example... Figure 4 As shown, the application package can include: notes, camera, email, and calendar. The application package can also include applications such as gallery, calendar, calling, maps, navigation, WLAN, Bluetooth, music, video, and SMS.

[0117] like Figure 4As shown, the system application framework layer may include an Activity Manager Service (AMS), a Distributed Activity Manager Service (DAMS), a Package Manager Service (PMS), a Distributed Package Manager Service (DPMS), a Service Manager Module (SM), a Distributed Service Manager Module (DSM), and a system Binder framework. AMS, PMS, and SM are existing system services in the Android system, and their functions are not described in detail here. DAMS, DPMS, and DSM are new system functions added to the distributed system in this embodiment of the application. Together, they form a distributed application framework used to handle service calls between distributed applications in this application. The distributed application framework can provide a distributed application management service for registration with the distributed service management module, enabling service calls and management between distributed applications.

[0118] like Figure 4 As shown, the Collaboration Service and Scheduling Layer provides management capabilities for remote services, including remote service registration and acquisition. It is responsible for forwarding service calls between devices, converting local resource references (anonymous Binder objects, file descriptors, etc.) into inter-device resource references. This Collaboration Service and Scheduling Layer may 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 lifecycle module. The service management module is used to manage multiple remote devices when they exist.

[0120] The service registration module is used by the service registration module of device 2 to register the target service before device 1 calls the target service of device 2. The service acquisition module is used by the service acquisition module of device 1 to acquire the target service of device 2 after the target service of device 2 has been fully registered when device 1 calls the target service of device 2.

[0121] The service lifecycle module is used to handle situations where device 1 can call services provided by devices A and B. Device A may have two services, and device B may also have two services. When a service on either device A or B becomes abnormal or is terminated (i.e., the service exits), the service lifecycle module on device 1 needs to perform certain actions on the exited service. The lifecycle can be understood as a process of creation and closure.

[0122] The distributed service management module lists services with known names; these are all system services, meaning they are all named services, and their corresponding Binder objects are all named Binders. When a server registers its services, it registers the services with 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 lifecycle module.

[0124] In the distributed Binder management module, all Binders except for those with real names are anonymous Binders. Therefore, the scope is broader than that of the Binders in the distributed service management module. Anonymous Binders refer to Binders that are not registered in the distributed service management module and are created by the application itself.

[0125] The Binder management mapping module is used to manage Binder objects, involving the mapping between local and remote Binders. The Binder access authentication module is used to manage 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. It manages distributed files, primarily creating and opening files, which involves message transmission between devices, including serialization and deserialization. In scenarios like taking photos, for example, when a PC uses a phone's camera, the actual photo cache file is created by the PC. After taking a photo, the phone obtains the file handle of the photo cache file from the PC. Then, it writes to this cache file. This involves cross-device read and write operations. The distributed file management module provides cross-device file access. The file handle is a relatively complex object, similar to a Binder object.

[0127] The transmission management module refers to the channels (sessions) created between devices to transmit messages. The device management module refers to the connected devices, which may go online or offline. Going offline means that a device has been connected and then taken offline, meaning it is no longer connected. In this case, all resources associated with that device need to be cleaned up or other operations performed. This may involve one or more connected devices.

[0128] like Figure 4 As shown, the communication module and device profile layer include a communication module, a device profile module, and a distributed file module. The communication module is responsible for transmission, including device discovery and connection services and data transmission services. It provides cross-device transmission interfaces and supports automatic networking within the trust ring, one-to-many connections, and wake-up from sleep mode. In cross-device scenarios, devices transmit information through the communication module. The device profile module provides device information, a service registration interface supported by the device, and an interface for querying services from other devices. The distributed file module, also known as distributed file management, is responsible for reading and writing files across devices.

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

[0130] In this embodiment, a first electronic device is taken as the main device and a second electronic device as the auxiliary device. The first electronic device can call the services of the second electronic device. The first electronic device can be a personal computer, computer, etc., and the second electronic device can be a tablet, mobile phone, etc. In the scenario where the first electronic device calls the services 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 wants to use the service provided by the server.

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

[0132] In this embodiment, when the first electronic device starts up, its PC Binder module (also called the Binder module), service collaboration module, and distributed application plugin can be started sequentially, requiring the creation of corresponding IBinder objects for the services they provide. On the PC side, when a module creates an IBinder object for the first time, it needs to obtain the corresponding module identifier.

[0133] In this embodiment, after the electronic device starts up, the IPC communication module is started first. Following the IPC communication module, the PCBinder module starts. At this time, the PC Binder module sends a request to the IPC communication module to obtain the module identifier corresponding to the PCBinder module. In this embodiment, the PC Binder module is a common module; various modules 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 identifier, that is, after initialization is complete, the service collaboration module and the distributed application plugin start sequentially.

[0134] Please see Figure 5 , Figure 5 This diagram illustrates the creation of an IBinder object by a service collaboration module according to an embodiment of this application. The service collaboration module creates the corresponding IBinder object by calling the PC Binder SDK module (the first Binder management module). At this time, the PC Binder SDK module determines whether the service collaboration module possesses a module identifier. For example, the PC Binder SDK module identifies the process corresponding to the process ID contained in the received call request, that is, it identifies which module's process sent the call request, and then searches the stored module identifier list for a corresponding module identifier. Then, the PC Binder SDK module generates judgment information, which indicates whether the service collaboration module of the first electronic device possesses a module identifier.

[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, then the corresponding module identifier will be allocated through the IPC communication module.

[0136] Specifically, such as 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. Upon receiving the request, the PC Binder SDK module sends a request to the IPC communication module to obtain the module identifier of the service collaboration module. Upon 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 PC Binder SDK module creates an IBinder object corresponding to the service provided by the service collaboration module and sends the IBinder object and module identifier to the PC Binder management (second Binder management module) module. The PC Binder management module requests a unique identifier for the IBinder object corresponding to the service collaboration module and associates this unique identifier with the module identifier.

[0137] Please see Figure 6 , Figure 6 This is a schematic diagram illustrating the creation of an IBinder object by a distributed application plugin, as provided in an embodiment of this application. Figure 6 As shown, the distributed application plugin 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 plugin. Upon 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 plugin. Upon receiving the request, the IPC communication module allocates an available module identifier to the distributed application plugin. 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 plugin, the PC Binder SDK module creates the IBinder object corresponding to the distributed application plugin and sends the IBinder object and module identifier to the PC Binder management module. The PC Binder management module requests a unique identifier for the IBinder object corresponding to the distributed application plugin and associates this unique identifier with the module identifier.

[0138] In other words, neither the service collaboration module nor the distributed application plugin needs to obtain the module identifier in advance. Instead, it obtains the corresponding module identifier through the IPC communication module when an IBinder object needs to be created, and then creates the corresponding IBinder object and associates it with the corresponding module identifier so that it can be forwarded to the corresponding module through the IPC communication module based on the module identifier when used.

[0139] In this embodiment, besides starting the first module of the first electronic device when it starts up, it can also be started when the first electronic device receives a user's operation, indicating the user's intention to make cross-device calls. The first module is the module needed for cross-device calls and includes the aforementioned service collaboration module and distributed application plugin.

[0140] Taking the example of a first electronic device's note-taking application calling a second electronic device's camera application to take a picture, the first electronic device, in response to the user's first operation on the note-taking application (first application), launches a first module of the first electronic device. This requires creating corresponding IBinder objects for the services provided by each first module. The aforementioned first operation can be a touch operation; for example, it includes clicking a button on the first application's display interface, or clicking on a target device and target service in a list that can be accessed across devices.

[0141] For details, please refer to Figure 7 In response to a user's first operation on the first application, the first electronic device obtains judgment information; wherein, the judgment information is used to indicate whether a module identifier exists in the first module of the first electronic device. If 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 its Binder module (PC Binder module). After obtaining the first 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, 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 plugin corresponding to the target module identifier in the first module identifier. Therefore, the cross-device data processing method provided in this application embodiment can perform IPC initialization through the corresponding Binder module of each module when each module first creates an IBinder object for the provided service. This avoids the additional step of initializing the IPC communication component, allowing each module of the client to directly perform Binder calls without needing to be aware of the underlying IPC communication component framework. The first module does not directly interact with the IPC communication module, but interacts with the IPC communication module through the corresponding Binder module to complete the IPC initialization. For the first module, it does not need to pay attention to the IPC communication process; it only needs to send a call message to the Binder module. The rest of the process is implemented in the Binder module through the interaction between the Binder module and the IPC communication module.

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

[0144] Taking a scenario where the note-taking application of a first electronic device calls the camera application's photo-taking service of a second electronic device as an example, the second electronic device first registers with the distributed application management service (target service) within its own device. The first electronic device then obtains the registered distributed application management service from the second electronic device. After the first electronic device successfully obtains the second electronic device's distributed application management service, its note-taking application launches the second electronic device's camera application. The camera application takes a picture of the specified content, and the second electronic device then transmits the captured image data to the first electronic device's note-taking application.

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

[0146] First, the service registration process for the second electronic device will be introduced. The service registered by the second electronic device at this stage is the distributed application management service.

[0147] In this context, the application (e.g., the camera application) is an interface provided by the distributed application framework, which is located within 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 access the services provided by the camera application.

[0148] The distributed application management service is located within the system application framework. When the second electronic device powers on, the system application framework, including the distributed application management service, is started. After the second electronic device powers on, the communication module starts. Following the communication module, the service collaboration module starts. Therefore, after the service collaboration module starts, the second electronic device can register the distributed application management service with the service collaboration module.

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

[0150] The distributed application management service of the second electronic device is registered in the Distributed Service Manager module (see reference). Figure 8 Step 1). Among them, the distributed application management service is located within the system application framework of the second electronic device and is started after the second electronic device is powered on.

[0151] The distributed service management module stores the service name (e.g., "DisApp") and IBinder object (e.g., "IBinder S1") of the distributed application management service (see reference). Figure 8 Step 1.1). Then, the service name and IBinder object are sent to the distributed Binder management module. The distributed Binder management module caches the IBinder object (IBinder S1 mentioned above) and assigns a BinderId (e.g., "Binder S1") to it. That is, a mapping relationship is established between IBinder S1 and Binder S1 (see step 1). Figure 8 Step 1.2). Then, the distributed Binder management module returns the registration result to the system application framework (see step 1.2). Figure 8 Step 1.3).

[0152] The service name and IBinder are parameters; one IBinder object can invoke a target service. After the first electronic device obtains the IBinder object of the target service of the second electronic device, it can use the IBinder object to invoke the corresponding interface of the target service, that is, to invoke the capabilities provided by the target service. In this embodiment, after the first electronic device obtains the IBinder object of the distributed application management service of the second electronic device, it can invoke the distributed application management service of the second electronic device.

[0153] Each service has a corresponding service name (ServiceName), such as Distributed Application Management Service, AMS Service, Camera Service, Audio Service, etc. The service name is registered with the service management module. In a distributed service scenario, the service name can also be registered with the distributed service management module.

[0154] In this embodiment, a unique identifier (BinderId) can be assigned to each IBinder object. Each IBinder object has a BinderId, and a mapping relationship can be established between the BinderId and the IBinder object. That is, a service registered on the server side has a BinderId, and when the client obtains the corresponding service, the BinderId can identify the relationship between the two. The mapping relationship can be understood as a key-value pair.

[0155] The BinderId can be assigned based on the device. For example, when multiple second electronic devices are connected, the second electronic devices first set a device identifier (DeviceId), and then assign a BinderId to the service on each second electronic device. The device identifier can be pre-set.

[0156] Specifically, BinderIds can be assigned sequentially in a certain order. For example, if a second electronic device A can provide service a (IBinder a) and service b (IBinder b), and a 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; it can also be letters, text, etc. When using numbers as BinderIds, they do not necessarily start from 1; they can also start from a specific number and increment sequentially.

[0157] In this embodiment, the second electronic device stores the service name and IBinder object of the distributed application management service, and assigns a BinderId to the IBinder object. Therefore, in subsequent steps, the distributed application management service can be obtained through the corresponding service name. Specifically, the acquisition process involves determining the IBinder object through the service name, and then determining the corresponding BinderId. The IBinder object and BinderId are in a one-to-one correspondence.

[0158] It's understandable that for services with verified names, the server stores the service name, the IBinder object, and the BinderId. This relationship is stored in the server-side distributed service management module. System services have corresponding service names, and these names are registered in the distributed service management module; therefore, system services are all services with verified names.

[0159] The storage method can be a list, 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] Alternatively, the data can be stored in two lists: one list containing the service name and the IBinder object, and another list containing the IBinder object and the BinderId. These three elements are linked one-to-one.

[0163] In this embodiment, 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 registration success notification 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 obtaining services will be described. Specifically, after the second electronic device successfully registers its distributed application management service, the first electronic device can obtain the distributed application management service registered by the second electronic device.

[0165] Understandably, before obtaining the distributed application management service, the first electronic device had already opened the note-taking application and responded to the user's touch operation on the note-taking application interface by displaying the device list and capability list. In other words, when the first electronic device receives the user's operation, it can assume the user intends to make cross-device calls, and therefore needs to obtain the distributed application management service provided by the second electronic device.

[0166] 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 a device has a service collaboration module. If a device does not have a service collaboration module, it does not have cross-device call capabilities and sends an empty message to the application of the first electronic device. In this case, the application interface of the first electronic device will not display the device name, or it will display the device name but distinguish it from other devices with cross-device call capabilities through a specific identifier.

[0167] In this embodiment of the application, a call entry point is provided in the note-taking application of the first electronic device. For example... Figure 9 As shown, the computer's note-taking application display interface 501 includes an insert button 502. Upon user touch of the insert button 502, the computer displays a list of second electronic devices that can provide services, along with a list of capabilities corresponding to those devices, on the display interface 502. The displayed devices can be a mobile phone 1 or a tablet 1. The capability list includes the services that the second electronic device can provide, such as... Figure 9 Mobile phone 1 has functions for taking photos and scanning, while tablet 1 has functions for taking photos and scanning.

[0168] In some embodiments of this application, the display interface of the note-taking application can show all devices with cross-device calling capabilities within a set range. For example, if the set range of devices with cross-device calling capabilities includes mobile phone 1 and tablet 1. Figure 9 As shown, the devices displayed are mobile phone 1 and tablet 1, and the functions that mobile phone 1 and tablet 1 can provide, such as taking pictures and scanning.

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

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

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

[0172] In this embodiment of the application, in response to an operation to open 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... Figure 9 (The "Insert" button in the interface) will then display a list of devices and their corresponding capabilities on the application interface of the first electronic device.

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

[0174] In other words, the device list and capability list are displayed before the first electronic device obtains the service. Then, in response to the user's touch operation on a certain item in the list, such as the first electronic device responding to the user's touch operation on the camera service option of phone 1 in the list of a certain application, it can be determined that the corresponding second electronic device is phone 1, and the target service is the distributed application management service. At this time, the first electronic device can begin to obtain the distributed application management service of phone 1.

[0175] Please refer to Figure 8 The note-taking application on the first electronic device can access the distributed context of the second electronic device, that is, access the "DisApp" service of the second electronic device (see...). Figure 8 Step 2). Specifically, the process of the first electronic device obtaining the service includes: the note-taking application of the first electronic device sending a request to the distributed application plugin of the first electronic device to obtain the "DisApp" service. This request 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-taking application and the distributed application plugin are different processes, and when communicating, the module identifier of the distributed application plugin also needs to be obtained and forwarded through the IPC communication module.

[0176] Then, the distributed application plugin sends a service request to the distributed service management module of the first electronic device. Specifically, the distributed application plugin sends a service request to the IPC communication module of the first electronic device, carrying the device identifier (DeviceId) and service name (ServiceName) in the request. The service name carried here is "DisApp" (see [reference]). Figure 8 Step 2.1).

[0177] Upon receiving the request, the IPC communication module sends the service acquisition request 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 its module identifier. Then, the distributed service management module of the first electronic device sends a request to the message center-communication module of the first electronic device to acquire the "DisApp" service (see reference). 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. 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 identifiers of the service collaboration module.

[0178] Understandably, for service requests, the IPC communication module will forward the request to the distributed service management module based on the request content, rather than the distributed Binder management module. Only after the distributed service management module obtains the BinderId corresponding to the service will it call the distributed Binder management module to create a local IBinder object.

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

[0180] In some embodiments of this application, the first electronic device can establish a connection with the second electronic device based on the device identifier in the request. After the connection is established, the corresponding service is searched from the second electronic device based on the service name in the request.

[0181] The specific steps for the first electronic device to search for a service from the second electronic device include: creating a session between the first and second electronic devices. After the session is successfully created, the first electronic device searches for the corresponding service from the second electronic device based on the service name.

[0182] The specific steps for creating a channel include: after the channel is successfully created between the communication modules of the first and second electronic devices, the communication module of the second electronic device sends a channel creation success command to its distributed Binder management module, and the communication module of the first electronic device sends a channel creation success command to its distributed Binder management module. The distributed Binder management module is used to manage Binder objects.

[0183] The specific steps for the first electronic device to find the corresponding service from the second electronic device based on the service name include: the first electronic device sends the service name to be obtained to the target device via a message. After receiving the message, the second electronic device parses the service name according to the message content. Then, it searches for the target service corresponding to the service name in the distributed service management module. The distributed service management module stores the mapping relationship between service names and IBinder objects.

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

[0185] The communication module is a message receiving module with message reception functionality. After receiving a message, the communication module of the second electronic device can parse it. If the message contains a service name, it can be considered a query command 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 has been found. The second electronic device then returns the IBinder object corresponding to the target service to the communication module of the second electronic device.

[0186] Understandably, the distributed Binder management module of the second electronic device establishes a mapping relationship between IBinder objects and BinderIds. 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, which then saves the mapping relationship. (See reference...) Figure 4 The arrow indicates this. The communication module of the second electronic device queries the distributed service management module based on the mapping relationship.

[0187] In this process, the second electronic device locates the corresponding IBinder object based on the service name in the distributed service management module, and then 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 IBinder objects and BinderIds. Then, it sends the determined BinderId to the communication module of the second electronic device.

[0188] In other words, when the two devices actually interact, the communication module of the second electronic device sends the BinderId to the communication module of the first electronic device.

[0189] It's important to note that the IBinder object generated by the second electronic device for the target service is not actually sent to the client. This is because the IBinder object has system boundaries and only has concrete meaning on the second electronic device. The IBinder object can be understood as a pointer or address; sending it to the first electronic device has no practical significance. 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 it into a 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] Please see Figure 8 After receiving the message, the communication module of the second electronic device parses it and obtains the instruction to obtain the "DisApp" service (see reference). Figure 8 Step 2.2.3). The communication module of the second electronic device sends this 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. As mentioned in step 1.1, the distributed service management module of the second electronic device stores service names and corresponding IBinder objects. Therefore, the distributed Binder management module of the second electronic device can search for the service name ("DisApp") in the distributed service management module to see if the service is stored. 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) based on the established mapping relationship between IBinder objects and BinderIds (see reference). Figure 8 Step 2.2.4). Then, the BinderId (BinderId S1) is sent to the communication module of the second electronic device (see step 2.2.4). Figure 8 Step 2.2.5).

[0194] After receiving the BinderId (BinderId S1) from 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, it 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 (see reference). Figure 8 Step 2.2.6).

[0196] In this embodiment, the first electronic device creates a local IBinder object based on the received BinderId. Specifically, the distributed service management module of the first electronic device creates a corresponding local IBinder object (denoted as IBinderC1) based on the received BinderId S1, and establishes a mapping relationship between it and BinderId S1 (see reference). 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. The creation request includes the BinderId (BinderId S1) of the "DisApp" service. The distributed Binder management module of the first electronic device creates a corresponding local IBinder object (IBinder C1) based on BinderId S1. That is, the distributed Binder management module creates a mapping relationship between BinderId S1 and IBinder C1 and stores the mapping relationship (see step 2.2.7). Figure 8 Step 2.2.7.1).

[0197] Then, after the first electronic device creates a local IBinder object, it requests a unique identifier (set as the first identifier) ​​for this local IBinder object. This identifier is then associated with module identifier 3. Specifically, the distributed Binder management module of the first electronic device sends a creation success command to the PC Binder SDK module of the first electronic device. After receiving the creation success command, 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 unique identifier (first identifier) ​​of IBinder C1 and associate it with the module identifier (moduleId3) of the service collaboration module. This involves creating a mapping relationship between IBinder C1 and moduleId3 and storing this mapping relationship (see [reference]). Figure 8Step 2.2.7.2). Here, IBinder C1 is created in the distributed Binder management module of the service collaboration module. Therefore, the unique identifier of IBinder C1 should be associated with the module identifier (moduleId3) of the service collaboration module.

[0198] It's important to note that the first identifier requested for a newly created IBinder object has a different function and meaning than the obtained Binder identifier (BinderId). If the first electronic device is making cross-device calls on the Android system, it's not necessary to request a new first identifier for the locally created IBinder object.

[0199] In this case, cross-process communication on the PC side relies on the IPC message module, which can forward call messages to the corresponding module based on the obtained module identifier.

[0200] Understandably, during the process of sending IBinder C1 from the service collaboration module to the distributed application plugin, the distributed application plugin does not actually obtain the IBinder C1 object, but rather a reference object to IBinder C1. Since this reference object of IBinder C1 needs to be sent to the distributed application plugin, the first identifier corresponding to this reference object needs to be associated with the module identifier of the distributed application plugin. Therefore, the IPC communication module can send the reference object of IBinder C1 to the distributed application plugin based on the module identifier of the distributed application plugin.

[0201] In this embodiment of the application, the distributed application plugin of the first electronic device is used to handle service calls between distributed applications. Therefore, service call messages across devices need to be sent to the distributed application plugin.

[0202] After the PC Binder management module of the first electronic device creates the mapping relationship between IBinder C1 and module identifier 3, it 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 (see...). 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) (see...) Figure 8 Step 2.2.8).

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

[0205] In this context, for different modules of the first electronic device, if they belong to different processes, the IBinder object actually obtained by each process is not the entity itself, but a reference object to the entity object. Therefore, during the creation of the reference object, the unique identifier of the reference object needs to be associated with the module identifier of the module to which it is to be sent, 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 plugin of the first electronic device actually receives the first reference object of IBinder C1, and the note-taking application of the first electronic device actually receives the reference object of the first reference object, which is the second reference object of IBinder C1. Then, the distributed service management module of the first electronic device returns IBinder C1 to the distributed application plugin of the first electronic device. Specifically, the first reference object of IBinder C1 is created in the PC Binder module, and the first identifier of the first reference object is associated with the module identifier of the distributed application plugin. The IPC communication module then forwards the first reference object to the distributed application plugin.

[0207] During the process of the distributed application plugin returning the created local IBinder object to the note-taking application, it's not actually returning the local IBinder object (IBinder C1) to the note-taking application, but rather returning a second reference object of IBinder C1. At this point, it's equivalent to the note-taking application of the first electronic device creating the IBinder object for the first time, and the note-taking application hasn't yet allocated a corresponding module identifier. Therefore, the note-taking application needs to obtain the module identifier in order to receive messages from other processes through the IPC communication module.

[0208] Specifically, such as Figure 10As shown, the note-taking application of the first electronic device sends a request to the PC Binder SDK module of the first electronic device to request the module identifier of the note-taking 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-taking 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 for IBinder C1 and requests a unique identifier for this second reference object. Specifically, the PC Binder SDK module sends a request to the PC Binder management module. After receiving the request, the PC Binder management module requests a unique identifier for the second reference object and associates it with the module identifier of the note-taking application.

[0210] Therefore, the IPC communication module sends the referenced object to the note application based on the note application's module identifier.

[0211] It's understandable that the newly created IBinder object in the first electronic device is created based on the BinderId carried in the received message, which is the BinderId passed from the second electronic device to the first. The BinderId remains constant. Then, the first electronic device creates a corresponding IBinder object based on the BinderId. In other words, a mapping relationship is established between the BinderId and the new IBinder object within the first electronic device.

[0212] In other words, in this embodiment of the application, in order for 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's important to note that since Windows systems cannot directly recognize IBinder objects, a unique first identifier needs to be allocated for locally created IBinder objects and associated with a module identifier to enable transmission between modules on the first device. For example, if the IPC message module needs to forward call messages related to a newly created locally created IBinder object to a distributed application plugin, the first identifier is associated with the distributed application plugin's module identifier. If the IPC message module needs to forward call messages related to a newly created locally created IBinder object to other modules, the first identifier is associated with the module identifiers of those other modules.

[0214] In some embodiments of this application, the first electronic device may be calling the camera's photo-taking service of the second electronic device for the first time, or it may be calling it multiple times. Therefore, after the first electronic device first obtains the camera's photo-taking service, it can cache the call information locally. Thus, the first electronic device can first search for the second electronic device and the distributed application management service in its local cache. If found, it directly returns the information to the note-taking application; if not found, it can search for it in the second electronic device. For example, if application 1 on computer 1 has called the scanning service of mobile phone 1 once, then the next time application 1 on computer 1 needs to call the scanning service, it can directly search for the name of mobile phone 1, the name of the distributed application management service, and the corresponding IBinder object, first identifier, module identifier, and other information from the local cache of computer 1.

[0215] In some embodiments of this 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 can 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. Specifically, when the client calls the service interface of the server, it sends a service call request to the server; after receiving the request, the server calls the corresponding service interface and then returns a reply containing the call result to the client.

[0217] The request may or may not contain an anonymous IBinder object. An anonymous IBinder object is one that hasn't been registered with the distributed service management module; it can call an anonymous service. When a client calls a service registered with the server, if the request is a simple command without any further instructions (equivalent to the request not containing an anonymous IBinder object), and the returned result is directly usable without any further instructions (equivalent to the response not containing an anonymous IBinder object), or if the returned result is not directly usable and requires further access or invocation (equivalent to the response containing an anonymous IBinder object), then the request may be valid.

[0218] For example, if the service provided by the second electronic device is a computational service, taking a simple adder (a+b) as an example, the input parameters for the application of the first electronic device are two numbers, a and b. Calling the service's interface directly yields the result c; where result c is a single number, containing nothing else. This is equivalent to the request not containing an IBinder object, and the reply also not containing an IBinder object.

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

[0220] For example, if the client sends a request to the server that includes an anonymous IBinder object, the server can obtain this IBinder object and then call the interface provided by this IBinder object in the client.

[0221] In this embodiment of the application, in the scenario where the first electronic device calls the camera application of the 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 by which the note-taking application of the first electronic device opens the camera application of the second electronic device is as follows:

[0223] like Figure 11 As shown, the note-taking application makes IPC calls through a locally created IBinder C1. Specifically, the note-taking application sends a "start activity for result(intent)" message to the distributed application plugin of the first electronic device (see...). Figure 11 Step 1), the intent contains the URI and device information. The distributed application plugin sends this call message to the PC Binder SDK module of the first electronic device (see...). Figure 11 Step 1.1). The PC Binder SDK module sends this call message to the PC Binder management module of the first electronic device to obtain the unique identifier (set as Id1) corresponding to IBinder C1 (refer to...). Figure 11 Step 1.2). The PC Binder management module of the first electronic device finds the corresponding module identifier (moduleId3) based on the unique identifier (refer to...). Figure 11 Step 1.3).

[0224] It's understandable that the distributed Binder management module creates an IBinder C1 object, while the distributed application plugin obtains a reference to that IBinder C1 object. Therefore, the distributed application plugin actually initiates the call based on the reference to the IBinder C1 object. For the distributed application plugin to send the call message to the distributed Binder management module, the PC Binder management module first locates IBinder C1 from the reference object and then determines the unique identifier of IBinder C1. Then, the PC Binder management module finds the corresponding module identifier, which is the module identifier (moduleId3) of the distributed Binder management module, based on the association relationship of this unique identifier.

[0225] The PC Binder management module of the first electronic device can forward the call message to the module corresponding to moduleId3 (see reference) through the IPC communication module of the first electronic device. Figure 11 Step 1.4). Specifically, the distributed application plugin initiates a call to the distributed Binder management module, which means sending a call message to the IPC communication module. The call message contains 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 module identifier 3. The above process is equivalent to the distributed application plugin of the first electronic device calling the onTransact method (refer to...). Figure 11 Step 1.5) sends 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, which then calls the start activity method to launch the camera via the locally created IBinder S1. The system application framework then 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 coordination module of the second electronic device sends the result message to the service coordination 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 coordination 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 plugin module of the first electronic device. At this point, the camera is successfully activated.

[0230] In this embodiment, the messages transmitted between the modules can all be encapsulated in parcel packages, and the messages are transmitted by transmitting parcel packages between the modules. For example, the call message and the result message mentioned above can be encapsulated in parcel packages and transmitted between the modules of the first electronic device and the second electronic device.

[0231] After the first electronic device acquires the "DisApp" service registered by the second electronic device, and the camera application of the second electronic device is opened, the user takes a picture of the information that needs to be transferred back to the notes using the camera application. The camera application responds to the user's action and sends the acquired photo data back to the notes. For example, if whiteboard content from an offline classroom is inserted into the notes application, after the camera application is opened, the user takes a picture of the whiteboard content with the camera. The camera responds to the user's click of the shutter button, obtaining a photo of the whiteboard content. Then, the camera sends the whiteboard photo back to the notes.

[0232] The camera responds to the user's click of the shutter button, acquires a photo, and then confirms whether the photo meets the user's requirements. The camera responds to the user's click of the confirmation button, that is, after confirming the photo meets the user's requirements, it acquires the confirmed photo. The camera then sends the confirmed photo back to the notebook. In other words, after the camera responds to the user's click of the confirmation button, it sends the captured data back to the notebook of the first electronic device.

[0233] For the camera, after taking a photo, when it needs to send the photo data back to the note-taking application, it first needs to obtain the file handle of the note-taking's photo cache file, and then write the photo data back to the client application's photo cache file. Since the file handle is a local resource of the first electronic device, it cannot be obtained directly. Therefore, the file handle can be hosted in a service (such as a Provider service). The camera obtains the note-taking's File Provider object, and then uses that object to obtain the file handle. It can be understood that the camera application sends a simple request to the note-taking application, while the result returned by the note-taking application to the camera application is an object that requires further calls. This situation is equivalent to the request not containing an anonymous IBinder object, while the response contains an anonymous IBinder object.

[0234] Therefore, the specific steps for the second electronic device to send service data (photo data) back to the first electronic device include: the camera application obtaining the IContent Provider object (i.e., File Provider object) of the note-taking application; the camera application obtaining the file handle of the photo cache file of the note-taking application; and the camera application writing the photo data back to the first electronic device. Here, the photo data refers to the result of the second electronic device executing the distributed application management service.

[0235] The note-taking 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), which the note-taking application registers with the distributed application plugin. The note-taking application can create the photo cache file in response to a user's touch operation on camera options, or it can create the photo cache file at any time before obtaining its file handle.

[0236] Please see Figure 12 , Figure 12A timing diagram of a File Provider object for obtaining notes, provided in an embodiment of this application. For example... Figure 12 As shown, when the camera application uses IBinder S1 to call the corresponding interface of the note-taking application, it enters the distributed Binder management module of the service collaboration module (see...). Figure 12 Step 1.1), the input parameters in the interface call (by calling the transact method) can be encapsulated in the Parcel package (i.e., the request parcel) (see...). Figure 12 Step 1.2).

[0237] The distributed Binder management module of the service collaboration module processes the request parcel (denoted as reqA) (see reference). Figure 12 Step 1.3). Specifically, first, it is determined whether reqA contains an anonymous IBinder object. By parsing reqA, it can be determined that reqA does not contain an anonymous IBinder object. This is understandable, since reqA is only used to retrieve the File Provider object for notes and does not require further calls, 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 (see reference). Figure 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 a message, which contains the BinderId S1 of the "DisApp" service (see step 1.4). Figure 12 Step 1.5).

[0239] The communication module of the first electronic device receives and parses the message, determining that it carries a Binder call request. It then sends the message to the distributed Binder management module of the first electronic device. The distributed Binder management module parses the message, obtaining a reqA byte stream (i.e., the serialized reqA), and deserializes the reqA byte stream to obtain reqA. The distributed Binder management module then finds the corresponding local IBinder object (IBinder C1) based on the received BinderId S1 (see reference). Figure 12Step 1.5.1), then based on IBinder C1, the transact method is called to perform the actual service call (that is, to obtain the FileProvider object of the notes) (see...). Figure 12 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, the call message containing the IBinder C1 object. Based on the received call message, the PC Binder SDK module of the first electronic device sends a retrieval request to the PC Binder management module of the first electronic device to request the unique identifier (first identifier) ​​corresponding to the IBinder C1 object (see reference). Figure 12 Step 1.5.3). After obtaining the first identifier corresponding to the IBinder C1 object, the PC Binder management module of the first electronic device finds the associated module identifier (moduleId2) based on the first identifier (see step 1.5.3). Figure 12 Step 1.5.4) then sends 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 plugin based on module identifier 2 (see...). Figure 12 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 plugin based on the IBinder C1 object in the call message sent by the distributed Binder management module. Then, based on the association relationship of the unique identifier of the reference object in the distributed application plugin, the corresponding module identifier is determined, which is the module identifier 2 of the distributed application plugin. The IPC communication module can then forward the call message to the distributed application plugin based on module identifier 2.

[0242] The distributed application plugin of the first electronic device obtains the File Provider object of the created note-taking application (see reference). Figure 12Step 1.5.6) then sends 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 a unique identifier (first identifier) ​​for the File Provider object and associate it with the module identifier (moduleId2) of the distributed application plugin. That is, it creates a mapping relationship between the File Provider and moduleId2 and stores this mapping relationship (see...). Figure 12 (Step 1.5.7). After the File Provider is successfully associated with moduleId2, a notification is sent to the PC BinderSDK module and the distributed application plugin.

[0243] The distributed application plugin for the first electronic device writes the File Provider object of the note-taking application into the Parcel package, namely the Reply Parcel (denoted as repB) (see...). Figure 12 Step 1.5.8) then returns repB to the camera application of the second electronic device. Specifically, the distributed application plugin of the first electronic device calls on transact (see...). Figure 12 Step 1.6). The distributed Binder management module of the first electronic device processes repB. Specifically, it checks if repB contains an IFile Pc (equivalent to an IBinder object), and then assigns a BinderId2 to the IFile Pc object (that is, establishes a mapping relationship between the IFilePc object and BinderId2). Then, the distributed Binder management module performs serialization processing on repB (refer to...). Figure 12 Step 1.6.1). Before serialization, replace the IFile Pc object in repB with BinderId2, set the newly generated Reply Parcel to repB1, and fill the remaining space belonging to the IFile Pc object with placeholders (see...). Figure 12 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 carrying 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 it to obtain the 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] In other words, the distributed Binder management module of the second electronic device processes the repB1 byte stream (see...). Figure 12 Step 1.7). Specifically, firstly, the repB1 byte stream is 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 has been written into repB1 (refer to...). Figure 12 Step 1.7.1). Therefore, the second electronic device can obtain the BinderId2 of the first electronic device, and then create an IBinder object (denoted as IFilePs) for the second electronic device, where a mapping relationship is established between BinderId2 and 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 a reply package (denoted as repB2) and returns it to the camera application (see step 1.7.1). Figure 12 Step 1.8).

[0247] At this point, the second electronic device obtains the File Provider object from the note-taking application. Then, the second electronic device can use the File Provider object to obtain the file handle of the note's photo cache files.

[0248] Please see Figure 13 , Figure 13 A timing diagram for obtaining the file handle of the photo cache file of the notes provided in an embodiment of this application. (See diagram below.) Figure 13 As shown, when the camera application calls the corresponding interface of the note-taking application using the IFilePs object, 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 (i.e., the request parcel) (see...). Figure 13 Steps 1.1-1.2).

[0249] The distributed Binder management module of the service collaboration module processes the request parcel (denoted as reqD) and reqD (see reference). Figure 13Step 1.3). Specifically, first, it is determined whether reqD contains an anonymous IBinder object. By parsing reqD, it can be determined that reqD does not contain an anonymous IBinder object. This is understandable, as reqD is only used to obtain the file handle of the notes and does not require further calls; therefore, 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 (see reference). Figure 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, which contains BinderId2.

[0251] 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 (see reference). Figure 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), and 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) based on the received BinderId2 (refer to...). Figure 13 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, the call message containing 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) based on the first identifier, then sends moduleId2 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 plugin based on the received moduleId2.

[0253] The distributed application plugin for the first electronic device calls the transact method based on the IFilePc object to perform the actual service call (i.e., obtain the file handle of the note) (see reference). Figure 13 Step 1.5.2). Specifically, the notebook application of the first electronic device pre-registers the file descriptor object Fdc into the distributed application plugin. The distributed application plugin writes the file descriptor object Fdc into a Parcel package, namely the Reply Parcel (denoted as repE) (see...). Figure 13 Step 1.5.3) then returns repE to the camera application of the second electronic device. Specifically, the note-taking application calls onTransact (see...). Figure 13 Step 1.6). The distributed Binder management module of the first electronic device processes the repE. Specifically, it checks if the repE contains an Fdc (equivalent to an IBinder object) (refer to...). Figure 13 Step 1.6.1), and then send the instruction to create a distributed file to the distributed file module of the first electronic device (see step 1.6.1). Figure 13 (Step 1.6.2). Let the name of the created distributed file be "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 for the distributed file service provided by the distributed file module. Since this is the first time the distributed file module has called the PC Binder SDK module to create the IBinder object for the distributed file service, the PC Binder SDK module does not yet store the module identifier corresponding to the distributed file module. Therefore, the PC Binder SDK module of the first electronic device sends a request to the IPC communication module of the first electronic device to obtain the module identifier of the distributed file module. Upon receiving the request, the IPC communication module of the first electronic device allocates an available module identifier to the distributed file module and returns the corresponding module identifier through the PC Binder SDK module. Then, the PC Binder SDK module creates the IBinder object for the distributed file service and requests a unique identifier for this IBinder object through the PC Binder management module of the first electronic device, associating it with the corresponding module identifier. After successful association, a notification is returned to the distributed file module of the first electronic device. At this point, the distributed file module can create a distributed file; let's say the name of the created distributed file is "DisPicture".

[0255] It is understandable that after receiving a user's operation on the first application, the first electronic device can be considered to have the intention of cross-device invocation. Therefore, 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 aforementioned first module may include the distributed file module.

[0256] In this embodiment, the distributed Binder management module of the first electronic device sends an instruction to the distributed file module to create a distributed file. Before the distributed file module creates the distributed file, the distributed Binder management module actually needs to bind to the distributed file service provided by the distributed file module. Please refer to... Figure 14 , Figure 14 This is a schematic diagram illustrating the creation of a distributed file, as provided in an embodiment of this application. Figure 14 As shown, the distributed Binder management module sends a service binding instruction to the distributed application framework (see reference). Figure 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, based on the parameter (the service name of the service to be bound) contained in the instruction (see...). Figure 14 Step 1.1). After receiving the instructions from the distributed application framework, the distributed file module will generate an IBinder object (let's call it BBinder1) for the distributed file service during the process of starting the distributed file service (refer to...). Figure 14 Step 1.2), and return a reference object of the IBinder object (let's call it BpBinder1) to the distributed application framework (see step 1.2). Figure 14 Step 1.3). The Service component of the distributed application framework stores BpBinder1, and then returns the result of the binding service to the distributed Binder management module, that is, returns a reference object of the IBinder object (let's call it BpBinder2) to the distributed Binder management module (see step 1.3). Figure 14 Step 1.4).

[0257] In this process, after each module of the first electronic device creates or acquires a new IBinder object, it needs to request a unique identifier (first identifier) ​​for that IBinder object from the PC Binder module of the first electronic device, and associate the first identifier with the module identifier according to the calling requirements. For example, the PC Binder module stores the first identifier (denoted as Id1) corresponding to BBinder1, the first identifier (denoted as Id2) corresponding to BpBinder1, and the first identifier (denoted as Id3) corresponding to BpBinder2. Since BBinder1 runs in the distributed file module, 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 to the distributed file service provided by the distributed file module, that is, after obtaining the reference object (BpBinder2) of the distributed file service, the distributed Binder management module can obtain the file creation (CreateFile) interface provided by the distributed file service through BpBinder2 (see...). Figure 14 Step 2). Based on 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, as well as 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 to process the request, that is, to create the distributed file.

[0259] Understandably, files can be accessed via file handles, such as opening, closing, reading, and writing files. Therefore, after the camera obtains the file handle, it can write the captured data to the actual file. Since the actual file is on the device side where the note-taking application resides, and the camera application performs cross-device read and write operations, a distributed file can be created (a distributed file module can provide cross-device file access) to ensure that data is written from the camera side to the file on the device side where the note-taking application resides.

[0260] After the distributed file is successfully created, the distributed file module of the first electronic device sends a creation success command to the distributed Binder management module (see reference). Figure 13Step 1.6.3). The distributed Binder management module writes the name of the distributed file into the original location of Fdc in repE and places it as a placeholder, generating repE1 (refer to...). Figure 13 (Step 1.6.4). Then, the distributed Binder management module serializes repE1.

[0261] Then, the first electronic device sends the serialized repE1 (i.e., the repE1 byte stream) to the second electronic device. Specifically, the distributed Binder management module of the first electronic device constructs a message, which carries the repE1. The distributed Binder management module of the first electronic device sends the constructed message to the communication module of the first electronic device (see reference). Figure 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 (see reference). Figure 13 (Step 1.7). 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] In other words, 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 (see...). Figure 13 Step 1.7.1). Then, the distributed Binder management module can detect that repE1 contains the name of the distributed file, meaning that repE1 contains information related to the corresponding file handle. The second electronic device can read the name of the distributed file (“DisPicture”) in repE1 and open the corresponding distributed file (see step 1.7.1). Figure 13 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 (see reference). Figure 13 Step 1.7.3). The distributed Binder management module writes the file handle VFd into the reply packet (set as repE2) and returns it to the camera application (see step 1.7.3). Figure 13 (Steps 1.7.4-1.8).

[0265] At this point, the second electronic device obtains the file handle (VFd) of the note-taking application. Then, the camera application can write the captured data back to the first electronic device. That is, the camera application writes the captured data to the distributed file of the second electronic device through the file handle, then passes it to the distributed file of the first electronic device, and finally returns it to the note-taking application of the first electronic device.

[0266] In other words, a channel can be created between the distributed file modules of the first and second electronic devices. After the camera application calls the write data interface of the distributed file of the second electronic device through the file handle, it writes the photo data, which is then passed to the distributed file of the first electronic device through the channel created above, and finally returned to the notebook.

[0267] In summary, the cross-device data processing method described above allows users to send a shooting command from a first electronic device to a second electronic device. Upon receiving the command, the second electronic device activates its camera to perform a photo or scan. After completion, the captured image or scanned text is directly transmitted back to the first electronic device. This eliminates the need for users to manually upload the image or scanned text to the first electronic device, download and save it there, and then upload it again. The process is simpler and improves user efficiency.

[0268] Please see Figure 15 , Figure 15 A schematic diagram illustrating a cross-device PC Binder mechanism provided for the implementation of this application. (See diagram below.) Figure 15 As shown, the client is the first electronic device, and the server is the second electronic device. The client calls the server's service. First, the server registers the target service in its service collaboration module (refer to...). Figure 15 Step 1), namely obtaining the IBinder object of the target service (let's call it IBinder1), and assigning a Binder identifier (let's call it BinderId1) to IBinder1. The service collaboration module on the server side stores the service name of the target service and its corresponding Binder identifier. The service collaboration module on the client side obtains the name of the target service and its corresponding BinderId (see...) from the service collaboration module on the server side. Figure 15 Step 2) involves creating a local IBinder object IBinder2 based on BinderId1. The client then requests a unique identifier for IBinder2 within the PC Binder module, establishing a mapping between it and the module identifier.

[0269] The client's distributed application framework obtains the target service from the service coordination module (see reference). Figure 15 Step 2), and then when calling the target service (refer to...) Figure 15Step 3) uses the mapping relationship between the unique identifier of the target service's IBinder object and the module identifier obtained from the PC Binder module to forward the data to the corresponding module (service collaboration module) by the IPC communication component, and then calls the onTransact method.

[0270] The PC Binder module of the first electronic device can store the mapping relationship between the unique identifier of each IBinder object and the corresponding module identifier. Here, IBinder objects include entity objects and reference objects. After an entity of an IBinder object is created in a certain module, other modules in other processes will obtain a reference object of that IBinder object. In other words, after creating the 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 via 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 identifier of the corresponding module must be obtained before it can be forwarded to the corresponding module through the IPC communication component, thus realizing inter-process communication.

[0272] In this embodiment, a PC Binder mechanism is built on the PC. The first electronic device completes IPC Message initialization by calling the Binder SDK interface (i.e., Binder lib), which eliminates the need for additional IPC Message initialization. The purpose of this IPC initialization is to specify the module identifier of the first electronic device, allowing the other end to access it through the specified module identifier. Since all Binder calls on the PC side use the Binder SDK module, this process can be completed within the Binder SDK module. This allows the PC application to focus only on the call process, similar to Binder calls on the Android side, without needing to concern itself with the implementation of IPC inter-process communication.

[0273] In some embodiments, the cross-device data processing method described above can also be applied to cross-device invocation of other capabilities, such as handwriting tablets, recording, and scanning. Adaptation to different scenarios is required in cross-device service invocation. For example, if invoking a computer-related service, after the first electronic device obtains the distributed context of the service on the second electronic device, the relevant application on the first electronic device can directly initiate the invocation of the service on the second electronic device. It is understood that in the above cross-device invocation scenarios, communication between different processes is achieved through the association between the module identifier and the unique identifier of the IBinder object, with the IPC communication component forwarding the request to the corresponding module based on the module identifier.

[0274] In some embodiments, cross-device service call messages can also be communicated within the same process. In this case, different module identifiers can be set for different modules within the same process, and process communication can be based on the module identifiers. Alternatively, different modules can be distinguished in other ways so that call messages can be forwarded to different modules, thereby realizing cross-device service calls.

[0275] This application also provides a chip system, such as... Figure 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 are interconnected via lines. For example, the interface circuit 902 can be used to receive signals from other devices (e.g., the memory of an electronic device). As another example, the interface circuit 902 can be used to send signals to other devices (e.g., the processor 901). Exemplarily, the interface circuit 902 can read instructions stored in the memory and send those instructions to the processor 901. When the instructions are executed by the processor 901, the electronic device can perform the steps in the above embodiments. Of course, the chip system may also include other discrete devices, and this application embodiment does not specifically limit this.

[0276] This application also provides a computer storage medium that includes computer instructions. When the computer instructions are executed on the electronic device, the electronic device causes the electronic device to perform various functions or steps performed by the mobile phone in the above method embodiment.

[0277] This application also provides a computer program product that, when run on a computer, causes the computer to perform the various functions or steps performed by the mobile phone in the above method embodiments.

[0278] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above 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 this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0280] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0281] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0282] If the integrated unit is implemented as 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 solutions of the embodiments of this application, essentially or in other words, the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0283] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A cross-device data processing method, applied to a first electronic device, characterized in that, The method includes: In response to a user's first operation on the first application, the first electronic device acquires judgment information; wherein, the judgment information is used to indicate whether the first module of the first electronic device has a module identifier; If the judgment information indicates that the first module does not have a module identifier, the first electronic device determines the first module identifier corresponding to the first module through the Binder module of the first electronic device; The first electronic device creates a target IBinder object for a first service through the Binder module and determines a first identifier for the target IBinder object; wherein the first identifier is associated with the identifier of the first module, and the target IBinder object is used to invoke the first service provided by the first module; The first electronic device invokes the target service of the second electronic device based on the distributed application plugin corresponding to the 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 by the second electronic device based on the first IBinder object of the target service when registering 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 invoke 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. 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; Wherein, the first electronic device creates a target IBinder object for the first service through the Binder module, and determines a first identifier for 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 process further includes: The first module of the first electronic device sends a first call request to the first Binder management module, the first call request being used to request the first Binder management module to create the target IBinder object of the first service; Wherein, 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. The first acquisition request is used to request the acquisition of the module identifier of the first module. In response to the first acquisition request, the inter-process communication module assigns a corresponding first module identifier to the first module 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. The second acquisition request is used to request the acquisition of a first identifier of the target IBinder object; wherein, the acquisition request includes the identifier of the first module. In response to the second acquisition request, the second Binder management module determines the corresponding first identifier based on the target IBinder object.

4. The cross-device data processing method according to any one of claims 1-3, characterized in that, Before the first electronic device determines the first module identifier corresponding to the first module through the first electronic device's Binder module, the method further includes: The Binder module of the first electronic device sends an initialization command 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.

5. The cross-device data processing method according to claim 3, characterized in that, Before the first electronic device calls the target service of the second electronic device based on the distributed application plugin corresponding to the target module identifier in the first module identifier, the process 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 with the second identifier; The first electronic device returns the second IBinder object to the distributed application plugin based on the target module identifier; The first electronic device sends the second IBinder object to the first application via the distributed application plugin 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 based on the second module identifier of the first application, the method further includes: The first application sends a second invocation request to the first Binder management module, the second invocation request being 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 invoke 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. The third acquisition request is used to request the acquisition of the module identifier of the first application. In response to the third acquisition request, the inter-process communication module assigns a 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. The fourth acquisition request is used to request the acquisition of the third identifier of the reference object; wherein, the acquisition request includes the identifier of the second module. In response to the fourth acquisition request, the second Binder management module determines the corresponding third identifier based on the referenced object and associates the third identifier with the second module identifier; Wherein, the first electronic device sends the second IBinder object to the first application via the distributed application plugin based on the second module identifier of the first application, including: The distributed application plugin sends the referenced 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 invokes the target service of the second electronic device based on the distributed application plugin corresponding to the target module identifier in the first module identifier, including: The first application sends a service call request to the distributed application plugin based on the target module identifier; wherein the service call request includes the reference object; In response to the service call request, the distributed application plugin invokes the target service based on the second IBinder object corresponding to the referenced object.

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

9. An electronic device, characterized in that, The electronic device includes: a communication module, a display screen, a memory, and one or more processors; the communication module, the display screen, the memory, and the processors are coupled; the memory is used to store computer program code, the computer program code including computer instructions, which, when executed by the electronic device, cause the electronic device to perform 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 that, when executed in an electronic device, cause the electronic device to perform the method as described in any one of claims 1 to 8.

Images