A cross-device data processing method and an electronic device
By building PC Binder modules and cross-device IBinder objects in electronic devices, cross-device service calls are enabled, solving the problem of cumbersome operations between devices and improving the efficiency of data processing for users across different devices.
Patent Information
- Application Number
- CN202311386437.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-10-23
- Publication Date
- 2025-12-12
- Estimated Expiration
- 2043-10-23
AI Technical Summary
Due to the differences in the functions of different electronic devices, users need to frequently switch and transfer data when operating across devices, which makes the operation cumbersome, especially when uploading whiteboard content photographed by a mobile phone to computer notes, the steps are cumbersome and inefficient.
By building a PC Binder module in the first electronic device, creating a cross-device IBinder object and associating it with the target module identifier, cross-device service calls are realized, allowing the capture or scanning results to be directly obtained from the second electronic device and sent back to the first device, thus simplifying the operation process.
It reduces the steps users need to switch between multiple devices and transfer data, improves work efficiency, and simplifies the operation process, especially when shooting or scanning whiteboard content, the results can be directly sent back to the computer notebook.
Smart Images

Figure CN119922226B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of electronic devices, and in particular to a cross-device data processing method and an electronic device. BACKGROUND
[0002] Currently, because different types of electronic devices have different functions, users will use more convenient electronic devices according to different scenes. For example, because the screen of a computer is relatively larger than that of a mobile phone, users usually use a computer to organize notes for learning, and in an offline classroom, the content of blackboard writing needs to be photographed and inserted into the notes of the computer.
[0003] Because there is no rear camera on the computer, the existing solution is to photograph the content of blackboard writing through a mobile phone, upload the photographed content to the computer, then download and save it to the computer, and finally upload it to the notes of the computer. However, in this method, multiple devices are switched and used for data transmission, which is relatively cumbersome. SUMMARY
[0004] Embodiments of the present application provide a cross-device data processing method and an electronic device, which can realize cross-device calling of services, reduce the complexity of operations, and improve the work efficiency of users.
[0005] To achieve the above-mentioned purpose, embodiments of the present application adopt the following technical solutions:
[0006] In a first aspect, a cross-device data processing method is provided, which can be applied to a first electronic device. The method includes: obtaining, by the first electronic device, a first Binder identification (ID) from a second electronic device, and creating a second IBinder object based on the first Binder ID; wherein the first Binder ID is determined by the second electronic device when registering a distributed application management service according to a first IBinder object of the distributed application management service, and the first IBinder object and the second IBinder object are used to call the distributed application management service; determining, by the first electronic device, a first identification based on the second IBinder object, and associating a target module identification based on the first identification, so that the first electronic device initiates a call to the distributed application management service based on a distributed application plug-in corresponding to the target module identification.
[0007] By adopting the above-mentioned solution, a unique identification can be applied for an IBinder object newly created in a PC Binder module constructed in the first electronic device for calling a cross-terminal service, and the corresponding module identification is associated, so as to realize calling of the Binder framework corresponding to the module identification to the service, and the Binder calling of the PC terminal is realized. Here, the first electronic device takes the PC as an example, and the service refers to the distributed application management service.
[0008] In the method, the user can send a shooting instruction to the second electronic device by using the first electronic device, the second electronic device starts a camera to perform a shooting or scanning task after receiving the shooting instruction, and the second electronic device returns the shooting result or the scanned text to the first electronic device directly after the shooting or scanning task is completed. The method can save the steps of uploading the shooting result or the scanned text to the second electronic device, downloading and saving the shooting result or the scanned text to the second electronic device, and then uploading the shooting result or the scanned text to the corresponding position of the second electronic device, and the operation is more convenient, and the work efficiency of the user is improved.
[0009] In the above process, since the service call is initiated through the distributed application plug-in, the IBinder object of the distributed application management service can be sent to the distributed application plug-in only by associating the module identifier of the distributed application plug-in. In fact, the second IBinder object obtained by the distributed application plug-in is not the second IBinder object, but a reference object of the second IBinder object. Therefore, the first identifier of the target module identifier associated with the second IBinder object can be understood as the first identifier of the target module identifier corresponding to the reference object of the second IBinder object.
[0010] In a possible implementation manner of the first aspect, before the first electronic device obtains the first Binder identifier ID from the second electronic device, the method further includes: displaying, by the first electronic device, a display interface of a first application, the display interface of the first application including a plurality of device controls, each device control corresponding to a device that establishes a preset wireless connection with the first electronic device, and each device control including one or more services provided by the corresponding device; receiving, by the first electronic device, a first touch operation of a user on a target device control in the plurality of device controls, the first touch operation corresponding to the distributed application management service of the second electronic device. Wherein, the touch operation for the camera service is to call the distributed application management service.
[0011] In a possible implementation of the first aspect, after the first electronic device determines the first identifier based on the second IBinder object and associates the target module identifier based on the first identifier, the first electronic device further includes: in response to receiving a first request from the second electronic device, the first electronic device finds the corresponding second IBinder object according to the first Binder ID contained in the first request; the first electronic device obtains the corresponding first identifier based on the second IBinder object, and finds the corresponding target module identifier based on the first identifier, and obtains the first file providing object of the first application through the distributed application plug-in corresponding to the target module identifier; the first electronic device determines the second identifier based on the first file providing object, and associates the target module identifier based on the second identifier, and indicates the first file providing object of the first application to the second electronic device through the distributed application plug-in corresponding to the target module identifier. Wherein, the first request is used to request to obtain the first file providing object, the first request is sent by the second electronic device in response to the second touch operation of the second application by the user, the second touch operation is used to confirm the result of the second electronic device executing the distributed application management service on the second application, and the first file providing object is used to support the second electronic device returning the result of executing the distributed application management service to the first electronic device. Wherein, the module identifier associated through the first identifier realizes the communication between different modules.
[0012] In a possible implementation of the first aspect, after the first electronic device indicates the first file providing object of the first application to the second electronic device through the distributed application plug-in corresponding to the target module identifier, the first electronic device further includes: in response to receiving a second request from the second electronic device, the first electronic device obtains the corresponding second identifier based on the first file providing object, and finds the corresponding target module identifier based on the second identifier, and indicates the first file handle object to the second electronic device through the distributed application plug-in corresponding to the target module identifier. Wherein, the second request is generated by the second electronic device based on the first file providing object, and is used to request to obtain the first file handle object for calling the preset cache file of the first application; the first electronic device receives the result of executing the distributed application management service returned by the second electronic device based on the first file handle object. Wherein, by associating the target module identifier with the corresponding second identifier when obtaining the first file providing object, the request can be forwarded to the corresponding module according to the associated target module identifier when the request is received.
[0013] In a possible implementation manner of the first aspect, the first electronic device, in response to receiving the second request from the second electronic device, obtains a corresponding second identifier based on the first file providing object, and finds a corresponding target module identifier based on the second identifier, and indicates the first file handle object to the second electronic device through the distributed application plug-in corresponding to the target module identifier, including: the first electronic device, in response to receiving the second request from the second electronic device, finds a corresponding first file providing object according to a second Binder ID contained in the second request. The first electronic device obtains a corresponding second identifier based on the first file providing object, and finds a corresponding target module identifier based on the second identifier, and obtains the first file handle object through the distributed application plug-in corresponding to the target module identifier, and creates a first distributed file based on the first file handle. The first electronic device sends the name of the first distributed file to the second electronic device.
[0014] In a possible implementation manner of the first aspect, the first electronic device, in response to receiving the second request from the second electronic device, obtains a corresponding second identifier based on the first file providing object, and finds a corresponding target module identifier based on the second identifier, and indicates the first file handle object to the second electronic device through the distributed application plug-in corresponding to the target module identifier, including: the first electronic device, in response to receiving the second request from the second electronic device, finds a corresponding first file providing object according to a second Binder ID contained in the second request. The first electronic device obtains a corresponding second identifier based on the first file providing object, and finds a corresponding target module identifier based on the second identifier, and obtains the first file handle object through the distributed application plug-in corresponding to the target module identifier, and creates a first distributed file based on the first file handle. The first electronic device sends the name of the first distributed file to the second electronic device.
[0015] In a possible implementation of the first aspect, before the first electronic device receives the first request from the second electronic device, the method further includes: sending, by the first electronic device, an opening instruction to the second electronic device, where the opening instruction is used to open the second application of the second electronic device. The first application of the first electronic device sends the opening instruction to the second application of the second electronic device based on the second IBinder object. The first application sends the opening instruction, which can also be regarded as a call message, to the distributed application plug-in. The distributed application plug-in obtains the first identifier of the second IBinder object through the Binder module
[0016] In a possible implementation of the first aspect, before the first electronic device obtains the first Binder identifier ID from the second electronic device, the method further includes: sending, by the first application, the distributed application plug-in, the service cooperation module, the Binder module, and the distributed file module of the first electronic device, an initialization instruction to the inter-process communication module of the first electronic device. The inter-process communication module of the first electronic device allocates a corresponding module identifier to the first application, the distributed application plug-in, the service cooperation module, the Binder module, and the distributed file module of the first electronic device.
[0017] In a second aspect, the present application provides an electronic device, which 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 configured to store computer program code, the computer program code includes computer instructions, when the computer instructions are executed by the electronic device, the electronic device executes the method in the first aspect.
[0018] In a third aspect, the present application provides a computer readable storage medium, which stores instructions, when the instructions are executed on a computer, the computer can execute the method in any one of the first aspect.
[0019] In a fourth aspect, the present application provides a computer program product including instructions, when the instructions are executed on a computer, the computer can execute the method in any one of the first aspect.
[0020] It can be understood that the electronic device in the second aspect, the computer readable storage medium in the third aspect, and the computer program product in the fourth aspect provided above are all used to execute the corresponding method provided above, and thus the beneficial effects achieved by the electronic device in the second aspect, the computer readable storage medium in the third aspect, and the computer program product in the fourth aspect can refer to the beneficial effects of the corresponding method provided above, which will not be described herein again. BRIEF DESCRIPTION OF DRAWINGS
[0021] Figure 1 A scene schematic diagram of inserting board content of offline classroom is provided for the embodiments of the present application.
[0022] Figure 2 A hardware structure schematic diagram of an electronic device provided for an embodiment of the present application;
[0023] Figure 3 A software structure schematic diagram of a first electronic device provided for an embodiment of the present application;
[0024] Figure 4 A software structure schematic diagram of a second electronic device provided for an embodiment of the present application;
[0025] Figure 5 A schematic diagram of IPC initialization provided for an embodiment of the present application;
[0026] Figure 6 A timing diagram of registering a distributed application management service and obtaining a service provided for an embodiment of the present application;
[0027] Figure 7 An interface display schematic diagram of a note application provided for an embodiment of the present application;
[0028] Figure 8 A schematic diagram of a first electronic device starting a camera of a second electronic device provided for an embodiment of the present application;
[0029] Figure 9 A timing diagram of obtaining a File Provider object of a note provided for an embodiment of the present application;
[0030] Figure 10 A timing diagram of obtaining a file handle of a note provided for an embodiment of the present application;
[0031] Figure 11 A schematic diagram of creating a distributed file provided for an embodiment of the present application;
[0032] Figure 12 A schematic diagram of a PC Binder mechanism of cross-device calling provided for an embodiment of the present application;
[0033] Figure 13 A structure schematic diagram of a chip system provided for an embodiment of the present application. DETAILED DESCRIPTION
[0034] Clearly, only some of the embodiments of the application are described herein and all modifications that come within the scope of the application are protected by the application. The following terms should therefore not be interpreted in an exclusive sense: first, second, etc.
[0035] Furthermore, the terms "comprising" and "including" and any of their derivatives, as used in the description of the application, are intended to be taken in their broadest sense as meaning that they include a stated step, integer, etc, without precluding the addition of further steps, integers, etc. or the inclusion of further steps, integers, etc.
[0036] In addition, the words "example" and "exemplary" are used herein to mean serving as an instance, example, or illustration, and not as implying any preference or superiority. The use of these terms is intended to present concepts in a concrete form for purposes of illustration only.
[0037] For the purpose of facilitating understanding, the terms related to the embodiments of the application are introduced herein:
[0038] Binder: Binder is a medium for communication between the client and the server. The server returns a Binder object containing the server business call, and the client can obtain the services or data provided by the server through the Binder object.
[0039] The Binder mechanism supports intra-process calls and inter-process calls. Remote calls (i.e. cross-process calls) can be implemented through IBinder. IBinder is a basic interface for remote calls. The main application programming interface (API) of IBinder is transact(), and the corresponding method is Binder.onTransact(). The first method enables the local end to send a call to the remote IBinder object, and the second method enables the remote object of the local end to respond to the received call.
[0040] 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.
[0041] 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.
[0042] 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.
[0043] 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.
[0044] 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.
[0045] 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.
[0046] Generally, the PC is installed with a Windows system, and the mobile phone is installed with an Android system. The cross-device call between the PC and the mobile phone refers to the cross-device call between the Windows system and the Android system. Therefore, in order to make the cross-device call scheme between the Windows side and the Android side more universal, the architecture design of Windows system->Android system and Android system->Android system needs to be unified, and the access mode also needs to be consistent. Windows system->Android system refers to that the Windows side calls the Android side, for example, the PC calls the mobile phone; Android system->Android system refers to that the Android side calls the Android side, for example, the tablet calls the mobile phone.
[0047] Therefore, the PC Binder capability needs to be built on the PC side (the Windows system side) to support the Binder call on the PC side, the Binder framework on the Android side needs to be transplanted, and the corresponding capability adaptation is made on the Windows platform. After the PC Binder capability is built on the PC side, a component framework similar to that on the Android side is also built to support the binding of Activity components and Service components, the access of Provider, and other capabilities across devices. The component framework built on the PC side is similar to that on the Android side, and due to the difference between the systems, the system underlying capabilities may be different, and the interface provided by the system needs to be improved.
[0048] For example, the electronic device in the embodiment of the present application can be a tablet computer, a mobile phone, a desktop computer, a laptop computer, a handheld computer, a notebook computer, an ultra-mobile personal computer (UMPC), a netbook, and a cellular phone, a personal digital assistant (PDA), an augmented reality (AR) \ virtual reality (VR) device, a vehicle-mounted device, and the like. The specific form of the electronic device is not specially limited in the embodiment of the present application.
[0049] In the embodiment of the present application, the electronic device can be divided into a private device and a public device. It can be understood that the private device is used to indicate a device that can be used only by the owner (i.e., the owner of the device). For example, the private device can be a mobile phone, a smart watch, smart glasses, a headset, and the like. The public device is used to indicate a device that can be used by any user. That is, there can be multiple accounts logged in the public device, and there is an association between the multiple different accounts. For example, the public device can be a television, a sound box, a tablet computer, and the like.
[0050] The execution subject of the cross-device service calling method provided in the application can be a cross-device data processing apparatus, and the execution apparatus can be a central processing unit (CPU) of the electronic device or a control module for cross-device data processing in the electronic device. In the embodiments of the application, the cross-device data processing method is executed by the electronic device as an example to illustrate the cross-device data processing method provided in the embodiments of the application. Figure 2 The execution subject of the cross-device service calling method provided in the application can be a cross-device data processing apparatus, and the execution apparatus can be a central processing unit (CPU) of the electronic device or a control module for cross-device data processing in the electronic device. In the embodiments of the application, the cross-device data processing method is executed by the electronic device as an example to illustrate the cross-device data processing method provided in the embodiments of the application.
[0051] The implementation of the embodiments of the application will be described in detail below with reference to the accompanying drawings. The above electronic device is taken as a mobile phone as an example to introduce the hardware structure of the electronic device (such as the electronic device 300). Among them, Figure 2 The electronic device 300 shown in the drawings is only an example of the electronic device, and the electronic device 300 can have more or fewer components than those shown in the drawings, can combine two or more components, or can have a different component configuration. Figure 2 The various components shown in the drawings 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.
[0052] Please refer to Figure 2 , Figure 2 The structure of the electronic device is shown in the schematic diagram, as shown in Figure 2 The electronic device 300 can include a processor 310, an external memory interface 320, an internal memory 321, a USB interface 330, a charge 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 headset interface, a sensor module 380, a key 390, a motor 391, an indicator 392, a camera 393, a display screen 394, and a subscriber identification module (SIM) card interface 395, etc.
[0053] Among them, the above-mentioned sensor module 380 can include pressure sensor, gyroscope sensor, barometric pressure sensor, magnetic sensor, acceleration sensor, distance sensor, proximity light sensor, fingerprint sensor, temperature sensor, touch sensor, ambient light sensor and bone conduction sensor, etc.
[0054] It can be understood that the structure illustrated in the embodiment does not constitute a specific limitation on the electronic device 300. In other embodiments, the electronic device 300 can include more or fewer components than illustrated, or combine certain components, or split certain components, or different arrangement of components. The illustrated components can be implemented in hardware, software, or a combination of software and hardware.
[0055] The processor 310 can include one or more processing units, for example: the processor 310 can include an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Among them, different processing units can be independent devices, or can be integrated in one or more processors.
[0056] The controller can be the nerve center and command center of the electronic device 300. The controller can generate operation control signals according to instruction operation codes and timing signals, and complete the control of fetching and executing instructions.
[0057] The memory can also be provided in the processor 310, for storing instructions and data. In some embodiments, the memory in the processor 310 is a cache memory. The memory can save instructions or data that the processor 310 has just used or repeatedly uses. If the processor 310 needs to use the instructions or data again, it can directly call from the memory. Avoiding repeated access, reducing the waiting time of the processor 310, thus improving the efficiency of the system.
[0058] In some embodiments, the processor 310 can include one or more interfaces. The interfaces can 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.
[0059] It can be understood that the interface connection relationship between the modules shown in the embodiments is only illustrative and does not constitute a limitation on the structure of the electronic device 300. In other embodiments, the electronic device 300 can also use different interface connection manners or combinations of multiple interface connection manners.
[0060] The charging management module 340 is configured to receive a charging input from a charger. In the embodiments of the present application, the charger is a wired charger, and the charging management module 340 can receive the charging input of the wired charger through the USB interface 330 (i.e., the charging interface described above). The charging management module 340 can charge the battery 342 and also supply power to the electronic device through the power management module 341.
[0061] The power management module 341 is configured to connect the battery 342, the charging management module 340, and the processor 310. The power management module 341 receives the input of the battery 342 and / or the charging management module 340 to supply power to the processor 310, the internal memory 321, the external memory, the display screen 394, the camera 393, and the wireless communication module 360, etc. The power management module 341 can also be configured to monitor parameters such as the battery capacity, the battery cycle number, the battery health status (leakage, impedance), etc. In other embodiments, the power management module 341 can also be arranged in the processor 310. In other embodiments, the power management module 341 and the charging management module 340 can also be arranged in the same device.
[0062] The wireless communication function of the electronic device 300 can be implemented by the antenna 1, the antenna 2, the mobile communication module 350, the wireless communication module 360, the modem processor, the baseband processor, and the like.
[0063] The antenna 1 and the antenna 2 are used for transmitting and receiving electromagnetic wave signals. Each antenna in the electronic device 300 can be used to cover a single or multiple communication frequency bands. Different antennas can also be multiplexed to improve the utilization of the antennas. For example, the antenna 1 can be multiplexed as a diversity antenna of a wireless local area network. In some other embodiments, the antennas can be used in combination with a tuning switch.
[0064] The mobile communication module 350 can provide a solution for wireless communication including 2G / 3G / 4G / 5G and the like applied to the electronic device 300. The mobile communication module 350 can include at least one filter, a switch, a power amplifier, a low noise amplifier (LNA), and the like. The mobile communication module 350 can receive electromagnetic waves by the antenna 1, and perform filtering, amplification, and the like on the received electromagnetic waves, and transmit the processed electromagnetic waves to the modem processor for demodulation.
[0065] The mobile communication module 350 can also amplify the signals modulated by the modem processor, and convert the signals into electromagnetic waves radiated by the antenna 1. In some embodiments, at least part of the functional modules of the mobile communication module 350 can be arranged in the processor 310. In some embodiments, at least part of the functional modules of the mobile communication module 350 and at least part of the modules of the processor 310 can be arranged in the same device.
[0066] The wireless communication module 360 can provide a solution for wireless communication including wireless local area networks (WLAN) (such as a wireless fidelity (Wi-Fi) network), Bluetooth (BT), a global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR) technology, and the like, applied to the electronic device 300. For example, in the embodiments of the present application, the electronic device 300 can access a Wi-Fi network through the wireless communication module 360.
[0067] The wireless communication module 360 can be one or more devices that integrate at least one communication processing module. The wireless communication module 360 receives electromagnetic waves via the antenna 2, frequency-modulates and filters the electromagnetic wave signals, and transmits the processed signals to the processor 310. The wireless communication module 360 can also receive signals to be transmitted from the processor 310, frequency-modulate them, amplify them, and radiate them as electromagnetic waves via the antenna 2.
[0068] In some embodiments, the antenna 1 and the mobile communication module 350 of the electronic device 300 are coupled, and the antenna 2 and the wireless communication module 360 are coupled, so that the electronic device 300 can communicate with a network and other devices through wireless communication technology. The wireless communication technology can include global system for mobile communications (GSM), general packet radio service (GPRS), code division multiple access (CDMA), wideband code division multiple access (WCDMA), time-division code division multiple access (TD-SCDMA), long term evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technology, etc. The GNSS can include a global positioning system (GPS), a global navigation satellite system (GLONASS), a beidu navigation satellite system (BDS), a quasi-zenith satellite system (QZSS), and / or a satellite based augmentation systems (SBAS).
[0069] The electronic device 300 implements a display function through a GPU, a display screen 394, and an application processor, etc. The GPU is a microprocessor for image processing, which is connected to the display screen 394 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 310 can include one or more GPUs that execute program instructions to generate or change display information.
[0070] The display screen 394 is configured to display images, videos, and the like. The display screen 394 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flex light-emitting diode (FLED), a Miniled, a Micro Led, a Micro-oLed, a quantum dot light emitting diode (QLED), or the like.
[0071] The electronic device 300 can implement a photographing function through an ISP, the camera 393, a video codec, a GPU, the display screen 394, and an application processor, and the like. The ISP is configured to process data fed back by the camera 393. The camera 393 is configured to capture a still image or a video. In some embodiments, the electronic device 300 can include one or N cameras 393, where N is a positive integer greater than 1. The digital signal processor is configured to process a digital signal, which can be a digital image signal, and can also be other digital signals. For example, when the electronic device 300 selects a frequency point, the digital signal processor is configured to perform Fourier transform on the frequency point energy, and the like. The video codec is configured to compress or decompress a digital video. The NPU is a neural-network (NN) calculation processor, which is configured to process input information quickly by referring to a biological neural network structure, for example, by referring to a transmission mode between neurons in a human brain, and can also be self-learned constantly. Through the NPU, the electronic device 100 can implement intelligent cognition applications, such as image recognition, face recognition, voice recognition, text understanding, and the like.
[0072] The external memory interface 320 can be configured to connect an external memory card, such as a Micro SD card, to implement an extension of the storage capability of the electronic device 300. The external memory card communicates with the processor 310 through the external memory interface 320 to implement a data storage function. For example, music, video, and the like are saved in the external memory card.
[0073] The internal memory 321 can be used to store computer executable program codes, which include instructions. The processor 310 performs various functional applications and data processing of the electronic device 300 by running the instructions stored in the internal memory 321. For example, in the embodiments of the present application, the processor 310 can perform the instructions stored in the internal memory 321, and the internal memory 321 can include a storage program area and a storage data area.
[0074] The storage program area can store an operating system, at least one application program required by a function (such as a sound playing function, an image playing function, etc.), and the like. The storage data area can store data (such as audio data, a phone book, etc.) created during the use of the electronic device 300, and the like. In addition, the internal memory 321 can include a high-speed random access memory, and can further include a non-volatile memory, such as at least one magnetic disk storage device, a flash memory device, a universal flash storage (UFS), and the like.
[0075] The electronic device 300 can realize an audio function through an audio module 370, a speaker 370A, a receiver 370B, a microphone, a headset interface, and an application processor, and the like. For example, music playing, recording, and the like.
[0076] The audio module 370 is used to convert digital audio information into an analog audio signal output, and is also used to convert an analog audio input into a digital audio signal. The audio module 370 can also be used to encode and decode an audio signal. In some embodiments, the audio module 370 can be disposed in the processor 310, or part of the functions of the audio module 370 can be disposed in the processor 310. The speaker 370A, also known as a “loudspeaker”, is used to convert an audio electrical signal into a sound signal. The receiver 370B, also known as a “earpiece”, is used to convert an audio electrical signal into a sound signal. The microphone, also known as a “microphone”, “sound receiver”, is used to convert a sound signal into an electrical signal.
[0077] The headset interface is used to connect a wired headset. The headset interface can be a USB interface 330, or a 3.5 mm open mobile terminal platform (OMTP) standard interface, a cellular telecommunications industry association of the USA (CTIA) standard interface.
[0078] The keys 390 include an on / off key, a volume key, and the like. The keys 390 can be mechanical keys. The keys 390 can also be touch keys. The motor 391 can generate a vibration prompt. The motor 391 can be used for incoming call vibration prompt, and can also be used for touch vibration feedback. The indicator 392 can be an indicator light, and can be used to indicate a charging state, a power change, and can also be used to indicate a message, a missed call, a notification, and the like. The SIM card interface 395 is used to connect a SIM card. The SIM card can be inserted into or pulled out of the SIM card interface 395 to realize contact and separation with the electronic device 300. The electronic device 300 can support one or N SIM card interfaces, and N is a positive integer greater than 1. The SIM card interface 395 can support a Nano SIM card, a Micro SIM card, a SIM card, and the like.
[0079] Although Figure 2 Not shown, the electronic device 300 can also be a flash, a micro projection device, a near field communication (NFC) device, and the like, which will not be described here.
[0080] After introducing the hardware structure of the electronic device, the system architecture of the electronic device provided in the present application is introduced. The system architecture of the electronic device can adopt a layered architecture, an event-driven architecture, a microkernel architecture, a microservice architecture, or a cloud architecture. The embodiment of the present application takes a layered system as an example to exemplarily illustrate the software structure of the electronic device.
[0081] The layered architecture divides the software into several layers, and each layer has a clear role and division of labor. The layers communicate with each other through a software interface. In some embodiments, the PC side system can include, from top to bottom, an application layer, a distributed application plug-in, a service collaboration layer, a PC Binder module, a communication module and a device Profile layer, and an inter-process communication (IPC) module.
[0082] The application program layer can include a series of application program packages. The application program package can include notes, cameras, mail, schedules, and the like. The application program package can also include gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, short message, and the like.
[0083] As Figure 3 shown, the distributed application plug-in is used to process service calls between distributed applications on the PC side, and meets the call requirements of the distributed application framework.
[0084] As Figure 3As shown, the service coordination layer is used to provide management capabilities of remote services, responsible for forwarding service calls between devices, and converting local resource references (anonymous Binder objects, file descriptors, etc.) into inter-device resource references. The service coordination layer can include a distributed service management module, a distributed Binder management module, a distributed file management module, a transmission management module, and a device management module.
[0085] The distributed service management module includes a service management module and a service acquisition module. The service management module is used to manage multiple remote devices in the presence of multiple remote devices. The service acquisition module is used to acquire the target service of device 2 after the target service of device 2 is registered in the scenario where device 1 calls the target service of device 2.
[0086] The services listed in the distributed service management module are all named services, which are system services, i.e. real-name services, and the corresponding Binder objects are real-name Binders. When the service provider registers the service, the service is registered in the distributed service management module.
[0087] The distributed Binder management module includes a Binder management mapping module and a Binder access authentication module.
[0088] The Binders in the distributed Binder management module are all anonymous Binders in addition to the real-name Binders, so the scope is wider than that of the Binders in the distributed service management module. The anonymous Binder refers to a Binder that is not registered in the distributed service management module and is created by the application itself.
[0089] The Binder management mapping module is used to manage Binder objects, involving the mapping between local Binders and remote Binders.
[0090] The distributed file management module is responsible for reading and writing files across devices. The distributed file management module is used to manage distributed files, mainly creating files, opening files, and other operations, i.e. involving the transmission of messages between devices, which will be serialized and deserialized.
[0091] The distributed file management module mainly refers to a scenario of taking a photo, for example, a PC calls a photo shooting capability of a mobile phone, and an actual photo cache file is created by the PC. Then, the mobile phone side acquires a file handle of the photo cache file of the PC side after taking a photo. After acquiring the file handle, a write operation is performed on the photo cache file. That is, cross-device reading and writing are involved. The distributed file management module can provide cross-device file access. The file handle is a relatively complex object, similar to a Binder object.
[0092] The transmission management module refers to a session created between devices, and a message is transmitted through the session.
[0093] The device management module refers to an accessed device. The device can have an online or offline operation. Offline means that the device has been accessed and then is offline, that is, no longer accessed, and all resources related to the device need to be cleaned up or other operations. One or more devices can be accessed.
[0094] As shown in Figure 3 , the PC Binder module includes an IPC Client module, a Binder Software Development Kit (SDK) module (PC Binder SDK module), a PC Binder Manager module, and a Binder Server module.
[0095] When the client and the server perform cross-process access, the IPC Message component needs to be initialized. The IPC Message component is equivalent to the server, and each application needs to use the IPC Message component when performing cross-process communication, and then the IPC Client module needs to be generated internally.
[0096] The Binder SDK module is used to provide interfaces for various businesses. The PC Binder Manager module is used to manage local binder resources. The Binder Server module is used to implement binder calling.
[0097] As shown in Figure 3 , the communication module and the device Profile layer include a communication module, a device Profile module, and a distributed file module.
[0098] Among them, the communication module is responsible for the transmission module, including device discovery connection service and data transmission service, etc., provides cross-device transmission interface, supports automatic networking in trust ring, one-to-many connection, and sleep device wake-up. In the scene of cross-device calling, the information transmission between devices is carried out through the communication module.
[0099] The device Profile module is used to provide the information of the device, provide the service registration interface supported by the device, and the interface for querying the service of other devices.
[0100] The distributed file module, i.e. the distributed file management mentioned above, is responsible for the reading and writing of cross-device files.
[0101] The IPC module includes an IPC Message, wherein the IPC Message is an inter-process communication component, which can be referred to as an IPC communication module. The PC side will rely on the above-mentioned IPC Message when building the cross-process communication capability.
[0102] In some embodiments, the system on the Android side can be divided into five layers, from top to bottom, application layer, system application framework layer, collaborative service and scheduling layer, communication module and device Profile layer, and kernel layer.
[0103] Among them, the application program layer can include a series of application program packages. As shown in Figure 4 The application program package can include: notes, cameras, mail, schedules. The application program package can also include gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, short message, etc.
[0104] As shown in Figure 4As shown, the system application framework layer can 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 (SM), a Distributed Service Manager (DSM), and a system Binder framework. Among them, the AMS, PMS and SM are system services already existing in the Android system, and the related functions are not specifically introduced here. Among them, the DAMS, DPMS and DSM are system functions newly added by the embodiments of the present application in the distributed system, and together they are a distributed application framework, used to process service calls between distributed applications in the present application. Among them, the distributed application framework can provide a distributed application management service, used to register in the distributed service management module, to realize service calls and management between distributed applications.
[0105] As shown, Figure 4 The cooperative service and scheduling layer is used to provide management capabilities of remote services, including remote service registration and remote service acquisition. It is responsible for forwarding service calls between devices, and converting local resource references (anonymous Binder objects, file descriptors, etc.) into resource references between devices. Among them, the cooperative service and scheduling layer can include a distributed service management module, a distributed Binder management module, a distributed file management module, a transmission management module and a device management module.
[0106] Among them, the distributed service management module includes a service registration module, a service management module, a service acquisition module and a service life cycle module. The service management module is used to manage multiple remote devices in the case where multiple remote devices exist.
[0107] The service registration module is used to register the target service by the service registration module of device 2 before device 1 calls the target service of device 2. The service acquisition module is used to acquire the target service of device 2 by the service acquisition module of device 1 after the target service of device 2 is completely registered in the scenario where device 1 calls the target service of device 2.
[0108] The service life cycle module is configured to call services provided by the A device and the B device, wherein the A device can have two services and the B device can also have two services, and when a service on the A device or the B device is abnormal or dies, that is, the service exits, the service life cycle module of the device 1 performs some processing on the exited service. The life cycle can be understood as a process of creating and closing.
[0109] The distributed service management module lists all the services with known names, which are system services, that is, real-name services, and the corresponding Binder objects are real-name Binders. The service provider registers the provided services in the distributed service management module.
[0110] The distributed Binder management module includes a Binder management mapping module, a Binder access authentication module, and a Binder life cycle module.
[0111] The Binders in the distributed Binder management module are all anonymous Binders except the real-name Binders, so the scope is wider than that of the Binders in the distributed service management module. The anonymous Binder refers to a Binder that is not registered in the distributed service management module and is created by the application.
[0112] The Binder management mapping module is configured to manage Binder objects and involves mapping between local Binders and remote Binders. The Binder access authentication module is configured to manage the Binder access authentication capability in the cross-device or distributed scenario.
[0113] The distributed file management module is responsible for cross-device file reading and writing. The distributed file management module is configured to manage distributed files, mainly to create files and open files, which involves message transmission between devices and serialization and deserialization. The distributed file management module mainly refers to a scenario of taking a photo, for example, a PC calls the photo taking capability of a mobile phone, and the actual photo cache file is created by the PC. Then, the mobile phone side acquires the file handle of the photo cache file of the PC side after taking a photo. After acquiring the file handle, the mobile phone side performs write operation on the photo cache file. The distributed file management module can provide cross-device file access. The file handle is a complex object similar to the Binder object.
[0114] The transmission management module refers to a session created between devices, through which messages are transmitted. The device management module refers to the accessed device, which can have operations such as going online or offline. Offline means that the device has been accessed and then disconnected, that is, no longer accessed, and all resources related to the device need to be cleaned up or other operations. One or more devices can be accessed.
[0115] As shown in Figure 4 , the communication module and the 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 connection services and data transmission services, provides a cross-device transmission interface, supports automatic networking within a trust ring, one-to-many connection, and sleep device wake-up. In the cross-device calling scenario, information is transmitted between devices through the communication module. The device Profile module provides device information, provides a service registration interface supported by the device, and other device query service interfaces. The distributed file module, i.e., the distributed file management mentioned above, is responsible for cross-device file reading and writing.
[0116] As shown in Figure 4 , the kernel layer includes a Binder driver module, mainly used for cross-device communication.
[0117] In the embodiments of the present application, the first electronic device is taken as the master device and the second electronic device is taken as the auxiliary device. The first electronic device can call the service of the second electronic device, wherein the first electronic device can be a personal computer, a computer, etc., and the second electronic device can be a tablet, a mobile phone, etc. In the scenario where the first electronic device calls the service of the second electronic device, the first electronic device can be a client and the second electronic device can be a server. The server refers to the side that provides services, and the client refers to the side that uses the services provided by the server.
[0118] The cross-device data processing method provided by the embodiments of the present application can be applied to the scenario where the first electronic device calls the photographing service of the second electronic device.
[0119] In the scenario that the note application of the first electronic device invokes the photographing service of the camera application of the second electronic device, first, the first electronic device needs to perform IPC initialization, then the second electronic device registers the distributed application management service in the device itself, and the first electronic device obtains the registered distributed application management service of the second electronic device. After the first electronic device successfully obtains the distributed application management service of the second electronic device, the note application of the first electronic device invokes the camera application of the second electronic device, and after the camera application photographs the specified content, the second electronic device transmits the obtained photographing data to the note application of the first electronic device.
[0120] Therefore, in the embodiment of the present application, the overall flow of the cross-device data processing method mainly includes IPC initialization of the first electronic device, service registration of the second electronic device, service obtaining of the first electronic device, and service data (photographing data) return of the second electronic device to the first electronic device.
[0121] First, the IPC initialization flow of the first electronic device is introduced.
[0122] In the first electronic device, each module needs to be initialized separately to perform IPC initialization to use the IPC Message component of the PC side for cross-process communication. The modules in the first electronic device that need to perform IPC initialization include the note application, the distributed application plug-in, the service collaboration module, the distributed file, and the PC Binder module (also referred to as Binder module).
[0123] Please refer to Figure 5 , Figure 5 The flowchart diagram of the IPC initialization of each module of the first electronic device provided in the embodiment of the present application is shown. As shown in Figure 5 , the specific steps of the IPC initialization of the note application include: the note application sends a message to the IPC communication (IPC message) module, and the message is used to request to obtain the module identifier (Moduleld) corresponding to the note application; the note application receives the message returned by the IPC communication module, and the message contains the module identifier corresponding to the note application. Wherein, the module identifier of the note application can be set as moduleId1. The message sent by the note application to the IPC communication module can also be referred to as initialization instruction.
[0124] In the embodiment of the present application, the steps of the IPC initialization of the distributed application plug-in, the service collaboration module, the PC Binder module, and the distributed file module are the same as the steps of the IPC initialization of the note application, and can be referred to Figure 5The module identifier of the distributed application plug-in is moduleId2, the module identifier of the service coordination module is moduleId3, the module identifier of the PC Binder module is moduleId4, and the module identifier of the distributed file module is moduleId5.
[0125] The first module to start is the IPC communication module after the first electronic device is started. Then, each module in the first electronic device communicates with the IPC communication module to determine the module identifier of each module. The order of the IPC initialization of each module is not limited, and generally, the PC Binder module, the service coordination module, and the distributed application plug-in can be sequentially initialized. Then, the note application and the distributed file module are initialized after the IPC initialization of the PC Binder module, the service coordination module, and the distributed application plug-in is completed, or the note application and the distributed file module can be initialized when they are used.
[0126] In the embodiment of the present application, after the IPC initialization of the above modules is completed, the IPC communication (cross-process communication) between processes can be performed by using the module identifier. That is, the module identifier is used for communication between different processes, and the communication is forwarded to the module corresponding to the module identifier by the IPC communication module.
[0127] Secondly, the service registration process of the second electronic device is introduced. The service registered by the second electronic device is the distributed application management service.
[0128] The application (for example, the camera application) is an interface provided by the distributed application framework in the system application framework. After the first electronic device obtains the distributed application management service registered by the second electronic device, the camera application of the second electronic device can be called by the distributed application framework, and the service provided by the camera application can be obtained.
[0129] The distributed application management service is in the system application framework, and the system application framework is started when the second electronic device is started, that is, the distributed application management service is started. After the second electronic device is started, the communication module is started. After the communication module is started, the service coordination module is started. Therefore, after the service coordination module is started, the second electronic device can register the distributed application management service in the service coordination module.
[0130] The service registration process of the second electronic device is the registration process of the distributed application management service of the second electronic device, and specifically includes:
[0131] The distributed application management service of the second electronic device is registered in the distributed service manager (see step 1 of Figure 6 ). The distributed application management service is started in the system application framework of the second electronic device after the second electronic device is powered on.
[0132] The service name (e.g., "DisApp") and IBinder object (e.g., "IBinder S1") of the distributed application management service are stored in the distributed service manager (see step 1.1 of Figure 6 ). Then, the service name and IBinder object are sent to the distributed Binder manager. The distributed Binder manager caches the IBinder object (IBinder S1) and assigns a BinderId (e.g., "Binder S1") to the IBinder object. That is, IBinder S1 and Binder S1 establish a mapping relationship (see step 1.2 of Figure 6 ). Then, the distributed Binder manager returns the registration result to the system application framework (see step 1.3 of Figure 6 ).
[0133] The service name and IBinder are parameters, and one IBinder object can call one target service. After the first electronic device obtains the IBinder object of the target service of the second electronic device, the IBinder object can be used to call the interface of the corresponding target service, that is, the capability provided by the target service. In the embodiment of the present application, after the first electronic device obtains the IBinder object of the distributed application management service of the second electronic device, the distributed application management service of the second electronic device can be called.
[0134] Each service is provided with a corresponding service name (ServiceName), such as the distributed application management service, the AMS service, the camera service, the audio service, and the like. The service name is registered in the service manager. If in the distributed service scenario, the service name can be registered in the distributed service manager.
[0135] In the embodiments of the present application, a unique identifier (BinderId) can be assigned to an IBinder object, each Binder object has a BinderId, and the BinderId can establish a mapping relationship with the IBinder object. That is, the registered service in the server has a BinderId, and when the corresponding service is obtained in the client, the BinderId can identify the relationship between the two. The mapping relationship can be understood as a key-value pair.
[0136] The BinderId can be assigned according to the device, for example, in the case of accessing multiple second electronic devices, the second electronic devices first set a device identifier (DeviceId), and then assign BinderId to the services on each second electronic device. The device identifier can be pre-set.
[0137] Specifically, the BinderId can be assigned in a certain order. For example, the second electronic device A can provide services a (IBinder a), service b (IBinder b), the second electronic device B can provide service c (IBinder c), then the BinderId corresponding to IBinder a can be Binder1, the BinderId corresponding to IBinder b can be Binder2, and the BinderId corresponding to IBinder c can be Binder3. The form of BinderId is not limited to numbers, but can also be letters, characters, etc. When using numbers as BinderId, it does not necessarily start from 1, but can also start from a specific number and increase sequentially.
[0138] In the embodiments of the present application, the second electronic device stores the service name and IBinder object of the distributed application management service, and the second electronic device assigns BinderId to the IBinder object. Then, in the following steps, the distributed application management service can be obtained through the corresponding service name. The specific obtaining process is to determine the IBinder object through the service name, and after determining the IBinder object, the corresponding BinderId can be determined. The IBinder object and the BinderId are one-to-one corresponding.
[0139] It can be understood that the real-name service is stored in the service name, IBinder object and BinderId in the server. The above relationship is stored in the distributed service management module in the server. The system service has a corresponding service name, and the service name is registered in the distributed service management module, so the system service is a real-name service.
[0140] The storage mode can be a list mode, as shown in Table 1.
[0141] Service name IBinder object Binderld Service S1 IBinder S1 Binderld S1 Service S2 IBinder S2 Binderld S2
[0142] Table 1
[0143] The IBinder object and the BinderId can be stored in two lists, that is, the service name and the IBinder object can be stored in one list, and the IBinder object and the BinderId can be stored in another list. The three are one-to-one corresponding.
[0144] In the embodiment of the present application, after the distributed Binder management module of the second electronic device allocates the BinderId to the IBinder object and establishes the mapping relationship, it means that the registration of the distributed application management service of the second electronic device is successful. The distributed Binder management module of the second electronic device can send the notification information of the successful registration to the system application framework of the second electronic device. At this time, the first electronic device can obtain the distributed application management service registered by the second electronic device.
[0145] Next, the process of the first electronic device obtaining the service is introduced. After the registration of the distributed application management service of the second electronic device is successful, the first electronic device can obtain the distributed application management service registered by the second electronic device.
[0146] It can be understood that before obtaining the distributed application management service, the first electronic device has opened the note application, and the first electronic device responds to the touch operation of the user on the calling entry of the note application interface, and calls out the device list and the capability list. That is to say, when the first electronic device receives the operation of the user, it can be considered that the user has the intention of cross-device calling, and therefore the distributed application management service provided by the second electronic device needs to be obtained.
[0147] The application of the first electronic device can obtain the device list within a certain range through the interaction between devices. The distributed application framework of each device can determine whether the device has a service collaboration module. If a certain device does not have a service collaboration module, the device does not have the cross-device calling capability, and then an empty message is sent to the application of the first electronic device. Therefore, the device name of the device will not be displayed on the application interface of the first electronic device, or the device name of the device will be displayed, but distinguished from other devices with cross-device calling capability through a specific identifier.
[0148] In the embodiment of the present application, the calling entry is provided in the note application of the first electronic device. For example, Figure 7As shown in FIG. 7, the display interface 701 of the note application of the computer is provided with an insertion button 702. After the computer responds to the touch operation of the insertion button 702 by the user, the display interface 701 displays the second electronic device that can provide services and the capability list corresponding to the device. The displayed devices can be the mobile phone 1 and the tablet 1. The capability list includes the services that can be provided by the second electronic device, such as Figure 7 the photographing, scanning, etc. corresponding to the mobile phone 1 and the photographing, scanning, etc. corresponding to the tablet 1.
[0149] In some embodiments of the present application, the display interface of the note application can display all the devices within the set range that have the cross-device calling capability. For example, if all the devices within the set range that have the cross-device calling capability are the mobile phone 1 and the tablet 1. As shown in FIG. 8, the displayed devices are the mobile phone 1 and the tablet 1, and the photographing, scanning, etc. that can be provided by the mobile phone 1 and the tablet 1, respectively. Figure 7
[0150] In some embodiments of the present application, the display interface of the note application can also display all the devices within the set range, and distinguish whether the devices have the cross-device calling capability through the set identification. For example, the devices that do not have the cross-device calling capability can be displayed in gray, and the other devices that have the cross-device calling capability are displayed normally.
[0151] In some embodiments of the present application, the capability list corresponding to the device can also display all the possible services, distinguish whether the services are provided by the device through the set identification information, or only display the services provided by the device.
[0152] In some embodiments of the present application, the display interface of the note application can first display the device list, and then display the capability list corresponding to the device in response to the touch operation on a certain device in the device list.
[0153] In the embodiments of the present application, in response to the opening operation of a certain application of the first electronic device, the application interface is displayed, and then in response to the touch operation on the target button (such as the "insert" button in FIG. 9), the application interface of the first electronic device displays the device list and the corresponding capability list. Figure 7
[0154] In some other embodiments of the present application, in response to the opening operation of a certain application of the first electronic device, the application interface is displayed, and the application interface directly displays the device list and the corresponding capability list.
[0155] That is, the device list and the capability list are displayed before the second electronic device acquires the service, and then in response to a touch operation of a user on a certain item of the list, such as the first electronic device in response to a touch operation of a user on a camera service option of the phone 1 in the list of an application, it can be determined that the corresponding second electronic device is the phone 1, and the target service is the distributed application management service. At this time, the first electronic device can start to acquire the distributed application management service of the phone 1.
[0156] Please refer to Figure 6 , the note application of the first electronic device can acquire the distributed context of the second electronic device, that is, acquire the "DisApp" service of the second electronic device (see step 2 of Figure 6 ). Specifically, the process of the first electronic device acquiring the service includes that the note application of the first electronic device sends a request for acquiring the "DisApp" service to the distributed application plug-in of the first electronic device. The request here is an IPC call request, and the first electronic device needs to communicate between modules through the IPC communication component (IPC communication module). It can be understood that the note application and the distributed application plug-in are different processes, and when communicating, the module identifier of the distributed application plug-in also needs to be acquired to forward through the IPC communication module.
[0157] Then, the distributed application plug-in initiates a request for acquiring the service to the distributed service management module of the first electronic device. Specifically, the distributed application plug-in initiates a request for acquiring the service to the IPC communication (IPC message) module of the first electronic device, and the request is initiated with the device identifier (DeviceId) and the service name (ServiceName). The service name carried here is "DisApp" (see step 2.1 of Figure 6 ).
[0158] After receiving the request, the IPC communication module sends the request for acquiring the service to the distributed service management module of the first electronic device. The IPC communication module can forward the request to the distributed service management module based on the module identifier of the distributed service management module. Then, the distributed service management module of the first electronic device sends a request for acquiring the "DisApp" service to the message center (Message Center) - communication module of the first electronic device (see step 2.2 of Figure 6 ). The service coordination module of the first electronic device includes the distributed service management module and the distributed Binder management module, and the distributed service management module and the distributed Binder management module are in the same process, so the module identifier of the distributed service management module and the distributed Binder management module is the module identifier of the service coordination module.
[0159] It can be understood that, for the request for obtaining the service, the IPC communication module forwards the request to the distributed service management module based on the content of the request, instead of the distributed Binder management module. After the distributed service management module obtains the BinderId corresponding to the service, the distributed Binder management module is called to create a local IBinder object.
[0160] After the communication module of the first electronic device receives the request for obtaining the "DisApp" service, a session with the second electronic device is created (refer to step 2.2.1 of FIG. 2). Figure 6
[0161] In some embodiments of the present application, the first electronic device can establish a connection with the second electronic device according to the device identifier in the request. After the connection is established, the corresponding service is searched from the second electronic device according to the service name in the request.
[0162] The specific steps in which the first electronic device searches for the service from the second electronic device include: creating a session between the first electronic device and the second electronic device. After the session is successfully created, the first electronic device searches for the corresponding service from the second electronic device according to the service name.
[0163] The specific steps of creating the session include: after the session between the communication module of the first electronic device and the communication module of the second electronic device is successfully created, the communication module of the second electronic device sends a session creation success instruction to the distributed Binder management module of the second electronic device, and the communication module of the first electronic device sends a session creation success instruction to the distributed Binder management module of the first electronic device. The distributed Binder management module here is used to manage Binder objects.
[0164] The specific steps in which the first electronic device searches for the corresponding service from the second electronic device according to the service name include: the distributed service management module of the first electronic device sends a service obtaining instruction (refer to step 2.2.2 of FIG. 2), and the first electronic device sends the service name to be obtained to the target device through a message. After the second electronic device receives the message, the service name is parsed according to the content of the message. Then, the target service corresponding to the service name is searched from the distributed service management module. The distributed service management module stores the correspondence between the service name and the IBinder object. Figure 6 If the corresponding target service is found, the IBinder object corresponding to the target service is determined, and the IBinder object is returned to the first electronic device.
[0165]
[0166] The communication module is a message receiving module and has a message receiving function. After the communication module of the second electronic device receives the message, the message can be parsed. If the message contains a service name, the message can be considered as a query type instruction message. Then, the service name in the message can be used to query the corresponding target service 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, the corresponding target service is found. The second electronic device returns the IBinder object corresponding to the target service to the communication module of the second electronic device.
[0167] It can be understood that the distributed Binder management module of the second electronic device establishes a mapping relationship between the IBinder object and the BinderId. After the mapping relationship is successfully established, the distributed Binder management module of the second electronic device sends the mapping relationship to the distributed service management module, and the distributed service management module saves the mapping relationship. For details, refer to the arrow indication of Figure 4
[0168] The second electronic device finds the corresponding IBinder object in the distributed service management module according to the service name, 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 according to the established mapping relationship between the IBinder object and the BinderId. Then, the determined BinderId is sent to the communication module of the second electronic device.
[0169] That is, when the two devices really interact, the communication module of the second electronic device sends the BinderId to the communication module of the first electronic device.
[0170] It should be noted that the IBinder object of the target service generated by the second electronic device is actually not really sent to the client. Because the IBinder object has a system boundary, it only has a specific meaning on the second electronic device. The IBinder object can be understood as a pointer or address, and sending the IBinder object to the first electronic device has no actual meaning. Therefore, the second electronic device sends the BinderId to the first electronic device.
[0171] Specifically, the communication module of the second electronic device assembles a message after receiving the BinderId of the target service, and sends the message to the communication module of the first electronic device. That is, the message carries the BinderId of the target service.
[0172] Referring to Figure 6 , the communication module of the second electronic device receives the message and parses the message to obtain an instruction to obtain the "DisApp" service (see step 2.2.3 of Figure 6 ). The communication module of the second electronic device sends the instruction to the distributed Binder management module of the second electronic device (see step 2.2.4 of Figure 6 ).
[0173] The distributed Binder management module of the second electronic device receives the instruction and searches for the "DisApp" service in the distributed service management module. As known from step 1.1, the distributed service management module of the second electronic device stores service names and corresponding IBinder objects. Thus, the distributed Binder management module of the second electronic device can search for whether the service is stored in the distributed service management module according to the service name ("DisApp") in the above instruction. If the service ("DisApp" service) is found, the corresponding IBinder object (IBinder S1) is determined.
[0174] Then, the distributed service management module of the second electronic device returns the IBinder object (IBinder S1) to the distributed Binder management module of the second electronic device. The distributed Binder management module of the second electronic device determines the BinderId (BinderId S1) corresponding to the IBinder object (IBinder S1) according to the established mapping relationship between the IBinder object and the BinderId (see step 2.2.4 of Figure 6 ). Then, BinderId (BinderId S1) is sent to the communication module of the second electronic device (see step 2.2.5 of Figure 6 ).
[0175] The communication module of the second electronic device assembles a message (the message carries BinderId S1) after receiving the BinderId (BinderId S1) of the "DisApp" service, and sends the message to the communication module of the first electronic device.
[0176] The communication module of the first electronic device receives the message, that is, receives the BinderId of the target service carried in the message. Specifically, the communication module of the first electronic device receives the message and parses the information content to obtain the BinderId (BinderId S1) of the "DisApp" service. The communication module of the first electronic device sends the BinderId (BinderId S1) of the "DisApp" service to the distributed service management module of the first electronic device (see step 2.2.6 of Figure 6 ).
[0177] In an embodiment of the present application, the first electronic device will create a local IBinder object according to the received BinderId. Specifically, the distributed service management module of the first electronic device newly creates a corresponding local IBinder object (IBinder C1) according to the received BinderId S1 and establishes a mapping relationship with BinderId S1 (see step 2.2.7 of Figure 6 ). Figure 6
[0178] Then, after the first electronic device creates the local IBinder object, a unique identifier (set as the first identifier) is applied for the local IBinder object. And the identifier is associated with the module identifier 3. Specifically, the distributed Binder management module of the first electronic device sends a creation success instruction to the PC Binder SDK module of the first electronic device. After receiving the creation success instruction, the PC Binder SDK module of the first electronic device sends a request to the PC Binder management module of the first electronic device, which is used to request to apply a unique identifier (the first identifier) for IBinder C1 and associate the module identifier (moduleId3) of the service coordination module, that is, to create a mapping relationship between IBinder C1 and moduleId3 and store the mapping relationship (see step 2.2.7.1 of Figure 6 Binder C1 is created by the distributed Binder management module of the service coordination module, then the unique identifier of IBinder C1 is associated with the module identifier (moduleId3) of the service coordination module.
[0179] It should be noted that the first identifier applied for the newly created IBinder object locally and the Binder identifier (BinderId) obtained are different in function and meaning. If the first electronic device performs cross-device calling on the Android system, the first identifier applied for the newly created IBinder object locally is not needed.
[0180] The cross-process communication of the PC side needs to rely on the IPC message module, and the IPC message module can forward the calling message to the corresponding module according to the obtained module identifier.
[0181] It can be understood that in the process of sending IBinder C1 from the service coordination module to the distributed application plug-in, the distributed application plug-in actually obtains not the IBinder C1 object but the reference object of IBinder C1. Since the reference object of IBinder C1 needs to be sent to the distributed application plug-in, the first identifier corresponding to the reference object of IBinder C1 is associated with the module identifier of the distributed application plug-in. Therefore, the IPC communication module can send the reference object of IBinder C1 to the distributed application plug-in based on the module identifier of the distributed application plug-in.
[0182] In the embodiment of the application, the distributed application plug-in of the first electronic device is used to process service calling between distributed applications, so that the service calling message in the cross-device needs to be sent to the distributed application plug-in.
[0183] After the PC Binder management module of the first electronic device creates the mapping relationship between IBinder C1 and the module identifier 3, the PC Binder management module returns the newly created IBinder object to the note application 1 of the first electronic device. Specifically, the PC Binder management module of the first electronic device returns IBinder C1 to the PC Binder SDK module of the first electronic device. The PC Binder SDK module of the first electronic device returns IBinder C1 to the distributed Binder management module of the first electronic device (refer to step 2.2.7.3 of the method for creating a distributed application plug-in in the first electronic device). Figure 6
[0184] 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 step 2.2.8 of Figure 6 ).
[0185] The distributed service management module of the first electronic device returns the distributed context, i.e., the local IBinder object, the mapping relationship, etc., created in the above process, to the distributed application plug-in and the note application of the first electronic device (see step 2.3 of Figure 6 ).
[0186] 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 object itself, but a reference object of the object. In the process of creating the reference object, the unique identifier of the reference object needs to be associated with the module identifier of the module to be sent, so that the IPC communication module can send the reference object to the corresponding module based on the module identifier.
[0187] Thus, the distributed application plug-in of the first electronic device actually receives the first reference object of IBinder C1, and the note application of the first electronic device actually receives the reference object of the first reference object, i.e., 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 plug-in of the first electronic device, and the specific process is to create the first reference object of IBinder C1 in the PC Binder module, associate the first identifier of the first reference object with the module identifier of the distributed application plug-in, and forward the first reference object to the distributed application plug-in by the IPC communication module. The distributed application plug-in of the first electronic device returns IBinder C1 to the note application of the first electronic device, and the specific process is to create the second reference object of IBinder C1 in the PC Binder module, associate the first identifier of the second reference object with the module identifier of the note application, and forward the second reference object to the note application by the IPC communication module.
[0188] It can be understood that the IBinder object newly created by the first electronic device is created according to the BinderId carried in the received message, that is, the BinderId transmitted by the second electronic device to the first electronic device. The BinderId is invariable. Then, the first electronic device newly creates the corresponding IBinder object according to the BinderId. That is, in the first electronic device, the BinderId also has a mapping relationship with the new IBinder object.
[0189] That is, in the embodiment of the present application, in order to enable the first electronic device to call the second electronic device, a virtual IBinder object is created for the first electronic device, and then corresponds to the received BinderId.
[0190] It should be noted that since the IBinder object cannot be directly recognized on the Windows system, a unique first identifier needs to be applied for the locally created IBinder object and associated with the module identifier, so as to enable transmission between the modules of the first device. For example, if the IPC message module needs to forward the calling message related to the locally newly created IBinder object to the distributed application plug-in, the first identifier is associated with the module identifier of the distributed application plug-in. If the IPC message module needs to forward the calling message related to the locally newly created IBinder object to other modules, the first identifier is associated with the module identifier of the other modules.
[0191] In some embodiments of the present application, the first electronic device may be the first time to call the camera photographing service of the second electronic device, or there may be multiple calls. Therefore, after the first electronic device acquires the photographing service of the camera for the first time, the calling information of the acquired photographing service can be cached locally. Therefore, the first electronic device can first search the second electronic device and the distributed application management service from the local cache, and if found, directly return to the note application, and if not found, search from the second electronic device. For example, the application 1 of the computer 1 calls the scanning service of the mobile phone 1 once, and then the application 1 of the computer 1 can directly search the name of the mobile phone 1, the name of the distributed application management service, and the IBinder object, the first identifier, the module identifier and other information corresponding to the distributed application management service from the local cache of the computer 1 when the scanning service is called next time.
[0192] In some embodiments of the present application, if the target service is not found in the local cache, that is, the device name and the corresponding service name are not saved in the local cache. Then, the first electronic device can search for the corresponding target service in the second electronic device.
[0193] In some embodiments, after the first electronic device obtains the target service registered by the second electronic device, the first electronic device can make a service interface call of the second electronic device. That is, after the first electronic device obtains the service provided by the application of the second electronic device, the interface of the service is called through the IBinder object. When the client calls the service interface of the server, a service call request is sent to the server. After the server receives the request, the corresponding service interface is called, and a reply containing the call result is returned to the client.
[0194] In the request, there can be an anonymous IBinder object or no anonymous IBinder object. The anonymous IBinder object is an IBinder object that is not submitted to the distributed service management module for registration, and the anonymous IBinder object can call an anonymous service. When the client calls the service registered by the server, if a simple instruction is transmitted in the request, there is no further instruction (equivalent to that the request does not contain an anonymous IBinder object). If the returned result can be directly used, there is no further instruction (equivalent to that the reply does not contain an anonymous IBinder object). If the returned result cannot be directly used, the returned result needs to be further accessed or called (equivalent to that the reply contains an anonymous IBinder object).
[0195] For example, if the service provided by the second electronic device is a calculation service, taking a simple adder (a+b) as an example. For the application of the first electronic device, the input parameters are two numbers a and b, the interface of the service is called, and the result c can be directly obtained. The result c is a number and does not contain anything else. The above case is equivalent to that the request does not contain an IBinder object, and the reply does not contain an IBinder object.
[0196] 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.
[0197] 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.
[0198] 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.
[0199] 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:
[0200] like Figure 8 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 8 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 8 Step 1.1) of FIG. 1. The PC Binder SDK module sends the calling message to the PC Binder management module of the first electronic device, and obtains the unique identifier (Idl) corresponding to the IBinder Cl (see Figure 8 Step 1.2) of FIG. 1. The PC Binder management module of the first electronic device finds the corresponding module identifier (moduleId3) according to the unique identifier (see Figure 8 Step 1.3) of FIG. 1.
[0201] It can be understood that the IBinder Cl object is created in the distributed Binder management module, and the reference object of the IBinder Cl object is obtained in the distributed application plug-in. Therefore, the distributed application plug-in actually initiates the call based on the reference object of the IBinder Cl object. The distributed application plug-in sends the calling message to the distributed Binder management module, and then the reference object is used to find the IBinder Cl in the PC Binder management module, and the unique identifier of the IBinder Cl is determined. Then, the PC Binder management module finds the corresponding module identifier according to the association relationship of the unique identifier, that is, the module identifier (moduleId3) of the distributed Binder management module.
[0202] The PC Binder management module of the first electronic device can forward the calling message to the module corresponding to the moduleId3 through the IPC communication module of the first electronic device (see Figure 8 Step 1.4) of FIG. 1. Specifically, the distributed application plug-in initiates the call to the distributed Binder management module, that is, sends the calling message to the IPC communication module, and the calling message can contain the module identifier 3. The IPC communication module forwards the calling message to the corresponding distributed Binder management module based on the module identifier 3 after receiving the calling message. The above process is equivalent to that the distributed application plug-in of the first electronic device calls the onTransact method (see Figure 8 Step 1.5) of FIG. 1, and sends the calling message to the distributed Binder management module of the first electronic device.
[0203] The distributed Binder management module of the first electronic device sends the calling 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 forwards the calling message to the distributed Binder management module in the service coordination module of the second electronic device, and the distributed Binder management module of the second electronic device forwards the calling message to the system application framework of the second electronic device.
[0204] The system application framework of the second electronic device sends a start activity message to the camera application, and invokes a start activity method by a locally created IBinder S1 to start the camera. Then, the system application framework assembles the result data (the camera is opened) returned by the camera application into a result message, and sends the result message to the distributed Binder management module in the service collaboration module of the second electronic device.
[0205] The service collaboration module of the second electronic device sends the result message to the service collaboration module of the first electronic device. Specifically, the communication module of the second electronic device sends the result message to the communication module of the first electronic device. The communication module of the first electronic device forwards the result message to the distributed Binder management module in the service collaboration module of the first electronic device.
[0206] The distributed Binder management module of the first electronic device sends the result message to the distributed application plug-in module of the first electronic device. At this time, the camera is successfully opened.
[0207] In the embodiments of the present application, the messages transmitted between the above modules can be encapsulated in a parcel package, and each message can be transmitted by transmitting the parcel package in each module. For example, the above-mentioned calling message and result message can be encapsulated in a parcel package and transmitted between the modules of the first electronic device and the second electronic device.
[0208] 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 photo of the information needed to be returned to the note through the camera application. The camera application returns the obtained photo data to the note in response to the operation of the user. For example, the board content of the offline classroom is inserted in the note application. After the camera application is opened, the user uses the camera to take a photo of the board content. The camera obtains the board photo (the photo data of the board content) in response to the clicking operation of the user on the photo button. Then, the camera returns the board photo to the note.
[0209] The camera obtains the photo in response to the clicking operation of the user on the photo button, and then can confirm whether the photo meets the user's demand. The camera obtains the confirmed photo in response to the clicking operation of the user on the confirmation button, that is, after confirming that the photo meets the user's demand. The camera returns the confirmed photo to the note. That is to say, after the camera responds to the clicking operation of the user on the confirmation button, the camera returns the photo data to the note of the first electronic device.
[0210] Wherein, for the camera, after taking a photo, when the photo data needs to be returned to the note application, the file handle of the photo cache file of the note needs to be acquired first, and then the photo data is written back to the photo cache file of the client application. Since the file handle is a local resource of the first electronic device, it cannot be directly acquired. Therefore, the file handle can be hosted in a certain service (such as a Provider service), and the camera acquires the File Provider object of the note through the object, and then acquires the file handle through the object. It can be understood that the camera application sends a simple acquisition instruction (request) to the note application, and the result (reply) returned by the note application to the camera application is an object that needs to be further called. The above case is equivalent to that the request does not contain an anonymous IBinder object, and the reply contains an anonymous IBinder object.
[0211] Therefore, the specific steps of returning the service data (photo data) of the second electronic device to the first electronic device include: the camera application acquires the IContent Provider object (that is, the File Provider object) of the note application, the camera application acquires the file handle of the photo cache file of the note application, and the camera application writes the photo data back to the first electronic device. Wherein, the photo data is the result of the second electronic device executing the distributed application management service.
[0212] Wherein, the note application of the first electronic device can create a photo cache file (File Provider) with a uniform resource identifier (Uniform Resource Identifier, URI). Specifically, the photo cache file has a File Provider (equivalent to an IBinder object), and the note application registers the File Provider to the distributed application plug-in. Wherein, the note application can create the photo cache file in response to the touch operation of the user on the camera option, or can create the photo cache file at any time before acquiring the file handle of the photo cache file.
[0213] Please refer to Figure 9 , Figure 9 The timing diagram for acquiring the File Provider object of the note provided by the embodiments of the present application. As shown in Figure 9 , when the camera application uses IBinder S1 to call the interface corresponding to the note application, it enters the distributed Binder management module of the service cooperation module (refer to step 1.1 of Figure 9 ), and the input parameters in the interface call (by calling the transact method) can be encapsulated in a Parcel package (that is, a request parcel) (refer to Figure 9Step 1.2) of FIG. 1.
[0214] The distributed Binder management module of the service coordination module processes the request parcel (set as reqA) (see Figure 9 Step 1.3) of FIG. 1. Specifically, it is first determined whether the reqA contains an anonymous IBinder object. By analyzing the reqA, it is determined that the reqA does not contain an anonymous IBinder object. It can be understood that since the reqA is only used to obtain the File Provider object of the note, further calling is not required, and therefore the reqA does not contain an anonymous IBinder object. Then, the distributed Binder management module can directly serialize the reqA.
[0215] After the distributed Binder management module serializes the reqA, the calling request (reqA byte stream) is forwarded to the communication module of the second electronic device (see Figure 9 Step 1.4) of FIG. 1. 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 containing the BinderId S1 of the “DisApp” service (see Figure 9 Step 1.5) of FIG. 1.
[0216] The communication module of the first electronic device receives and analyzes the message, determines that the message carries a Binder calling request, and then sends the message to the distributed Binder management module of the first electronic device. The distributed Binder management module of the first electronic device analyzes the message to obtain the reqA byte stream (i.e., the serialized reqA), deserializes the reqA byte stream to obtain the reqA, and finds the corresponding local IBinder object (IBinder C1) according to the received BinderId S1 (see Figure 9 Step 1.5.1) of FIG. 1, and then calls the transact method based on the IBinder C1 to perform actual service calling (i.e., obtaining the File Provider object of the note) (see Figure 9 Step 1.5.2) of FIG. 1.
[0217] Specifically, the distributed Binder management module of the first electronic device sends a call message to the PC Binder SDK module of the first electronic device, and the call message contains the IBinder C1 object. The PC Binder SDK module of the first electronic device sends a request to the PC Binder management module of the first electronic device based on the received call message, to request the unique identifier (first identifier) corresponding to the IBinder C1 object (see step 1.5.3 of Figure 9 ). After the PC Binder management module of the first electronic device obtains the first identifier corresponding to the IBinder C1 object, it finds the associated module identifier (moduleId2) according to the first identifier (see step 1.5.4 of Figure 9 ), and then sends the module identifier 2 to the IPC communication module of the first electronic device. The IPC communication module of the first electronic device forwards the call message to the corresponding distributed application plug-in according to the module identifier 2 (see step 1.5.5 of Figure 9 ).
[0218] In the above process, since the distributed Binder management module sends the call message, the steps in the PC Binder module further include finding the reference object of the IBinder C1 object in the distributed application plug-in according to the IBinder C1 object in the call message sent by the distributed Binder management module. Further, according to the association relationship of the unique identifier of the reference object in the distributed application plug-in, the corresponding module identifier, that is, the module identifier 2 of the distributed application plug-in, is determined. The IPC communication module can forward the call message to the distributed application plug-in based on the module identifier 2.
[0219] The distributed application plug-in of the first electronic device obtains the File Provider object of the created note application (see step 1.5.6 of Figure 9 ), and 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 the unique identifier (first identifier) of the File Provider object and associate the module identifier (moduleId2) of the distributed application plug-in, that is, to create a mapping relationship between the File Provider and the moduleId2, and store the mapping relationship (see step 1.5.7 of Figure 9 ). After the File Provider is successfully associated with the moduleId2, the PC Binder SDK module sends a notification to the distributed application plug-in.
[0220] 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 9 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 9 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 9 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 9 Step 1.6.2).
[0221] 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.
[0222] 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.
[0223] In other words, the distributed Binder management module of the second electronic device processes the repB1 byte stream (see...). Figure 9 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 9of step 1.7.1) of the first electronic device. Thus, the second electronic device can obtain BinderId2 of the first electronic device, and then create an IBinder object (set as IFilePs) of the second electronic device, where BinderId2 and the IFilePs object of the second electronic device are in a mapping relationship. Then, the distributed Binder management module of the service coordination module of the second electronic device writes the created IFilePs object into a reply package (set as repB2), and returns to the camera application (refer to step 1.8 of Figure 9 ).
[0224] At this time, the second electronic device obtains the File Provider object of the note application. Then, the second electronic device can obtain the file handle of the photo cache file of the note through the File Provider object.
[0225] Please refer to Figure 9 , Figure 9 the timing diagram provided by the embodiment of the present application for obtaining the file handle of the photo cache file of the note. As shown in Figure 9 , when the camera application uses the IFilePs object to call the interface corresponding to the note application, the distributed Binder management module of the service coordination module is entered, and the input parameters in the interface call (through the transact method) can be encapsulated in a Parcel package (i.e., a request parcel) (refer to steps 1.1-1.2 of Figure 9 ).
[0226] The distributed Binder management module of the service coordination module processes the request parcel (set as reqD) reqD (refer to step 1.3 of Figure 10 ). Specifically, it is first determined whether the reqD contains an anonymous IBinder object. By analyzing the reqD, it can be determined that the reqD does not contain an anonymous IBinder object. It can be understood that since the reqD is only used to obtain the file handle of the note, it does not need to be further called, and it can be determined that the reqD does not contain an anonymous IBinder object. Then, the distributed Binder management module can directly serialize the reqD.
[0227] After the distributed Binder management module serializes the reqD, the call request (reqD byte stream) is forwarded to the communication module of the second electronic device (refer to step 1.4 of Figure 10 ). 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, where the message contains BinderId2.
[0228] 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 step 1.5 of FIG. 6). Figure 10 The distributed Binder management module of the first electronic device parses the message to obtain the serialized reqD (reqD byte stream), deserializes the reqD byte stream to obtain reqD, and finds the corresponding local IBinder object (IFilePc) according to BinderId2 (see step 1.5.1 of FIG. 6). Figure 10
[0229] Then, the distributed Binder management module of the first electronic device sends a call message to the PC Binder SDK module of the first electronic device, and the call message contains the IFilePc object. The PC Binder SDK module of the first electronic device requests the unique identifier (first identifier) corresponding to the IFilePc object based on the received call message. The PC Binder management module of the first electronic device requests the first identifier corresponding to the IFilePc object, finds the associated module identifier (moduleId2) according to the first identifier, and sends the module identifier 2 to the IPC communication module of the first electronic device. The IPC communication module of the first electronic device forwards the call message to the corresponding distributed application plug-in according to the received module identifier 2.
[0230] The distributed application plug-in of the first electronic device calls the transact method based on the IFilePc object to perform actual service calling (i.e., obtaining the file handle of the note) (see step 1.5.2 of FIG. 6). Figure 10 The distributed application plug-in of the first electronic device writes the File Descriptor object Fdc into the Parcel package, i.e., the Reply Parcel (set as repE) (see step 1.5.3 of FIG. 6), and returns the repE to the camera application of the second electronic device. Specifically, the note application calls onTransact (see step 1.6 of FIG. 6). Figure 10 The distributed Binder management module of the first electronic device processes the repE. Specifically, it checks that the repE contains the Fdc (equivalent to the IBinder object) (see step 1.6.1 of FIG. 6), and then sends a command to create a distributed file to the distributed file module of the first electronic device (see step 1.6.2 of FIG. 6). Figure 10 Figure 10 Figure 10 (Step 1.6.2). Let the name of the created distributed file be "DisPicture".
[0231] 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 10 , Figure 10 This is a schematic diagram illustrating the creation of a distributed file, as provided in an embodiment of this application. Figure 10 As shown, the distributed Binder management module sends a service binding instruction to the distributed application framework (see reference). Figure 10 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 11 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 11 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 11 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 11 Step 1.4).
[0232] 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.
[0233] 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 11 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.
[0234] 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.
[0235] 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 11 Step 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 11 (Step 1.6.4). Then, the distributed Binder management module serializes repE1.
[0236] 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 11 (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.
[0237] The communication module of the second electronic device receives the message and parses the message to obtain a message corresponding to repE1 (see step 1.7 of FIG. 1). Figure 11 The communication module of the second electronic device then sends the parsed message to the distributed Binder management module of the second electronic device for processing.
[0238] That is, the distributed Binder management module of the second electronic device processes the repE1 byte stream. Specifically, the distributed Binder management module of the second electronic device deserializes the repE1 byte stream to obtain the repE1 object (see step 1.7.1 of FIG. 1). Figure 10 The distributed Binder management module can detect that the repE1 contains the name of the distributed file, that is, the repE1 contains information about the corresponding file handle. The second electronic device can read the name of the distributed file ("DisPicture") in the repE1 and open the corresponding distributed file (see step 1.7.2 of FIG. 1). Figure 10
[0239] The distributed file module of the second electronic device then returns the file handle VFd of the distributed file to the distributed Binder management module of the second electronic device (see step 1.7.3 of FIG. 1). Figure 10 The distributed Binder management module writes the file handle VFd into a reply packet (set as repE2) and returns it to the camera application (see steps 1.7.4-1.8 of FIG. 1). Figure 10
[0240] At this time, the second electronic device obtains the file handle VFd of the note application. The camera application can then write the photographed data back to the first electronic device, that is, the camera application writes the photographed data into the distributed file of the second electronic device through the file handle, and then into the distributed file of the first electronic device, and finally returns to the note application of the first electronic device.
[0241] That is, a channel can be created between the distributed file module of the first electronic device and the distributed file module of the second electronic device. After the camera application calls the write data interface of the distributed file of the second electronic device through the file handle, the photographed data is written, and is transmitted to the distributed file of the first electronic device through the above-created channel, and then returned to the note.
[0242] 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.
[0243] Please see Figure 10 , Figure 10 A schematic diagram illustrating a cross-device PC Binder mechanism provided for the implementation of this application. (See diagram below.) Figure 10 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 12 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 coordination module on the server side stores the service name of the target service and its corresponding Binder identifier. Before the client obtains the service, each module performs IPC initialization, that is, assigns a corresponding module identifier (moduleId) to each module. The client's service coordination module obtains the name of the target service and its corresponding BinderId1 (see step 1) from the service coordination module on the server side. Figure 12 Step 2). The client's service collaboration module creates a local IBinder object (designated as IBinder2) based on Binder Id1, and applies for a unique identifier for IBinder2 in the PC Binder module, as well as establishes a mapping relationship between the unique identifier and module identifier 0.
[0244] The client's distributed application framework obtains the target service from the service coordination module (see reference). Figure 12 Step 2), and then when calling the target service (refer to...) Figure 12 Step 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.
[0245] The mapping relationship between the unique identifier of each IBinder object and the corresponding module identifier can be stored in the PC Binder module of the first electronic device. The IBinder object herein includes an entity object and a reference object. After the entity of the IBinder object is created in a certain module, the reference object of the IBinder object is obtained in the module in another process. That is, the corresponding reference object is created in the PC Binder module, and the unique identifier of the reference object is associated with the module identifier, and then the reference object can be forwarded to the module corresponding to the module identifier through the IPC communication component.
[0246] It should be noted that when the different modules (different processes) of the first electronic device communicate, the module identifier of the corresponding module needs to be obtained, so as to be forwarded to the corresponding module through the IPC communication component, that is, the communication between processes is realized.
[0247] The cross-device data processing method provided by the embodiments of the present application can apply for a unique identifier for an IBinder object newly created in the local end for calling a cross-end service in the PC Binder module constructed in the PC end and associate the corresponding module identifier, so as to realize that the Binder framework corresponding to the module identifier initiates a call to the service, realizes the Binder call of the PC end, and the application framework of the PC end builds the public calling capability of the distributed application, without the need for the application to be integrated with the kit and complete the customized development.
[0248] In some embodiments, the above cross-device data processing method can also be applied to the cross-device calling of other capabilities, such as a handwriting board, recording, scanning, etc., which need to be adapted to different scenarios in the cross-end service calling. For example, if a computer service is called, after the first electronic device obtains the distributed context of the service of the second electronic device, the first electronic device can directly initiate a call to the service of the second electronic device by the related application. It can be understood that in the above cross-device calling scenario, the communication between different processes is realized through the association of the module identifier and the unique identifier of the IBinder object, and the IPC communication component forwards to the corresponding module based on the module identifier.
[0249] In some embodiments, the cross-device service calling message can also be communicated in the same process, and then different module identifiers can be set for different modules in the same process for process communication. Alternatively, different modules can also be distinguished by other means, so that the calling message can be forwarded to different modules to realize cross-device service calling.
[0250] The embodiments of the present application also provide a chip system, such as Figure 12 Figure 12 Figure 12 Figure 13As shown, the chip system 90 includes at least one processor 901 and at least one interface circuit 902. The processor 901 and the interface circuit 902 can be interconnected via a line. For example, the interface circuit 902 can be used to receive a signal from another device (e.g., a memory of an electronic device). For another example, the interface circuit 902 can be used to send a signal to another device (e.g., the processor 901). Illustratively, the interface circuit 902 can read an instruction stored in a memory and send the instruction to the processor 901. When the instruction is executed by the processor 901, the electronic device can be caused to perform various steps in the above-described embodiments. Of course, the chip system can also include other discrete devices, which are not limited in the embodiments of the present application.
[0251] The embodiments of the present application further provide a computer storage medium, which includes computer instructions, when the computer instructions are run on the above-described electronic device, the electronic device is caused to perform various functions or steps performed by the mobile phone in the above-described method embodiments.
[0252] The embodiments of the present application further provide a computer program product, when the computer program product is run on a computer, the computer is caused to perform various functions or steps performed by the mobile phone in the above-described method embodiments.
[0253] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the convenience and brevity of description, only the above-described division of the functional modules is taken as an example for illustration, and in actual application, the above-described functions can be completed by different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above.
[0254] In several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only illustrative, for example, the division of the modules or units is only a logical function division, and actual implementation can have another division manner, for example, a plurality of units or components can be combined or integrated into another device, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the displayed or discussed ones can be indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.
[0255] The units described as separate components can or can not be physically separate, and the components shown as units can be one physical unit or multiple physical units, that is, can be located in one place, or can be distributed to multiple different places. Part or all of the units can be selected according to actual needs to achieve the purpose of the embodiments.
[0256] In addition, each function unit in each embodiment of the present application can be integrated in one processing unit, or each unit can be physically present separately, or two or more units can be integrated in one unit. The integrated unit can be realized in the form of hardware or in the form of a software function unit.
[0257] When the integrated unit is realized in the form of a software function 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 the present application essentially or the part that contributes to the prior art or the whole or part of the technical solutions can be embodied in the form of a software product. The software product is stored in a storage medium and includes a plurality of instructions for causing an apparatus (which can be a single-chip microcomputer, a chip, etc.) or a processor to execute all or part of the steps of the method described in each embodiment of the present application. The foregoing storage medium includes a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various media that can store program codes.
[0258] The above is only a specific embodiment of the present application, but the protection scope of the present application is not limited thereto. Any change or replacement within the technical scope disclosed in the present application should be covered in the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.
Claims
1. A cross-device data processing method applied to a first electronic device, comprising: The method comprises: The first electronic device obtains a first Binder identification ID from a second electronic device, and creates a second IBinder object based on the first Binder ID; wherein the first Binder ID is determined by the second electronic device according to a first IBinder object of a distributed application management service when the second electronic device registers the distributed application management service, and the first IBinder object and the second IBinder object are used to call the distributed application management service; The first electronic device determines a first identification based on the second IBinder object, and associates a target module identification based on the first identification, so that the first electronic device initiates a call to the distributed application management service based on a distributed application plug-in corresponding to the target module identification.
2. The data processing method across devices according to claim 1, wherein, Before the first electronic device obtains the first Binder identification ID from the second electronic device, the method further comprises: The first electronic device displays a display interface of a first application, and the display interface of the first application includes a plurality of device controls, each device control corresponding to a device that has established a preset wireless connection with the first electronic device, and each device control including one or more services provided by the corresponding device; The first electronic device receives a first touch operation of a user on a target device control in the plurality of device controls, and the first touch operation corresponds to the distributed application management service of the second electronic device.
3. The cross-device data processing method of claim 2, wherein, After the first electronic device determines the first identification based on the second IBinder object, and associates the target module identification based on the first identification, the method further comprises: The first electronic device, in response to receiving a first request from the second electronic device, finds a corresponding second IBinder object according to the first Binder ID contained in the first request; The first electronic device obtains a corresponding first identification based on the second IBinder object, and finds a corresponding target module identification based on the first identification, and obtains a first file providing object of the first application through a distributed application plug-in corresponding to the target module identification; The first electronic device determines a second identification based on the first file providing object, and associates the target module identification based on the second identification, and indicates the first file providing object of the first application to the second electronic device through a distributed application plug-in corresponding to the target module identification; wherein the first request is used to request to obtain the first file providing object, and the first request is sent by the second electronic device in response to a second touch operation of a user on a second application, the second touch operation is used to confirm a result of the second electronic device executing the distributed application management service on the second application, and the first file providing object is used to support the second electronic device to return a result of executing the distributed application management service to the first electronic device.
4. The data processing method across devices according to claim 3, wherein, After indicating the first file providing object of the first application to the second electronic device through the distributed application plug-in corresponding to the target module identification, the method further comprises: The first electronic device, in response to receiving a second request from the second electronic device, obtains a corresponding second identifier based on the first file providing object, and finds a corresponding target module identifier based on the second identifier, and indicates a first file handle object to the second electronic device through a distributed application plug-in corresponding to the target module identifier; wherein the second request is generated by the second electronic device based on the first file providing object, and is used to request to obtain the first file handle object for calling a preset cache file of the first application; The first electronic device receives a result returned by the second electronic device based on the first file handle object for executing the distributed application management service.
5. The data processing method across devices according to claim 4, wherein, The first electronic device, in response to receiving a second request from the second electronic device, obtains a corresponding second identifier based on the first file providing object, and finds a corresponding target module identifier based on the second identifier, and indicates the first file handle object to the second electronic device through a distributed application plug-in corresponding to the target module identifier, including: The first electronic device, in response to receiving a second request from the second electronic device, finds a corresponding first file providing object according to a second Binder ID contained in the second request; The first electronic device obtains a corresponding second identifier based on the first file providing object, and finds a corresponding target module identifier based on the second identifier, and obtains the first file handle object through a distributed application plug-in corresponding to the target module identifier, and creates a first distributed file based on the first file handle object; The first electronic device sends the name of the first distributed file to the second electronic device.
6. The cross-device data processing method of claim 5, wherein, The first electronic device, in response to receiving a second request from the second electronic device, finds a corresponding first file providing object according to a second Binder ID contained in the second request; The first electronic device obtains a corresponding second identifier based on the first file providing object, and finds a corresponding target module identifier based on the second identifier, and obtains the first file handle object through a distributed application plug-in corresponding to the target module identifier, and creates a first distributed file based on the first file handle object; The first electronic device obtains the first file handle object through the distributed application plug-in corresponding to the target module identifier; The distributed application plug-in sends a creation instruction of the first distributed file to the distributed Binder management module of the first electronic device based on the first file handle object; The distributed Binder management module sends an instruction of pulling up a distributed file service to the distributed file module of the first electronic device through the distributed application framework of the first electronic device; The distributed file module generates a third IBinder object corresponding to the distributed file service based on the instruction, and sends a fourth IBinder object corresponding to the third IBinder object to the distributed Binder management module through the distributed application framework; the fourth IBinder object is a reference object of the third IBinder object, and the third IBinder object and the fourth IBinder object are used to call the distributed file service; The distributed Binder management module acquires an interface for creating a distributed file provided by the distributed file service based on the fourth IBinder object, and determines a file module identifier corresponding to a distributed file module where the third IBinder object is located; The distributed Binder management module sends the creation instruction to the distributed file module corresponding to the file module identifier through an inter-process communication module of the first electronic device; The distributed file module calls the interface to create the first distributed file.
7. The data processing method across devices according to any one of claims 3-6, wherein, Before the first electronic device responds to the first request from the second electronic device, the method further includes: The first electronic device sends an opening instruction to the second electronic device, where the opening instruction is used to open a second application of the second electronic device.
8. The data processing method across devices according to any one of claims 1-6, wherein, Before the first electronic device acquires the first Binder identifier ID from the second electronic device, the method further includes: The first application, the distributed application plug-in, the service collaboration module, the Binder module and the distributed file module of the first electronic device respectively send initialization instructions to an inter-process communication module of the first electronic device; The inter-process communication module of the first electronic device respectively allocates corresponding module identifiers to the first application, the distributed application plug-in, the service collaboration module, the Binder module and the distributed file module of the first electronic device.
9. An electronic device, comprising: 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 processor are coupled; the memory is used to store computer program code, the computer program code includes computer instructions, when the computer instructions are executed by the electronic device, the electronic device executes the method as claimed in any one of claims 1-8.
10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores instructions, when the instructions run in the electronic device, the electronic device executes the method as claimed in any one of claims 1 to 8.
Citation Information
Patent Citations
Cross-device data processing method and electronic device
CN119922163A