A cross-device data processing method and electronic device

Abstract

This application provides a cross-device data processing method and an electronic device, relating to the field of electronic devices, and applied to a first electronic device. The method includes: the first electronic device calling a target service of a second electronic device; the first electronic device obtaining a first file handle object of a preset file, and creating a first distributed file based on the first file handle object; wherein the preset data is the result of the second electronic device executing the target service; the first electronic device sending the filename of the first distributed file to the second electronic device, so that the second electronic device opens the corresponding second distributed file based on the filename, the second distributed file being used to obtain the preset data; the first distributed file receiving the preset data transmitted by the second distributed file; and the first electronic device returning the preset data from the first distributed file to the preset file through the first file handle object. This solution can return the result of service execution to the caller, realizing cross-device service invocation.

Description

Technical Field

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

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

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

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

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

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

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

[0008] Firstly, a cross-device data processing method is provided, which can be applied to a first electronic device. The method includes: the first electronic device invoking a target service of a second electronic device; the first electronic device obtaining a first file handle object of a preset file, and creating a first distributed file based on the first file handle object; wherein the preset file is used to store preset data, which is the result of the second electronic device executing the target service; the first distributed file and a second distributed file in the second electronic device are used to support data access between the first and second electronic devices, and the first file handle object is used by the first electronic device to return the preset data from the first distributed file to the preset file.

[0009] The first electronic device sends the file name of the first distributed file to the second electronic device, so that the second electronic device opens the corresponding second distributed file based on the file name. The second distributed file is used to obtain preset data. The first electronic device receives the preset data transmitted by the second distributed file from the first electronic device. The first electronic device returns the preset data in the first distributed file to the preset file through the first file handle object.

[0010] This solution allows for the replacement of complex objects such as file handles before transmission, enabling both devices to access each other.

[0011] In one possible implementation, the first electronic device obtains a first file handle object of a preset file, including: the first electronic device receiving a first request from a second electronic device to obtain the first file handle object of the preset file; wherein, the first request is used by the second electronic device to request the first electronic device to obtain the first file handle object.

[0012] In one possible implementation, before the first electronic device sends the filename of the first distributed file to the second electronic device, the method further includes: the first electronic device generating a first transmission data packet based on a first file handle object; wherein the first transmission data packet contains the first file handle object; the first electronic device replacing the first file handle object in the first transmission data packet with the filename of the first distributed file to obtain a second transmission data packet;

[0013] In one possible implementation, the first electronic device sends the file name of the first distributed file to the second electronic device, which includes: the first electronic device sending a second transmission data packet to the second electronic device.

[0014] In one possible implementation, before the first electronic device sends the filename of the first distributed file to the second electronic device, the method further includes: the first electronic device generating a first transmission data packet based on a first file handle object; wherein the first transmission data packet contains the first file handle object; the first electronic device replacing the first file handle object in the first transmission data packet with the filename of the first distributed file and a preset placeholder to obtain a second transmission data packet; wherein the first file handle object is stored in the first byte of the first transmission data packet, and the filename and the preset placeholder are stored in the second byte of the second transmission data packet, the first byte and the second byte are of the same size, and the position of the first byte in the first transmission data packet corresponds to the position of the second byte in the second transmission data packet;

[0015] In one possible implementation, the first electronic device sends the file name of the first distributed file to the second electronic device, which includes: the first electronic device sending a second transmission data packet to the second electronic device.

[0016] In one possible implementation, the first electronic device sends a second transmission data packet to the second electronic device, including: the first electronic device serializing the second transmission data packet to obtain corresponding first serialized data; and the first electronic device sending the first serialized data to the second electronic device.

[0017] In one possible implementation, the first electronic device generates a first transmission data packet based on a first file handle object, including: a first application of the first electronic device generates the first transmission data packet based on the first file handle object.

[0018] In one possible implementation, after the first electronic device generates the first transmission data packet based on the first file handle object, the method further includes: the first application sending the first transmission data packet to the distributed Binder management module of the first electronic device; the distributed Binder management module receiving the first transmission data packet and sending a creation instruction for the first distributed file to the distributed file module of the first electronic device based on the first file handle object in the first transmission data packet; the distributed file module creating the first distributed file based on the creation instruction and sending a creation success instruction to the distributed Binder management module.

[0019] In one possible implementation, the first electronic device replaces the first file handle object in the first transmission data packet with the file name of the first distributed file to obtain the second transmission data packet, including: the distributed Binder management module, in response to a creation success instruction, replaces the first file handle object in the first transmission data packet with the file name of the first distributed file to obtain the second transmission data packet.

[0020] In one possible implementation, the first electronic device serializes the second transmission data packet to obtain corresponding first serialized data, including: the distributed Binder management module of the first electronic device serializes the second transmission data packet to obtain the first serialized data;

[0021] In one possible implementation, the first electronic device sends first serialized data to the second electronic device, including: the distributed Binder management module sends the first serialized data to the second electronic device through the communication module of the first electronic device.

[0022] Secondly, a cross-device data processing method is provided, applied to a second electronic device. The method includes: the second electronic device receiving a filename of a first distributed file from a first electronic device; wherein the first distributed file is created by the first electronic device based on a first file handle object of a preset file, and a second distributed file in the second electronic device is used to support data access between the first and second electronic devices; the preset file is used to store preset data, which is the result of the second electronic device performing a target service; the first file handle object is used by the first electronic device to return the preset data from the first distributed file to the preset file; the second electronic device opens the corresponding second distributed file based on the filename and obtains a second file handle object of the second distributed file; wherein the second file handle object is used by the second distributed file to obtain the preset data; the second distributed file of the second electronic device obtains the preset data through the second file handle object and transmits the preset data to the first distributed file of the first electronic device, so that the first electronic device returns the preset data from the first distributed file to the preset file through the first file handle object.

[0023] In one possible implementation, before the first electronic device obtains the first file handle object of the preset file, the method further includes: the second electronic device sending a first request to the first electronic device; wherein the first request is used by the second electronic device to request the first electronic device to obtain the first file handle object of the preset file.

[0024] In one possible implementation, the second electronic device receives the file name of a first distributed file from the first electronic device, including: the second electronic device receiving a second transmission data packet sent by the first electronic device; wherein the second transmission data packet is obtained by the first electronic device replacing the first file handle object in the first transmission data packet with the file name, and the first transmission data packet is generated by the first electronic device based on the first file handle object.

[0025] In one possible implementation, the second electronic device receives a second transmission data packet sent by the first electronic device, including: the second electronic device receiving first serialized data sent by the first electronic device and performing deserialization processing on the first serialized data to obtain the corresponding second transmission data packet; wherein, the first serialized data is obtained by the first electronic device performing serialization processing on the second transmission data packet.

[0026] In one possible implementation, the second electronic device opens the corresponding second distributed file based on the file name and obtains the second file handle object of the second distributed file, including: the second electronic device opens the corresponding second distributed file based on the file name in the second transmission data packet and obtains the second file handle object of the second distributed file.

[0027] In one possible implementation, after the second electronic device opens the corresponding second distributed file based on the file name and obtains the second file handle object of the second distributed file, the method further includes: the second electronic device replaces the file name in the second transmission data packet with the second file handle object to obtain the third transmission data packet.

[0028] In one possible implementation, the second electronic device receives first serialized data sent by the first electronic device and performs deserialization processing on the first serialized data to obtain a corresponding second transmission data packet. This includes: the distributed Binder management module of the second electronic device receiving the first serialized data sent by the first electronic device through the communication module of the second electronic device; and the distributed Binder management module performing deserialization processing on the first serialized data to obtain the corresponding second transmission data packet.

[0029] In one possible implementation, the second electronic device opens the corresponding second distributed file based on the file name in the second transmission data packet and obtains the second file handle object of the second distributed file, including: the distributed Binder management module of the second electronic device sending an open command to the distributed file module of the second electronic device based on the file name; wherein the open command contains the file name; the distributed file module responds to the open command, opens the second distributed file corresponding to the file name, and sends the second file handle object of the second distributed file to the distributed Binder management module.

[0030] In one possible implementation, the second electronic device replaces the file name in the second transmission data packet with a second file handle object to obtain a third transmission data packet, including: the distributed Binder management module of the second electronic device replaces the file name in the second transmission data packet with a second file handle object to obtain a third transmission data packet.

[0031] In one possible implementation, after the second electronic device replaces the file name in the second transmission data packet with a second file handle object to obtain the third transmission data packet, the method further includes: the distributed Binder management module sending the third transmission data packet to the second application of the second electronic device.

[0032] In one possible implementation, the second distributed file of the second electronic device obtains preset data through the second file handle object and transmits the preset data to the first distributed file of the first electronic device, including: the second application returns the obtained preset data to the second distributed file through the second file handle object in the third transmission data packet; the second distributed file transmits the preset data to the first distributed file of the first electronic device.

[0033] In summary, this solution enables cross-device transmission of Parcel packets (transmission data packets). If the Parcel packet contains a file handle object, it replaces the file handle object with the name of the corresponding distributed file before serialization and transmission. In other words, the local resource (file handle object) is replaced with the cross-device resource (distributed file name) before serialization and transmission. Upon receiving the serialized Parcel packet at the other end, it is first deserialized to obtain the name of the distributed file. Then, the corresponding distributed file is opened based on the name, and the file handle object corresponding to the locally created distributed file is obtained. Thus, cross-device transmission of Parcel packets containing file handle objects can be achieved.

[0034] For example, during the process of the camera application of the second electronic device obtaining the file handle of the photo cache file of the notes application of the first electronic device, the first electronic device creates a corresponding first distributed file for the file handle object. Before serialization, the first electronic device can replace the file handle object in data packet 1 (parcel packet) with the name of the corresponding first distributed file to obtain data packet 2. Then, data packet 2 is serialized to obtain serialized data (parcel byte stream), which is then transmitted to the second electronic device over the network.

[0035] After receiving the serialized data (parcel byte stream), the second electronic device deserializes it to obtain data packet 2. The second electronic device parses data packet 2 to obtain the name of the distributed file. Then, it opens the corresponding second distributed file based on the name and obtains its file handle object. The photo data acquired by the camera application is written to the second distributed file through this file handle object, and the second distributed file transmits the photo data to the first distributed file. The first distributed file then returns the photo data to the photo cache file. This achieves cross-device transmission of Parcel packets containing file handles, enabling cross-device return of service results.

[0036] The above-described cross-device service transmission method can be applied to cross-device service invocation methods.

[0037] Optionally, a cross-device service invocation method can also be provided, which can be applied to a first electronic device. The method includes: the first electronic device displaying a display interface of a first application, the display interface of the first application including multiple 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 receiving a first touch operation from a user on a target device control among the multiple device controls, the first touch operation corresponding to a distributed application management service of a second electronic device; the first electronic device obtaining a first Binder identifier ID corresponding to the distributed application management service from the 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 the distributed application management service based on the first IBinder object of the distributed application management service, and the first IBinder object and the second IBinder object are used to invoke the distributed application management service.

[0038] In response to receiving a first request from a second electronic device, the first electronic device looks up the corresponding second IBinder object based on the first Binder ID contained in the first request, and instructs the second electronic device on the first file provision object of the first application based on the second IBinder object; wherein, the first request is used to request the first file provision object, the first request is sent by the second electronic device in response to a second touch operation of the user on the second application, the second touch operation is used to confirm the result of the second electronic device performing distributed application management service on the second application, and the first file provision object is used to support the second electronic device to return the result of performing distributed application management service to the first electronic device;

[0039] In response to receiving a second request from a second electronic device, the first electronic device indicates a first file handle object to the second electronic device based on a first file providing object; wherein, the second request is generated by the second electronic device based on the first file providing object, and is used to request the first file handle object for obtaining a preset cache file for calling 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.

[0040] By adopting this technical solution, users can send shooting commands from a first electronic device to a second electronic device. Upon receiving the shooting command, the second electronic device activates its camera to perform a photo or scan task. After completion, the shooting result or the scanned text is directly sent back to the first electronic device. This eliminates the need for users to upload the shooting result or scanned text to the second electronic device, download and save it there, and then upload it to the corresponding location on the second electronic device. The operation is simpler and improves user efficiency.

[0041] Optionally, a cross-device service invocation method can also be provided, applied to a second electronic device. This method includes: the second electronic device responding to a second touch operation by a user on a second application of the second electronic device, sending a first request to the first electronic device based on a first Binder ID of a distributed application management service; wherein the first request is used to request a first file provider object of the first application of the first electronic device, the first Binder ID being determined by the second electronic device when registering the distributed application management service based on a first IBinder object of the distributed application management service, the first IBinder object being used to invoke the distributed application management service, the second touch operation being used to confirm the result of the second electronic device executing the distributed application management service on the second application, and the first file provider object being used to support the second electronic device returning the result of executing the distributed application management service to the first electronic device; the second electronic device receiving the first file provider object indicated by the first electronic device, and sending a second request to the first electronic device based on the first file provider object; wherein the second request is used to request a first file handle object for invoking a preset cached file of the first application; the second electronic device receiving the first file handle object indicated by the first electronic device, and returning the result of executing the distributed application management service to the first electronic device based on the first file handle object.

[0042] Optionally, a cross-device service invocation method can also be provided, applied to a first electronic device. The method includes: the first electronic device displaying a display interface of a first application, the display interface of the first application including multiple 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 receiving a first touch operation from a user on a target device control among the multiple device controls, the first touch operation corresponding to a target service of a second electronic device; the first electronic device obtaining a first Binder identifier ID corresponding to the target service from the second electronic device, and creating a second IBinder object based on the first Binder identifier ID; wherein the first Binder identifier ID is determined by the second electronic device based on the first IBinder object of the target service when registering the target service, and the first IBinder object and the second IBinder object are used to invoke the target service; the first electronic device sending an invocation request to the second electronic device based on the second IBinder object; wherein the invocation request includes the first Binder identifier ID of the second IBinder object, and the invocation request is used to request the invocation of the target service of the second application in the second electronic device; and the first electronic device receiving an invocation response from the second electronic device, the invocation response including the result of the first electronic device invoking the target service.

[0043] By adopting this technical solution, after the first electronic device receives the BinderId of the IBinder object corresponding to the service of the second electronic device, it can create an IBinder object on its own end corresponding to the BinderId, and then call the service of the second electronic device through the IBinder object on its own end, thereby realizing cross-device service calls.

[0044] Optionally, another cross-device service invocation method can also be provided, applied to a second electronic device, the method comprising: the second electronic device receiving an invocation request from a first electronic device; wherein the invocation request includes a first Binder identifier ID of a second IBinder object, the invocation request being used to request invocation of a target service of a second application in the second electronic device; in response to the invocation request, the second electronic device searching for a first IBinder object created for the target service when the second electronic device registered the target service based on the first Binder ID of the second IBinder object; the second electronic device invoking the target service based on the first IBinder object, and sending back an invocation response to the first electronic device, the invocation response including the result of invoking the target service.

[0045] Optionally, a cross-device data processing method can also be provided, which can be applied to a first electronic device. The method includes: the first electronic device acquiring a first IBinder object and creating a corresponding Binder identifier ID based on the first IBinder object; wherein the first IBinder object is used to invoke a target service of the first electronic device; the first electronic device sends a Binder ID to a second electronic device, so that the second electronic device creates a corresponding second IBinder object based on the Binder ID, and the second IBinder object is used by the second electronic device to invoke the target service.

[0046] This solution allows for the replacement of complex objects like Binder objects within the parcel package before serialization, enabling communication between the two devices.

[0047] The aforementioned cross-device service call methods also involve another type of cross-device data transfer that includes a binder object.

[0048] Optionally, another cross-device data processing method can also be provided, applied to a second electronic device, the method comprising: the second electronic device receiving a Binder identifier ID sent by the first electronic device; wherein the Binder ID is created by the first electronic device based on a first IBinder object, the first IBinder object being obtained by the first electronic device and used to call the target service of the first electronic device; the second electronic device creating a corresponding second IBinder object based on the Binder ID; wherein the second IBinder object is used to call the target service.

[0049] In summary, in scenarios where Parcel packets can be transferred across devices, if the Parcel packet contains a Binder object, the Binder object can be replaced with the corresponding BinderId before serialization and transmission. That is, the local resource (Binder object) is replaced with the cross-device resource (BinderId) before serialization and transmission. Upon receiving the serialized Parcel packet at the other end, it is first deserialized to obtain the BinderId, and then replaced with the locally created Binder object. This allows for the cross-device transmission of Parcel packets containing Binder objects.

[0050] For example, during the process of the camera application of the second electronic device acquiring the FileProvider object of the note-taking application of the first electronic device, the first electronic device assigns a corresponding BinderId to the File Provider object (IFile Pc object). Before serialization, the first electronic device can replace the IFilePc object in data packet 1 (parcel packet) with the corresponding BinderId to obtain data packet 2. Then, it performs serialization processing on data packet 2 to obtain serialized data (parcel byte stream), and then transmits it to the second electronic device over the network.

[0051] After receiving the serialized data (parcel byte stream), the second electronic device deserializes it to obtain data packet 2. The second electronic device then parses data packet 2 to obtain the BinderId. Next, it locally creates an IFile Ps object corresponding to the BinderId and writes the IFile Ps object into data packet 2, resulting in data packet 3. This achieves cross-device transmission of a Parcel packet containing a Binder object (File Provider object).

[0052] During a call from a client (first electronic device) to a service on a server (second electronic device), the server application may exit. This could be due to an exception causing the server application to exit, or it could exit normally in response to a user action. Both situations indicate an exception in the server application. In these cases, both the client and server applications need to clean up their local storage resources to prevent resource redundancy.

[0053] Optionally, a resource cleanup method can also be provided, which can be applied to a first electronic device. The method includes: the first electronic device registering a cleanup service for a target service of a second electronic device; wherein the cleanup service is used to trigger the first electronic device to clean up the target service and the cleanup service's invocation resources; the invocation resources include resources used by the first electronic device when invoking the corresponding service; the first electronic device sending a cleanup service registration instruction to the second electronic device based on a first IBinder object of the cleanup service; wherein the registration instruction is used to instruct the second electronic device to register the cleanup service for the target service; and the first electronic device, in response to receiving a first cleanup invocation request from the second electronic device, executing the cleanup service based on the first IBinder object; wherein the first cleanup request is sent by the second electronic device in response to the exit of the target service.

[0054] With this solution, the first electronic device can receive the service exit message from the second electronic device in a timely manner, and can promptly clean up the stored resources to avoid resource redundancy within the first electronic device.

[0055] In one possible implementation, before the first electronic device registers and cleans up the target service of the second electronic device, the method further includes: the first electronic device displaying the display interface of a first application, the display interface of the first application including multiple device controls, each device control corresponding to a device that has established a preset wireless connection with the first electronic device, each device control including one or more services provided by the corresponding device; the first electronic device receiving a first touch operation from a user on a target device control among the multiple device controls, the first touch operation corresponding to the target service of the second electronic device;

[0056] In response to the first touch operation, the first electronic device obtains the first Binder identifier ID corresponding to the target service from the 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 based on the third IBinder object of the target service when registering the target service, and the second IBinder object and the third IBinder object are used to call the target service.

[0057] In one possible implementation, the first electronic device sends a registration instruction for the cleanup service to the second electronic device based on the first IBinder object of the cleanup service, including: the first electronic device obtaining the first IBinder object of the cleanup service based on the second IBinder object; the first electronic device creating a corresponding second Binder ID based on the first IBinder object and sending the second Binder ID to the second electronic device; wherein the registration instruction for the first cleanup service includes the second Binder ID.

[0058] In one possible implementation, the first electronic device, in response to receiving a first cleanup call request from the second electronic device, performs a cleanup service based on a first IBinder object, including: the first electronic device, in response to receiving the first cleanup call request, searches for the corresponding first IBinder object according to the second Binder ID contained in the first cleanup call request; and the first electronic device performs a cleanup service based on the first IBinder object.

[0059] In one possible implementation, before the first electronic device responds to receiving a first cleanup request from the second electronic device, the method further includes: the first electronic device receiving a registration message from the second electronic device; wherein the registration message is used to instruct the second electronic device to complete the registration for the cleanup service.

[0060] In one possible implementation, the invoked resources include the service name of the target service, the second IBinder object, the first Binder ID, and the first IBinder object and second Binder ID of the cleanup service.

[0061] In one possible implementation, the first electronic device obtains the first IBinder object of the cleaning service based on the second IBinder object, including: the first application of the first electronic device obtains the first IBinder object of the cleaning service based on the second IBinder object;

[0062] In one possible implementation, the first electronic device creates a corresponding second BinderID based on the first IBinder object and sends the second Binder ID to the second electronic device, including: the first application sending the first IBinder object to the distributed Binder management module of the first electronic device; the distributed Binder management module creating a corresponding second Binder ID based on the first IBinder object and sending the second Binder ID to the second electronic device through the communication module of the first electronic device.

[0063] In one possible implementation, the first electronic device responds to receiving a first cleanup call request by searching for the corresponding first IBinder object based on the second Binder ID contained in the first cleanup call request, including: the distributed Binder management module of the first electronic device receives the first cleanup call request through the communication module of the first electronic device and searches for the corresponding first IBinder object based on the second Binder ID contained in the first cleanup call request;

[0064] In one possible implementation, the first electronic device performs a cleanup service based on the first IBinder object, including: a distributed Binder management module calling the cleanup service based on the first IBinder object to clean up the call resources of the target service stored in the distributed Binder management module; the distributed Binder management module sending a cleanup notification to the first application; and the first application responding to the cleanup notification by cleaning up the target service and the call resources of the cleanup service stored in the first application.

[0065] Optionally, another resource cleanup method can also be provided, applied to a second electronic device, the method comprising: the second electronic device receiving a registration instruction from a first electronic device; wherein the registration instruction is used to instruct the second electronic device to register a cleanup service for a target service; the cleanup service is used to trigger the second electronic device to clean up the target service and the call resources of the cleanup service; the call resources include the resources used by the first electronic device when calling the corresponding service; the second electronic device obtaining a fourth IBinder object of the cleanup service; and the second electronic device performing the cleanup service based on the fourth IBinder object in response to the exit of the target service.

[0066] In one possible implementation, the method further includes: a second electronic device responding to the exit of the target service by sending a first cleanup call request to the first electronic device based on a fourth IBinder object; wherein the first cleanup call request is used to instruct the first electronic device to clean up the target service and the call resources of the cleanup service.

[0067] It is understandable that after cleaning up the resources called by the target service, the second electronic device can then clean up the resources called by the cleanup service. In summary, both the first and second electronic devices can clean up locally stored resources to avoid resource redundancy.

[0068] Thirdly, this application provides an electronic device, the electronic device comprising: a communication module, a display screen, a memory, and one or more processors; the communication module, the display screen, the memory, and the processor are coupled; the memory is used to store computer program code, the computer program code including computer instructions, which, when executed by the electronic device, cause the electronic device to perform the methods described in the first to second aspects above.

[0069] Fourthly, this application provides a computer-readable storage medium storing instructions that, when executed on a computer, enable the computer to perform the methods described in any one of the first to second aspects.

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

[0071] In a sixth aspect, this application provides a computer program product containing instructions that, when run on a computer, enable the computer to perform the methods described in any one of the first to second aspects above.

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

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

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

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

[0076] Figure 4 A timing diagram illustrating the registration and acquisition services provided in this application embodiment;

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

[0078] Figure 6A schematic diagram showing the interface of another note-taking application provided in an embodiment of this application;

[0079] Figure 7 A schematic diagram showing the interface of another note-taking application provided in an embodiment of this application;

[0080] Figure 8 A timing diagram for invoking a service interface provided in an embodiment of this application;

[0081] Figure 9 A schematic diagram illustrating a cross-device service invocation method provided in an embodiment of this application;

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

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

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

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

[0086] Figure 14 A schematic diagram illustrating a cross-device invocation scenario provided in an embodiment of this application;

[0087] Figure 15 This is a schematic diagram of a parcel data structure provided in an embodiment of this application;

[0088] Figure 16 A schematic diagram illustrating a cross-device data transmission method provided in an embodiment of this application;

[0089] Figure 17 A schematic diagram illustrating another cross-device data transmission method provided in an embodiment of this application;

[0090] Figure 18 A schematic diagram illustrating another cross-device data transmission method provided in an embodiment of this application;

[0091] Figure 19 A schematic diagram illustrating another cross-device data transmission method provided in an embodiment of this application;

[0092] Figure 20 A flowchart illustrating another cross-device data transmission method provided in this application embodiment;

[0093] Figure 21 A flowchart illustrating a cross-device resource cleanup method provided in this application embodiment;

[0094] Figure 22 A timing diagram of a cross-device service call resource cleanup method provided in an embodiment of this application;

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

[0096] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0097] The terms "first," "second," etc., used below are for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with "first," "second," etc., may explicitly or implicitly include one or more of that feature. In the description of this embodiment, unless otherwise stated, "multiple" means two or more. The character " / " in this application generally indicates that the preceding and following objects are in an "or" relationship. For example, A / B can be understood as A or B.

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

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

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

[0101] (1) Binder: From Android TMAt the application layer, Binder is the medium for communication between the client and the server. The server returns a Binder object containing the server's business logic calls. Through this Binder object, the client can obtain the services or data provided by the server.

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

[0103] (2) Parcel: A parcel is a container for messages and uses the Binder mechanism for data transmission. It can carry serialized data, transmit it via IPC, and then deserialize it at the destination. A parcel can also pass an IBinder object, which will be received as a proxy at the destination.

[0104] 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.

[0105] 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.

[0106] 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.

[0107] Therefore, this application provides a cross-device service invocation method, allowing users to send shooting commands from a first electronic device (such as a tablet or personal computer) to a second electronic device (such as a mobile phone). Upon receiving the shooting command, the mobile phone activates its camera to perform a photo or scan task, and then directly sends the shooting results or scanned text back to the tablet or personal computer.

[0108] 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.

[0109] 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.

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

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

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

[0113] The embodiments of this application will now be described in detail with reference to the accompanying drawings. Taking a mobile phone as an example, the hardware structure of the electronic device (such as electronic device 300) will be described. Figure 2 The electronic device 300 shown is merely an example of an electronic device, and the electronic device 300 may have more or fewer components than those shown in the figure, may combine two or more components, or may have different component configurations. Figure 2 The various components shown can be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and / or application-specific integrated circuits.

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

[0115] The aforementioned sensor module 380 may include sensors such as pressure sensors, gyroscope sensors, barometric pressure sensors, magnetic sensors, accelerometers, distance sensors, proximity sensors, fingerprint sensors, temperature sensors, touch sensors, ambient light sensors, and bone conduction sensors.

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

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

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

[0119] The processor 310 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 310 is a cache memory. This memory can store instructions or data that the processor 310 has just used or that are used repeatedly. If the processor 310 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 310, and thus improves the efficiency of the system.

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

[0121] It is understood that the interface connection relationships between the modules illustrated in this embodiment are merely illustrative and do not constitute a structural limitation on the electronic device 300. In other embodiments, the electronic device 300 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

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

[0123] The power management module 341 connects the battery 342, the charging management module 340, and the processor 310. The power management module 341 receives input from the battery 342 and / or the charging management module 340, providing power to the processor 310, internal memory 321, external memory, display screen 394, camera 393, and wireless communication module 360. The power management module 341 can also monitor parameters such as battery capacity, battery cycle count, and battery health status (leakage current, impedance). In some other embodiments, the power management module 341 may also be located within the processor 310. In other embodiments, the power management module 341 and the charging management module 340 may be housed in the same device.

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

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

[0126] The mobile communication module 350 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied to the electronic device 300. The mobile communication module 350 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 350 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation.

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

[0128] The wireless communication module 360 ​​can provide solutions for wireless communication applications on the electronic device 300, including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. For example, in this embodiment, the electronic device 300 can access a Wi-Fi network through the wireless communication module 360.

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

[0130] In some embodiments, antenna 1 of electronic device 300 is coupled to mobile communication module 350, and antenna 2 is coupled to wireless communication module 360, enabling electronic device 300 to communicate with networks and other devices via wireless communication technology. The wireless communication technology may include Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Time Division Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technologies, etc. The GNSS may include the Global Positioning System (GPS), the Global Navigation Satellite System (GLONASS), the BeiDou Navigation Satellite System (BDS), the Quasi-Zenith Satellite System (QZSS), and / or satellite-based augmentation systems (SBAS).

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

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

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

[0134] The external storage interface 320 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 300. The external memory card communicates with the processor 310 through the external storage interface 320 to perform data storage functions. For example, music, video, and other files can be saved on the external memory card.

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

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

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

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

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

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

[0141] although Figure 2 As not shown, electronic device 300 may also include a flash, a miniature projection device, a near field communication (NFC) device, etc., which will not be described in detail here.

[0142] After describing the hardware structure of the electronic device, the system architecture of the electronic device provided in this application will be described. The system architecture of the electronic device can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This embodiment of the invention uses a layered architecture system as an example to illustrate the software structure of the electronic device.

[0143] A layered architecture divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the system is divided into five layers, from top to bottom: the application layer, the system application framework layer, the coordination service and scheduling layer, the communication module and device profile layer, and the kernel layer.

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

[0145] like Figure 3As shown, the system application framework layer may include ActivityManagerService (AMS), DistributedActivityManagerService (DAMS), PackageManagerService (PMS), DistributedPackageManagerService (DPMS), Service Manager (SM), DistributedService Manager (DSM), and the system Binder framework. AMS, PMS, and SM are existing system services in the Android system, and their functions are not described in detail here. DAMS, DPMS, and DSM are new system functions added to the distributed system in this embodiment of the application; together, they form the distributed application framework, used to handle service calls between distributed applications in this application.

[0146] Among them, the distributed application framework can provide a distributed application management service, which is used to register with the distributed service management module to realize service calls and management between distributed applications.

[0147] like Figure 3 As shown, the Collaboration Service and Scheduling Layer provides management capabilities for remote services, including remote service registration and acquisition. It is responsible for forwarding service calls between devices, converting local resource references (anonymous Binder objects, file descriptors, etc.) into inter-device resource references. This Collaboration Service and Scheduling Layer may include a distributed service management module, a distributed Binder management module, a distributed file management module, a transmission management module, and a device management module.

[0148] The distributed service management module includes a service registration module, a service management module, a service acquisition module, and a service lifecycle module. The service management module is used to manage multiple remote devices when they exist.

[0149] The service registration module is used to register the target service before device 1 calls the target service of device 2.

[0150] The service acquisition module is used to acquire the target service of device 2 after device 2 has completed its registration when device 1 calls the target service of device 2.

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

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

[0153] The distributed Binder management module includes a Binder management mapping module, a Binder access authentication module, and a Binder lifecycle module.

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

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

[0156] The Binder access authentication module is used to manage distributed Binder access authentication capabilities in cross-device or distributed scenarios.

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

[0158] The distributed file management module primarily refers to scenarios like taking photos. For example, when a PC needs to access a phone's camera, the actual photo cache file is created by the PC. Then, after taking a photo, the phone needs to obtain the file handle of the photo cache file from the PC. After obtaining the file handle, it needs to perform write operations on this photo cache file. This involves cross-device read and write operations. The distributed file management module can provide cross-device file access.

[0159] The file handle is a relatively complex object, similar to a Binder object.

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

[0161] The device management module refers to the connected devices. Devices may be brought online or taken offline. Taking a device offline means it has been connected and then taken offline, meaning it will no longer be connected. In this case, all resources related to that device need to be cleaned up or other operations performed. One or more devices may be connected.

[0162] like Figure 3 As shown, the communication module and device profile layer include a communication module, a device profile module, and a distributed file module.

[0163] The communication module is responsible for transmission, including device discovery and connection services and data transmission services. It provides cross-device transmission interfaces and supports automatic networking within the trust ring, one-to-many connections, and wake-up of dormant devices. In cross-device scenarios, devices transmit information through the communication module.

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

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

[0166] The kernel layer includes the Binder driver module, which is mainly used for cross-device communication.

[0167] The methods described in the following embodiments can all be implemented in electronic devices having the above-described hardware structure and system architecture.

[0168] In this embodiment, a first electronic device is taken as the client (master device), and a second electronic device is taken as the server (auxiliary device). The first electronic device can call the services of the second electronic device. The first electronic device can be a personal computer, tablet, mobile phone, etc., and the second electronic device can be a tablet, mobile phone, etc. The server refers to the end that provides the service, and the client refers to the end that wants to use the service provided by the server.

[0169] In a scenario where the first electronic device invokes a target service from the second electronic device, the second electronic device first registers the target service within its own device, and then the first electronic device retrieves the registered target service. After successfully retrieving the target service from the second electronic device, the first electronic device can then invoke the service interface of the second electronic device.

[0170] Therefore, in this embodiment of the application, the overall process of the cross-device service invocation method is mainly divided into three parts: service registration of the second electronic device, obtaining the service of the second electronic device from the first electronic device, and invoking the service interface of the second electronic device from the first electronic device.

[0171] First, the service registration process for the second electronic device will be introduced.

[0172] Taking a distributed application management service as an example, where the target service registered by the second electronic device is a distributed application management service, this service (target service) is within the system application framework. When the electronic device powers on, the system application framework starts, which in turn starts the distributed application management service. After the electronic device powers on, the communication module starts. Following the communication module, the service collaboration module starts. Therefore, after the service collaboration module starts, the second electronic device can register the distributed application management service with the service collaboration module.

[0173] like Figure 4 As shown, the service registration process of the second electronic device includes: the target service of the second electronic device is registered to the distributed service management module (DistributedServiceManager) of the service collaboration module of the second electronic device; the service name (ServiceName) and IBinder object of the target service are stored in the distributed service management module; and a BinderId is assigned to the IBinder object.

[0174] The service name and IBinder are parameters; an IBinder object can invoke a target service. After the first electronic device obtains the IBinder object of the target service from the second electronic device, it can use the IBinder object to invoke the corresponding target service's interface, that is, to invoke the capabilities provided by the target service.

[0175] Each service has a corresponding service name, such as AMS service, camera service, audio service, etc. The service name is registered with the system's service management module. In a distributed service scenario, the service name can also be registered with the distributed service management module.

[0176] For example, a camera service is a system service, and its service name can be camera, or camera1, camera2, etc. As a service provider, the camera service has a corresponding IBinder object. The camera service may provide multiple interfaces, with different capabilities corresponding to different interfaces. For example, the interfaces provided by the camera service may include opening the camera, taking a picture, and recording video. Then, these interfaces can be directly called through the corresponding IBinder object.

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

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

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

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

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

[0182] The storage method can be a list, as shown in Table 1:

[0183] Service Name IBinder object BinderId Service S1 IBinder S1 BinderId S1 Service S2 IBinder S2 BinderId S2

[0184] Table 1

[0185] Alternatively, the data can be stored in two lists: one list containing the service name and the IBinder object, and another list containing the IBinder object and the BinderId. These three elements correspond one-to-one, as shown in Tables 2a and 2b.

[0186] Service Name IBinder object Service S1 IBinder S1 Service S2 IBinder S2

[0187] Table 2a

[0188] IBinder object BinderId IBinder S1 BinderId S1 IBinder S2 BinderId S2

[0189] Table 2b

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

[0191] Secondly, the process of the first electronic device acquiring the target service registered by the second electronic device is described. Specifically, after the second electronic device successfully registers the target service, the first electronic device can acquire it. It can be understood that before acquiring the target service, the first electronic device has already opened the application and responded to a user's action on the application interface by displaying the device list and capability list. In other words, when the first electronic device receives a user's action, it can assume that the user intends to make a cross-device call, and therefore needs to acquire the target service.

[0192] The application of the first electronic device can obtain a list of devices within a set range through interactions between devices. The distributed application framework of each device can determine whether a device has a collaborative service and scheduling module. If a device does not have a collaborative service and scheduling module, it does not have cross-device call capabilities and sends an empty message to the application of the first electronic device. In this case, the application interface of the first electronic device will not display the device name, or it will display the device name but distinguish it from other devices with cross-device call capabilities through a specific identifier.

[0193] In this embodiment, a call entry point is provided within the application of the first electronic device. For example, consider a note-taking application calling a camera application. Figure 5 As shown, the computer's note-taking application display interface 501 includes an insert button 502. After the user touches the insert button, the computer displays a list of server devices that can provide services and their corresponding capabilities on the display interface. The displayed devices can be a mobile phone 1 or a tablet 1. The capability list includes the services that the server device can provide, such as... Figure 5 Mobile phone 1 has functions for taking photos and scanning, while tablet 1 has functions for taking photos and scanning.

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

[0195] In some embodiments of this application, the display interface of the note-taking application can also display all devices within a set range, and distinguish whether a device has cross-device calling capabilities through a set identifier. For example, devices without cross-device calling capabilities can be displayed in gray, while other devices with cross-device calling capabilities are displayed normally. Figure 6 As shown, if all devices within the set range are phone 1, phone 2, tablet 1, and tablet 2, they are represented by diagonal dashed lines and displayed in gray. Phone 1 and tablet 1 are displayed normally, indicating devices with cross-device calling capabilities, while phone 2 and tablet 2 are devices without cross-device calling capabilities.

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

[0197] In some embodiments of this application, the display interface of the note-taking application can first display a list of devices, and then, in response to a touch operation on a device in the device list, display a list of capabilities corresponding to that device. For example, such as Figure 7 As shown, the displayed device list includes mobile phone 1, mobile phone 2, tablet 1, and tablet 2. In response to a touch operation on mobile phone 1, a list of capabilities corresponding to mobile phone 1 is displayed.

[0198] In this embodiment of the application, in response to an operation to open an application on the first electronic device, the application interface is displayed, and then in response to a touch operation on a target button (such as... Figure 5 (The "Insert" button in the interface) will then display a list of devices and their corresponding capabilities on the application interface of the first electronic device.

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

[0200] In other words, the device and capability lists are displayed before the service is acquired. Then, in response to a user's touch on an item in the list—for example, if the first electronic device responds to a user's touch on the camera service option of phone 1 in a list of applications—it can be determined that the corresponding second electronic device is phone 1, and the target service is the distributed application management service. At this point, the first electronic device can begin acquiring the distributed application management service from phone 1.

[0201] like Figure 4 As shown, the process of the first electronic device obtaining the target service includes: the system application framework of the first electronic device sends a request to the distributed service management module of the first electronic device to obtain the service, and the request carries the device identifier (DeviceId) and service name (ServiceName).

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

[0203] In some embodiments of this application, the first electronic device may call the same service multiple times. Therefore, after the first electronic device obtains the service for the first time, it can cache the information about that service locally. The next time an application on the first electronic device calls the service, it can directly look up the service name from the local cache. For example, if application 1 on computer 1 has called the scanning service on mobile phone 1 once, then the next time application 1 on computer 1 needs to call the scanning service, it can directly look up the name of mobile phone 1 and the name of the distributed application management service from computer 1's local cache.

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

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

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

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

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

[0209] The communication module is a message receiving module with message reception functionality. After receiving a message, the communication module of the second electronic device can parse it. If the message contains a service name, it can be considered a query command message. Then, based on the service name in the message, the corresponding target service can be queried in the distributed service management module. If the distributed service management module stores a service name that is the same as the service name in the message, it means that the corresponding target service has been found. The second electronic device then returns the IBinder object corresponding to the target service to the communication module of the second electronic device.

[0210] Understandably, the distributed Binder management module of the second electronic device establishes a mapping relationship between IBinder objects and BinderIds. After the mapping relationship is successfully established, the distributed Binder management module of the second electronic device sends the mapping relationship to the distributed service management module, which then saves the mapping relationship. (See reference...) Figure 4 The arrow indicates this. The communication module of the second electronic device queries the distributed service management module based on the mapping relationship.

[0211] In this process, after the second electronic device locates the corresponding IBinder object based on the service name in the distributed service management module, it sends the IBinder object back to the distributed Binder management module of the second electronic device. The distributed Binder management module of the second electronic device determines the BinderId corresponding to the IBinder object based on the established mapping relationship between Iinder objects and BinderIds. Then, it sends the determined BinderID to the communication module of the second electronic device.

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

[0213] It's important to note that the IBinder object generated by the second electronic device for the target service is not actually sent to the client. This is because the IBinder object has system boundaries and only has concrete meaning on the second electronic device. The IBinder object can be understood as a pointer or address; sending it to the first electronic device has no practical significance. Therefore, the second electronic device sends the BinderID to the first electronic device.

[0214] Specifically, after receiving the BinderID of the target service, the communication module of the second electronic device assembles it into a message and sends the message to the communication module of the first electronic device. In other words, the message carries the BinderID of the target service.

[0215] The communication module of the first electronic device receives the message, specifically the BinderID of the target service carried in the message. The first electronic device then creates a local IBinder object based on the BinderID. Specifically, the distributed Binder management module of the first electronic device creates the local IBinder object based on the BinderID.

[0216] Then, the newly created IBinder object is returned to Application 1 of the first electronic device. Specifically, the newly created IBinder object is returned sequentially to the distributed service management module of the first electronic device, the system application framework, and finally to Application 1 of the first electronic device.

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

[0218] In other words, in this embodiment of the application, in order for the first electronic device to call the second electronic device, a virtual IBinder object is created for the first electronic device and then corresponds to the received BinderId.

[0219] It's important to note that each service has a corresponding IBinder object, which can take several forms: one is the service itself, and another is a reference to a provided Binder object. Generally, the client obtains a reference to the Binder object (i.e., a Binder proxy). In other words, the server sends a Binder proxy object to the client's system application framework, effectively creating a proxy object on the client side.

[0220] Finally, after the first electronic device obtains the target service, it can call the service interface of the second electronic device. That is, after the first electronic device obtains the service provided by the application of the second electronic device, it calls the service interface through the IBinder object.

[0221] When a client calls a service interface on the server, it sends a service call request to the server. After receiving the request, the server calls the corresponding service interface and then returns a reply containing the call result to the client.

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

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

[0224] 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 handle is a local resource of the first electronic device, it cannot be obtained directly. Therefore, the 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 I Binder object, while the response contains an anonymous Binder 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.

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

[0226] like Figure 8 The steps are as follows. It is assumed that the request does not contain an IBinder object, but the response does. This can be applied to scenarios where a first electronic device calls a service of a second electronic device, and the service returned by the second electronic device to the first electronic device allows the first electronic device to make further calls.

[0227] like Figure 8 As shown, when the application 1 of the first electronic device uses a Binder reference object to call the interface corresponding to the remote service, it enters the distributed Binder management module for service collaboration. The input parameters in the interface call can be encapsulated in a Parcel package (i.e., Request Parcel).

[0228] The service coordination module parses the received Request Parcel (denoted as Parcel1) to determine if it contains an IBinder object. If it does not contain an IBinder object, the Parcel can be directly serialized. If it contains an IBinder object, the IBinder object is mapped and replaced before the Parcel is serialized. Since it's assumed the request does not contain an IBinder object, meaning that parsing Parcel1 determines it doesn't contain an IBinder object, the received Parcel1 can be directly serialized.

[0229] After Parcel1 is serialized, the first electronic device can send the request (i.e., the Binder call request) to the second electronic device. It's understandable that serializing the Parcel package means serializing the object's state into a byte stream, and byte streams can be transmitted across devices. Therefore, Parcel1 can be transmitted across devices, i.e., from the first electronic device to the second electronic device.

[0230] Specifically, the communication module of the first electronic device can assemble a message (denoted as message 1), which carries a Binder call request (i.e., a Parcel1 byte stream). The communication module of the first electronic device sends message 1 to the communication module of the second electronic device. Message 1 may contain identification information to identify that the message carries a Binder call from the first electronic device to the second electronic device. For example, certain bytes in the byte stream can be used to represent this identification information. The second electronic device can determine the type of request carried in message 1 using the identification information; for example, it can determine that the request is a function call type. The correspondence between the identification information and the request type can be preset.

[0231] Among them, message 1 also includes the BinderId of the target service received when the first electronic device obtains the target service.

[0232] The communication module of the second electronic device receives and parses message 1, determining that it carries a Binder call request. In other words, after receiving the request and deserializing it, the second electronic device calls the transact interface to execute the service interface call of the second electronic device. Specifically, the distributed Binder management module of the second electronic device processes the Parcel1 byte stream. First, since the previously assumed request does not contain an IBinder object, the Parcel1 byte stream can be directly deserialized. Then, it checks again whether it contains an IBinder object. Since it does not contain an anonymous IBinder object, the second electronic device can find the corresponding IBinder object based on the incoming BinderId (according to the mapping relationship stored in the second electronic device), and then directly call the transact interface to perform the actual service call. That is, the second electronic device finds the corresponding target service based on the received BinderId and calls the interface of the application containing that target service.

[0233] After the service interface call of the second electronic device is completed, which is equivalent to the actual method execution being completed, a result will be generated. This result will also be returned to the caller (i.e., the first electronic device) through the Parcel package (i.e., the Reply Parcel). In a remote call scenario, the Reply Parcel (let's call it Parcel2) needs to be returned to the first electronic device over the network.

[0234] When the second electronic device processes (parses) Parcel2, it can determine that Parcel2 contains IBinder objects. The distributed Binder management module of the second electronic device assigns a BinderId to the IBinder object (that is, establishes a mapping relationship between IBinder objects and BinderIds) and caches it in the Binder list. Then, the distributed Binder management module of the second electronic device performs serialization processing on Parcel2. Before serialization, the Binder objects in Parcel2 are replaced with BinderIds, and other spaces belonging to Binder objects are filled with placeholders.

[0235] The serialized data (Parcel2 byte stream) is then sent to the first electronic device. Specifically, the distributed Bind management module of the second electronic device constructs a message (let's call it message 2), which carries the response to the Binder call. The distributed Bind management module of the second electronic device sends the constructed message 2 to the communication module of the second electronic device, which then forwards message 2 to the communication module of the first electronic device.

[0236] After receiving message 2, the communication module of the first electronic device parses it to obtain a message corresponding to the response to the aforementioned Binder call. Then, the communication module of the first electronic device sends the parsed message to the distributed Binder management module of the first electronic device for processing.

[0237] After receiving the Parcel2 byte stream (i.e., the reply parcel byte stream mentioned above in the Binder call), the first electronic device processes the Parcel2 byte stream. Specifically, the distributed Binder management module of the first electronic device processes the Parcel2 byte stream. First, it deserializes the Parcel2 byte stream to obtain the Parcel2 object. Then, since the first electronic device can determine that Parcel2 contains an IBinder object, that is, by parsing Parcel2, it can determine that the corresponding BinderId is written into Parcel2. Therefore, the first electronic device can obtain the BinderId of the second electronic device and then create a local Binder reference object for the first electronic device, where a mapping relationship is established between the BinderId and the local Binder reference object. Then, the distributed Binder management module of the first electronic device writes the created Binder reference object into a new reply packet and returns it to application 1 of the first electronic device.

[0238] In summary, the embodiments of this application provide a cross-device service invocation method. After the first electronic device receives the BinderId of the IBinder object corresponding to the service of the second electronic device, it can create an IBinder object on its own end corresponding to the BinderId, and then invoke the service of the second electronic device through the IBinder object on its own end, thereby realizing cross-device service invocation.

[0239] In this embodiment, the cross-device service invocation method described above can be applied to a scenario where a first electronic device invokes the photo-taking service of a second electronic device. The first electronic device can be a personal computer, tablet, mobile phone, etc., and the second electronic device can be a tablet, mobile phone, etc.

[0240] If the first electronic device is a personal computer, the above cross-device service invocation method is introduced by taking the application of the first electronic device (e.g., a notebook) calling the photo-taking service of the application of the second electronic device (e.g., a camera) as an example.

[0241] In a scenario where the note-taking application of the first electronic device invokes the camera application's photo-taking service of the second electronic device, the second electronic device first registers with the distributed application management service within its own device. Then, the first electronic device obtains the registered distributed application management service from the second electronic device. After the first electronic device successfully obtains the second electronic device's distributed application management service, its note-taking application launches the second electronic device's camera application. The camera application takes a picture of the specified content, and the second electronic device then transmits the captured data to the first electronic device's note-taking application.

[0242] Therefore, the overall process of the aforementioned cross-device service invocation method can include three parts: service registration by the second electronic device, service acquisition by the first electronic device, and service data (photograph data) being sent back from the second electronic device to the first electronic device. The service registered by the second electronic device at this point is a distributed application management service. For example... Figure 9 As shown, Figure 9 This is a flowchart illustrating a cross-device service invocation method provided in an embodiment of this application.

[0243] like Figure 9 In the illustrated process, the first electronic device displays the interface of the first application, receives first touch operations from the user on multiple target device controls, and sends an acquisition command to the second electronic device, which is to acquire the distributed application management service registered by the second electronic device. The second electronic device receives the acquisition command from the first electronic device, looks up the BinderID of the distributed application management service based on the command, and sends the BinderID to the first electronic device. The first electronic device acquires the BinderID of the distributed application management service and creates an IBinder object based on that BinderID (see reference). Figure 9 (Steps S101-S103). That is, the specific process of the second electronic device registering for service and the first electronic device obtaining service, which will be described in detail below.

[0244] Please see Figure 10 , Figure 10 This is a sequence diagram showing the service registration process for the second electronic device and the service acquisition process for the first electronic device. First, the service registration process for the second electronic device is introduced.

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

[0246] The service registration process for the second electronic device is also the registration process for the distributed application management service of the second electronic device. Specifically, this includes: registering the distributed application management service of the second electronic device to the Distributed Service Manager module (see...). Figure 10 Step 1). Among them, the distributed application management service is in the system application framework and is started after the second electronic device is powered on.

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

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

[0249] In this context, the application (e.g., the camera application) is an interface provided by the distributed application framework, which is located within the system application framework. After the first electronic device obtains the distributed application management service registered by the second electronic device, it can call the camera application of the second electronic device through the distributed application framework to access the services provided by the camera application.

[0250] Secondly, the process of the first electronic device obtaining services is described. Specifically, after the second electronic device successfully registers its distributed application management service, the first electronic device can obtain the distributed application management service registered by the second electronic device.

[0251] Understandably, before accessing the photo service, the first electronic device had already opened the note-taking application and, in response to the user's touch operation on the note-taking application interface, displayed the device list and capability list. In other words, when the first electronic device receives the user's action, it can assume the user intends to make cross-device calls and therefore needs to access the distributed application management service provided by the second electronic device.

[0252] The entry point for accessing this feature is located within the note-taking application of the first electronic device. For example... Figure 5 As shown, the computer's note-taking application has an insert button on its display interface. After the user touches the insert button, the computer displays a list of available second electronic devices and their corresponding capabilities. The displayed devices can be a mobile phone (1) or a tablet (1). The capability list includes the services that the second electronic device can provide, such as... Figure 5 Mobile phone 1 has functions for taking photos and scanning, while tablet 1 has functions for taking photos and scanning.

[0253] In some embodiments of this application, the first electronic device may be calling the camera's photo-taking service of the second electronic device for the first time, or there may be multiple calls. Therefore, after the first electronic device obtains the camera's photo-taking service for the first time, it can cache the call information locally. Thus, the first electronic device can first search for the second electronic device and the distributed application management service in its local cache. If found, it directly returns the information to the note-taking application; if not found, it can search for it in the second electronic device.

[0254] The embodiments of this application describe in detail the process of obtaining the distributed application management service when the first electronic device calls the camera of the second electronic device for the first time.

[0255] In this embodiment, after the distributed application management service of the second electronic device is successfully registered, and in response to the user's touch operation on the entry point of the note-taking application interface, the note-taking application of the first electronic device can obtain the distributed context of the second electronic device, that is, obtain the "DisApp" service of the second electronic device (see...). Figure 10 Step 2.1). Specifically, the system application framework of the first electronic device sends a request to the distributed service management module of the first electronic device to obtain the "DisApp" service. Then, the distributed service management module of the first electronic device sends a request to the message center-communication module of the first electronic device to obtain the "DisApp" service (see...). Figure 10 Step 2.2).

[0256] After receiving a request to obtain the "DisApp" service, the communication module of the first electronic device creates a session with the first electronic device (see [reference]). Figure 10 Step 2.2.1). After the channel is successfully created, the distributed service management module of the first electronic device sends an instruction to the communication module of the first electronic device to obtain the "DisApp" service (refer to...). Figure 10 Step 2.2.2). The communication module of the first electronic device receives the instruction to obtain the "DisApp" service, assembles a message, and sends the message to the communication module of the second electronic device.

[0257] After receiving the message, the communication module of the second electronic device parses the message and obtains the instruction to obtain the "DisApp" service (see reference). Figure 10 Step 2.2.3). The communication module of the second electronic device sends this instruction to the distributed Binder management module of the second electronic device (refer to...). Figure 10 Step 2.1.4).

[0258] After receiving the instruction, the distributed Binder management module of the second electronic device searches for the "DisApp" service in the distributed service management module. As mentioned in step 1.1, the distributed service management module stores service names and corresponding IBinder objects. Therefore, the distributed Binder management module can search its database to see if the service ("DisApp") is stored based on the service name in the instruction. If the service ("DisApp") is found, the corresponding IBinder object (IBinder S1) is determined.

[0259] Then, the distributed service management module of the second electronic device returns the IBinder object (IBinder S1) to the distributed Binder management module of the second electronic device. The distributed Binder management module of the second electronic device determines the BinderId (BinderId S1) corresponding to the IBinder object (IBinder S1) based on the established mapping relationship between IBinder objects and BinderIds (see reference). Figure 10 Step 2.2.4). Then, the BinderId (BinderId S1) is sent to the communication module of the second electronic device (see step 2.2.4). Figure 10 Step 2.2.5).

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

[0261] The communication module of the first electronic device receives the message, parses the information content, and obtains the BinderId (BinderId S1) of the "DisApp" service (see reference). Figure 10 Step 2.2.6). 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. The distributed service management module of the first electronic device sends the BinderId (BinderId S1) of the "DisApp" service to the distributed Binder management module of the first electronic device. Then, the distributed Binder management module creates a new local IBinder object (IBinder C1) based on BinderId S1, that is, the distributed Binder management module creates a mapping relationship between BinderId S1 and IBinder C1 and stores the mapping relationship (see...). Figure 10 Step 2.2.7).

[0262] 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 communication module of the first electronic device, and the system application framework (see...) Figure 10 Step 2.2.8) is then returned to the note-taking application on the first electronic device (see step 2.2.8). Figure 10 Step 2.3).

[0263] In this embodiment of the application, after the first electronic device obtains the "DisApp" service registered by the second electronic device, the first electronic device opens the camera application of the second electronic device.

[0264] 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:

[0265] like Figure 11As shown, the note-taking application sends a `start activity forresult(intent)` message to the system application framework of the first electronic device. The Intent contains the URI and device information. The note-taking application makes the call through a locally created IBinder C1. The input parameters (URI and device information) in the message are encapsulated in parcel A. The system application framework sends parcel A to the distributed Binder management module in the service collaboration module of the first electronic device. The distributed Binder management module parses parcel A and determines that parcel A does not contain an IBinder object. It can then directly serialize parcel A to obtain the byte stream of parcel A.

[0266] The service coordination module of the first electronic device then sends the parcel A byte stream (request) to the service coordination module of the second electronic device. Specifically, the communication module of the first electronic device sends the parcel A byte stream to the communication module of the second electronic device. The communication module of the second electronic device then forwards the parcel A byte stream to the distributed Binder management module in the service coordination module of the second electronic device. The distributed Binder management module deserializes the parcel A byte stream to obtain parcel A.

[0267] The distributed Binder management module of the second electronic device sends parcel A (request) to the system application framework of the second electronic device. The system application framework of the second electronic device sends a start activity message to the camera application, which then calls the start activity method to start the camera through the locally created IBinder S1. Then, the system application framework encapsulates the result data returned by the camera application (camera turned on) in parcel A' (reply) and sends it to the distributed Binder management module in the service collaboration module of the second electronic device. The distributed Binder management module parses parcel A', determines that parcel A' does not contain an IBinder object, and can directly serialize parcel A' to obtain the byte stream of parcel A'.

[0268] The service coordination module of the second electronic device sends the parcel A' byte stream to the service coordination module of the first electronic device. Specifically, the communication module of the second electronic device sends the parcel A' byte stream to the communication module of the first electronic device. The communication module of the first electronic device then forwards the parcel A' byte stream to the distributed Binder management module in the service coordination module of the first electronic device. The distributed Binder management module deserializes the parcel A' byte stream to obtain parcel A'.

[0269] The distributed Binder management module of the first electronic device sends parcel A' to the system application framework of the first electronic device. At this point, the camera is successfully activated.

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

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

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

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

[0274] The note-taking application of the first electronic device can create a photo cache file (File Provider) with a Uniform Resource Identifier (URI). Specifically, the photo cache file has a File Provider (equivalent to a binder object), which the note-taking application registers with the system application framework. The note-taking application can create the photo cache file in response to a user's touch operation on the camera options, or it can create the photo cache file at any time before obtaining its file handle.

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

[0276] The distributed Binder management module of the service collaboration module processes the request parcel (denoted as reqA) (see reference). Figure 12 Step 1.3). Specifically, first, it is determined whether reqA contains an anonymous IBinder object. By parsing reqA, it can be determined that reqA does not contain an anonymous IBinder object. This is understandable, since reqA is only used to retrieve the File Provider object for notes and does not require further calls, reqA does not contain an anonymous IBinder object. Then, the distributed Binder management module can directly serialize reqA.

[0277] After the distributed Binder management module serializes reqA, it forwards the call request (reqA byte stream) to the communication module of the second electronic device. The communication module of the second electronic device assembles a message and sends the reqA byte stream to the communication module of the first electronic device. This message contains the BinderId S1 of the "DisApp" service.

[0278] The communication module of the first electronic device receives and parses the message, determining that it carries a Binder call request. It then sends the message to the distributed Binder management module of the first electronic device. The distributed Binder management module parses the message, obtaining a reqA byte stream (i.e., the serialized reqA), and deserializes the reqA byte stream to obtain reqA. The distributed Binder management module then finds the corresponding local IBinder object (IBinder C1) based on the received BinderId S1. Finally, it calls transact to perform the actual service call (i.e., retrieving the File Provider object for the notes).

[0279] The system application framework of the first electronic device writes the File Provider object of the note-taking application into a Parcel package, namely the Reply Parcel (denoted as repB), and then returns repB to the camera application of the second electronic device. Specifically, the system application framework calls on transact (see... Figure 12 Step 1.6). The distributed Binder management module of the first electronic device processes repB. Specifically, it checks if repB contains an IFile Pc (equivalent to an IBinder object), and then assigns a BinderId2 to the IFile Pc object (that is, establishes a mapping relationship between the IFile Pc object and BinderId2). Then, the distributed Binder management module performs serialization processing on repB. Before serialization, the IFile Pc object in repB is replaced with BinderId2, the generated new Reply Parcel is set as repB1, and other spaces belonging to the IFile Pc object are filled with placeholders (refer to...). Figure 12 Step 1.6.1).

[0280] 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.

[0281] 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.

[0282] In other words, the distributed Binder management module of the second electronic device processes the repB1 byte stream. Specifically, it first deserializes the repB1 byte stream 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 determine that the corresponding BinderId2 has been written into repB1. Therefore, the second electronic device can obtain the BinderId2 of the first electronic device and then create an Ibinder object (denoted as IFilePs) of the second electronic device, in which a mapping relationship is established between BinderId2 and the IFilePs object of the second electronic device. Then, the distributed Binder management module of the second electronic device writes the created IFilePs object into a reply packet (denoted as repB2) and returns it to the camera application (see reference). Figure 12 Step 1.8).

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

[0284] Please see Figure 13 , Figure 13 A timing diagram for obtaining the file handle of the photo cache file of the notes provided in an embodiment of this application. (See diagram below.) Figure 13 As shown, when the camera application calls the corresponding interface of the note application using the IFilePs object, it enters the distributed Binder management module of the service collaboration module. The input parameters in the interface call (by calling the transact method) can be encapsulated in the Parcel package (i.e., the request parcel).

[0285] The distributed Binder management module of the service collaboration module processes the request parcel (denoted as reqD) and reqD (see reference). Figure 13 Step 1.3). Specifically, first, it is determined whether reqD contains an anonymous IBinder object. By parsing reqD, it can be determined that reqD does not contain an anonymous IBinder object. It is understandable that since reqD is only used to obtain the file handle of the notes and does not require further calls, it can be determined that reqD does not contain an anonymous IBinder object. Then, the distributed Binder management module can directly perform serialization processing on reqD.

[0286] After the distributed Binder management module serializes reqD, it forwards the call request (reqD byte stream) to the communication module of the second electronic device. The communication module of the second electronic device then assembles a message and sends the reqD byte stream, which contains BinderId2, to the communication module of the first electronic device.

[0287] The communication module of the first electronic device receives and parses the message, determining that it carries a Binder call request. It then sends the message to the Binder management module of the first electronic device. The Binder management module parses the message, obtaining the serialized `reqD` (a byte stream), and deserializes the `reqD` byte stream to obtain `reqD` again. The distributed Binder management module of the first electronic device finds the corresponding local IBinder object (`IFilePc`) based on the received `BinderId2`. Then, it calls `transact` to perform the actual service call (i.e., obtain the file handle of the note).

[0288] The note-taking application on the first electronic device writes the file descriptor object Fdc into a Parcel package, namely the Reply Parcel (denoted as repE), and then returns repE to the camera application on the second electronic device. Specifically, the note-taking application calls onTransact (see... Figure 13 Step 1.6). The distributed Binder management module of the first electronic device processes the repE. Specifically, it checks if the repE contains an Fdc (equivalent to a Binder object), and then sends an instruction to create a distributed file to the distributed file module of the first electronic device (see...). Figure 13(Step 1.6.2). Let the name of the created distributed file be "DisPicture". It's understandable that files can be accessed through 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 / write operations, a distributed file can be created (the distributed file module can provide cross-device file access) to ensure that data is written across devices from the camera side to the file on the device side where the note-taking application resides.

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

[0290] 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 that 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, and then the communication module of the first electronic device sends the message to the communication module of the second electronic device.

[0291] After receiving the message, the communication module of the second electronic device parses it to obtain the message corresponding to repE1. 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.

[0292] In other words, the distributed Binder management module of the second electronic device processes the repE1 byte stream. Specifically, the distributed Binder management module of the second electronic device deserializes the repE1 byte stream to obtain the repE1 object. Then, the distributed Binder management module can detect that repE1 contains the name of a distributed file, meaning that repE1 contains information related to the corresponding file handle. The second electronic device can read the name of the distributed file (“DisPicture”) in repE1 and open the corresponding distributed file (see reference). Figure 13 Step 1.7.2).

[0293] Then, the distributed file module of the second electronic device returns the file handle VFd of the distributed file to the distributed Binder management module of the second electronic device. The distributed Binder management module writes the file handle VFd into a reply packet (let's call it repE2) and returns it to the camera application (see reference). Figure 13 Step 1.8).

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

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

[0296] The above steps of transmitting the photographed data back to the first electronic device, namely Figure 9 Steps S104-S110 are as follows: The second electronic device, in response to the user's second touch operation on the second application, sends a request to the first electronic device based on the first BinderID of the distributed application management service. The first electronic device, upon receiving the request from the second electronic device, searches for the corresponding IBinder object based on the BinderID contained in the request. The first electronic device then instructs the second electronic device to send a first file provider object based on this IBinder object, i.e., sends the BinderID corresponding to the first file provider object to the second electronic device. The second electronic device creates a corresponding second file provider object locally based on the received BinderID of the first file provider object. The second electronic device then sends a request to the first electronic device based on the second file provider object to obtain a file handle object. In response to the received request, the first electronic device instructs the second electronic device to send the name of the distributed file corresponding to the first file handle object. The second electronic device, upon receiving the instruction of the first file handle object (i.e., receiving the name of the corresponding distributed file), opens the corresponding distributed file. The second electronic device returns the result of the service execution to the distributed file and then returns the result to the first electronic device.

[0297] In summary, the aforementioned cross-device service invocation method 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, and then directly sends the shooting result or scanned text back to the first electronic device. This eliminates the need for users to upload the shooting result or scanned text to the first electronic device, download and save it there, and then upload it again to the corresponding location on the first electronic device. The operation is simpler and improves user efficiency.

[0298] Please see Figure 14 , Figure 14 A schematic diagram illustrating a cross-device invocation scenario is provided, such as... Figure 14 As shown, the computer's note-taking application interface has an insert button. After the user touches this button, the computer displays a list of server devices that can provide services, along with a list of their corresponding capabilities. The displayed devices can be a mobile phone (1) or a tablet (1). The capability list includes the services that the server device can provide, such as... Figure 14 The system includes functions like taking photos and scanning on both mobile phone 1 and tablet 1. When the user clicks the photo option on mobile phone 1, the computer sends a command to mobile phone 1 to open the camera application. Mobile phone 1 opens the camera application, takes a photo of the specified content, and receives the photo upon the user clicking the shutter button. Then, mobile phone 1 receives the confirmed photo upon the user clicking the confirmation button. Finally, mobile phone 1 sends the confirmed photo back to a designated location in the computer's note-taking application.

[0299] Therefore, through the aforementioned cross-device service invocation method, users can send shooting commands from their computers to their mobile phones. Upon receiving the shooting command, the mobile phone activates its camera to perform a photo or scan task, and then directly sends the shooting results or scanned text back to the computer. This saves users the steps of uploading the shooting results or scanned text to the computer, downloading and saving them, and then uploading them to the corresponding location, making the operation simpler and improving user work efficiency.

[0300] In this embodiment of the application, the cross-device service invocation method involves the serialization and deserialization of parcel packages. For example, in the process of the camera application obtaining the File Provider object of the notes application, it is necessary to serialize and deserialize reqA (request parcel A) and repB (reply parcel B). In the process of the camera application obtaining the file handle of the photo cache file of the notes application, it is necessary to serialize and deserialize reqD (request parcel D) and repE (reply parcel E). Here, reqA and reqD do not contain anonymous binder objects, while repB contains a File Pc object (i.e., repB contains an anonymous binder object), and repE contains an Fdc object (i.e., repE contains a file handle).

[0301] Existing serialization and deserialization methods only support serialization and deserialization of parcel packages that do not contain anonymous Binder objects or file handles. In other words, these methods only apply when the parcel package contains only basic type objects (such as int and string objects). Existing methods do not support serialization and deserialization of parcel packages containing complex objects such as anonymous Binder objects or file handles.

[0302] In this application embodiment, a cross-device data processing method is provided. When the parcel package contains complex objects such as Binder objects or file handles, the Binder objects or file handles in the parcel package are replaced before serialization, so that the two devices can access each other.

[0303] like Figure 15 As shown in the figure, this application provides a schematic diagram of the data structure of the parcel package. Figure 15 In the mData field, the InterfaceToken is located at the beginning of the mData field. It is usually filled with the package name, and each application will have a package name. Figure 15 The data also includes an int type data and a string type data. This example only uses two common data types, but other data types can also be used.

[0304] The parcel package also contains the starting positions of binder1 and binder2, which are stored as DataPos for binder1 and binder2. This indicates the starting bytes for binder1 and binder2 objects. In other words, the data structure contains bytes that identify the position of a binder object or file handle object. The specific position of a binder object can be obtained through these bytes in the parcel.

[0305] It should be noted that, Figure 15 The parcel data structure in the example is for illustrative purposes only. In real-world scenarios, the parcel package typically contains only one Binder object, and not two Binder objects.

[0306] Please see Figure 16 , Figure 16 This application provides a cross-device data processing method, wherein the Parcel package contains a Binder object. For example... Figure 16 As shown, we can define the left side as electronic device 1 and the right side as electronic device 2. Local resources from electronic device 1 are sent to electronic device 2. In Parcel A, S is a Binder object with a corresponding BinderId of S1. Before serialization, electronic device 1 can replace the Binder object S with the corresponding BinderId (S1) to obtain Parcel A'. Then, Parcel A' is serialized to obtain the serialized Parcel A', i.e., the byte stream of Parcel A', which is then transmitted to the client over the network. It can be understood that S in Parcel A, as a Binder object, can call the corresponding target service in electronic device 1, such as service 1.

[0307] After receiving the byte stream of Parcel A', electronic device 2 deserializes it to obtain Parcel A'. Electronic device 2 then parses Parcel A' to obtain BinderId(S1), and then creates a Binder reference object Q corresponding to BinderId(S1) locally on electronic device 2. Q is then written into Parcel A' to obtain Parcel B. That is, electronic device 2 can subsequently use the Binder reference object Q to call service 1 of electronic device 1.

[0308] In this parcel, the Binder object occupies a fixed number of bytes, for example, 28 bytes. Before serialization, a corresponding Binder Id is assigned to each Binder object. The Binder Id can be defined as an integer type, occupying 4 bytes. Therefore, in Parcel A', after replacing the Binder object with the Binder Id, the bytes in the Binder object other than the Binder Id need to be padded with placeholders. This ensures that when replacing the Binder object in the parcel, other data remains unchanged and the original structure of the parcel is not affected. When filling in placeholders, any preset placeholder can occupy the corresponding position. The form of the preset placeholder is not limited in this application; it can be empty or zero.

[0309] Figure 16 In this process, the Binder object can be S, and its assigned BinderId is S2. Before serialization, electronic device 1 can replace the Binder object S with the corresponding BinderId (S2) to obtain Parcel A'. Then, it serializes Parcel A' to obtain the serialized Parcel A', which is the byte stream of Parcel A', and then transmits it to electronic device 2 over the network. After receiving the byte stream of Parcel A', electronic device 2 deserializes it to obtain Parcel A'. Electronic device 2 parses Parcel A' to obtain BinderId (S2), and then creates a binder reference object Q1 corresponding to BinderId (S2) locally on electronic device 2, and writes Q1 into Parcel A' to obtain Parcel B.

[0310] In this embodiment of the application, during the process of the camera application obtaining the File Provider object of the note-taking application, after the first electronic device receives the request reqA to obtain the File Provider object, the first electronic device writes the File Provider object of the note-taking application into the Parcel package (i.e., repB). Figure 17 A method for serializing this repB is provided.

[0311] Figure 17In this example, the local Binder1 in repB can represent the aforementioned File Provider object (IFile Pc object). The first electronic device assigns a corresponding BinderId (BinderId2) to the IFile Pc object. Before serialization, the first electronic device can replace the IFile Pc object with the corresponding BinderId (BinderId2) to obtain repB1. Then, repB1 is serialized to obtain the serialized repB1, which is the byte stream of repB1, and then transmitted to the second electronic device over the network.

[0312] After receiving the repB1 byte stream, the second electronic device deserializes it to obtain repB1. The second electronic device then parses repB1 to obtain BinderId 2, and then locally creates an IFilePs object (i.e., a reference object corresponding to BinderId 2) on the second electronic device. Figure 17 In the remote Binder10, the IFile Ps object is written to repB1, resulting in repB2.

[0313] In summary, the Parcel serialization method provided in this application allows for cross-device transmission of Parcel packages containing Binder objects. If the Parcel package contains a Binder object, the serialization process is performed after replacing the Binder object with the corresponding BinderId. Specifically, the local resource (Binder object) is replaced with the cross-device resource (BinderId) before serialization and transmission. Upon receiving the serialized Parcel package at the other end, deserialization is performed to obtain the BinderId, which is then replaced with the locally created Binder object. Therefore, this Parcel serialization method enables cross-device transmission of Parcel packages containing Binder objects.

[0314] In this embodiment of the application, in the scenario of cross-device service invocation, the cross-device transmission of Parcel packets containing file handles is also involved. The serialization method of the Parcel packet is described below.

[0315] Please see Figure 18 , Figure 18 This application provides a cross-device data transmission method, wherein the Parcel packet contains a file handle. For example... Figure 18As shown, we can assume the left side is electronic device 3 and the right side is electronic device 4. Local resources from electronic device 3 are sent to electronic device 4. In Parcel D, T is a file handle object with the name T1. Before serialization, electronic device 3 can replace the file handle object T with the corresponding name T1 to obtain Parcel D'. Then, Parcel D' is serialized to obtain the serialized Parcel D', which is the byte stream of Parcel D', and then transmitted to electronic device 4 over the network.

[0316] After receiving the byte stream of Parcel D', electronic device 4 deserializes it to obtain Parcel D'. Electronic device 4 parses Parcel D' to obtain the name T1 corresponding to the file handle object T. Then, electronic device 4 creates a file handle object K corresponding to the name T1 locally and writes K into Parcel D' to obtain Parcel E.

[0317] In this embodiment of the application, during the process of the camera application obtaining the file handle of the photo cache file of the note-taking application, after the first electronic device receives the request reqD to obtain the file handle object, the first electronic device writes the file descriptor Fdc of the note-taking application into the Parcel packet (i.e., repE). Figure 19 A method for serializing this repE is provided.

[0318] Figure 19 In this process, the first electronic device creates a distributed file for a file descriptor Fdc object, named "DisPicture" as described above. Before serialization, the first electronic device can replace the Fdc object with "DisPicture" to obtain repE1. Then, repE1 is serialized to obtain the serialized repE1, which is the byte stream of repE1, and then transmitted to the client over the network.

[0319] After receiving the `repE1` byte stream, the second electronic device deserializes it to obtain `repE1`. The second electronic device then parses `repE1` to obtain the name of the distributed file. Specifically, the second electronic device can read the name of the distributed file based on the type and offset position in the `repE1` message header. Then, the second electronic device opens the corresponding distributed file according to the name and returns the distributed file handle `VFd`. The second electronic device writes the distributed file handle `VFd` object into `repE1`, obtaining `repE2`.

[0320] In summary, the Parcel packet serialization method provided in this application embodiment can, in scenarios where Parcel packets are transmitted across devices, replace the file handle object with the name of the corresponding distributed file before serialization and transmission if the Parcel packet contains a file handle object. That is, the local resource (file handle object) is replaced with the cross-device resource (name of the distributed file) before serialization and transmission. Upon receiving the serialized Parcel packet at the other end, deserialization is performed to obtain the name of the distributed file. Then, the corresponding distributed file is opened based on the name, and the file handle object corresponding to the locally created distributed file is obtained. Therefore, the above Parcel packet serialization method can achieve cross-device transmission of Parcel packets containing file handle objects.

[0321] Please see Figure 20 ,like Figure 20 In the cross-device data transmission method flowchart shown (refer to steps S201-S209), after the first electronic device calls the target service of the second electronic device, namely the distributed application management service, the second electronic device, after obtaining the execution result, follows the specific steps of the camera application sending the captured data back to the note. Specifically, it first obtains the note's File Provider object, and then uses that object to obtain the file handle. The second electronic device sends a request to the first electronic device to obtain the first file handle object. After obtaining the first file handle object of the preset file, the first electronic device creates a corresponding first distributed file based on the first file handle object, and then sends the file name of the first distributed file to the second electronic device. The second electronic device opens the corresponding second distributed file using the received file name and obtains the corresponding second file handle object. Then, the second electronic device writes the acquired captured data into the first distributed file. The captured data in the second distributed file is then transmitted to the first distributed file of the first electronic device, and then further written into the preset file of the first electronic device.

[0322] Therefore, through the above-mentioned cross-device data transmission method, the cross-device transmission of Parcel packages containing file handle objects can be realized, enabling the return of photographed data to the calling application of the first electronic device, thus realizing the complete process of cross-device calling.

[0323] In this embodiment of the application, during the process of a client calling a service on the server, the server application may exit. For example, the server application may exit due to some kind of exception, or the application may exit normally in response to a user's operation. Both of these situations can be considered as an exception occurring in the server application. In this case, both the client application and the server application need to clean up the locally stored resources to avoid resource redundancy.

[0324] Therefore, this application provides a cross-device service call resource cleanup method, which can clean up the resources stored in the client application and the server application when the server application exits.

[0325] In this embodiment, the cross-device service call resource cleanup method described above can be applied to scenarios where a first electronic device (client) calls a service from a second electronic device (server). The first electronic device can be a personal computer, tablet, mobile phone, etc., and the second electronic device can be a tablet, mobile phone, etc.

[0326] If the first electronic device is a personal computer, the above-mentioned cross-device service call resource cleanup method is introduced by taking the application 1 of the first electronic device calling the service S1 of the application 2 of the second electronic device as an example.

[0327] Please see Figure 21 ,like Figure 21 In the resource cleanup method flowchart shown (refer to steps S301-S307), after the first electronic device calls the target service of the second electronic device, it registers a cleanup service for the acquired target service and sends a registration instruction for the cleanup service to the second electronic device based on the first IBinder object of the cleanup service. The second electronic device receives the registration instruction from the first electronic device and obtains the fourth IBinder object of the cleanup service. In response to the exit of the target service, the second electronic device executes the cleanup service based on the fourth IBinder object and sends a request to the first electronic device to invoke the service. In response to receiving the first cleanup invocation request from the second electronic device, the second electronic device executes the cleanup service based on the first IBinder object. Here, registering the cleanup service means registering a death notification. The cleanup resources mainly include the target service and the invocation resources of the cleanup service, and the invocation resources include the resources used by the electronic device when invoking the corresponding service. The above steps are described in detail below.

[0328] The overall process of the aforementioned cross-device service call resource cleanup method can be mainly divided into four parts: service registration of the first electronic device, service acquisition by the second electronic device, service registration death notification of the first electronic device, and service exit of the second electronic device. The services registered and acquired by the electronic device can be any service, such as distributed application management services or audio services. The registration death notification is used so that after Binder communication is established, the client can receive a notification when the server unexpectedly crashes due to internal errors or other reasons.

[0329] Please see Figure 22 , Figure 22 This is a timing diagram of a cross-device service call resource cleanup method provided in an embodiment of this application. Figure 22 As shown, let's assume the service name registered by Application 2 is "ServiceS1". The process of Application 2 registering the service is consistent with the service registration process in the cross-device service invocation method described above. Specifically, Application 2's "ServiceS1" service is registered in the distributed service management module of the service collaboration module. The distributed service management module stores the service name ("ServiceS1") and IBinder object (IBinder S1) of "ServiceS1". The distributed Binder management module then assigns a corresponding BinderId (BinderId S1) to the "ServiceS1" service.

[0330] After the second electronic device stores the service name, iBinder object, and corresponding BinderId, the service registration of the first electronic device is successful. The first electronic device can then obtain the "ServiceS1" service registered in the second electronic device. Specifically, the first electronic device initiates a service request to the second electronic device, carrying the device identifier (DeviceId) and service name ("ServiceS1") in the request. The distributed Binder management module of the first electronic device can assemble a message (carrying the service name) and send it to the distributed Binder management module of the second electronic device through the channel established between the communication modules of the first and second electronic devices.

[0331] The first electronic device can establish a connection with the second electronic device based on the device identifier in the request.

[0332] The distributed Binder management module of the second electronic device searches for the corresponding service in the distributed service management module based on the service name carried in the message. The distributed service management module stores the mapping between service names and IBinder objects. After finding the corresponding service, it determines the IBinder object corresponding to the service and then returns the IBinder object to the distributed Binder management module of the second electronic device to determine the BinderId S1 corresponding to the IBinder object.

[0333] Then, the distributed Binder management module of the second electronic device can assemble a message (carrying BinderIdS1) and send the message to the distributed Binder management module of the first electronic device through the channel established between the communication module of the first electronic device and the communication module of the second electronic device.

[0334] After receiving the message, the distributed Binder management module of the first electronic device parses it to obtain BinderId S1 and creates a local IBinder object (IBinder C1) based on BinderId S1. A mapping relationship is established between IBinder C1 and BinderId S1.

[0335] Then, the newly created Ibinder objects are returned sequentially to the distributed service management module of the first electronic device, and the application 1 of the first electronic device.

[0336] After the first electronic device obtains service S1, that is, after the first electronic device obtains the IBinder reference object (IBinder C1) of service S1, the first electronic device can register a death notification for IBinder C1.

[0337] Specifically, application 1 of the first electronic device sends a request (i.e., request parcel, denoted as req1) to the distributed Binder management module of the first electronic device, where req1 contains recipient C1. The distributed Binder management module of the first electronic device assigns a corresponding BinderId (BinderId C1) to recipient C1. A mapping relationship is established between recipient C1 and BinderId C1.

[0338] Understandably, RecipientC1 is an anonymous binder object created by application 1 itself.

[0339] The distributed Binder management module of the first electronic device replaces recipient C1 with BinderId C1 in req1 and serializes req1. Then, the distributed Binder management module of the first electronic device can assemble the message (carrying the serialized req1) and send the message to the distributed Binder management module of the second electronic device through the channel established between the communication module of the first electronic device and the communication module of the second electronic device.

[0340] The distributed Binder management module of the second electronic device parses the received message to obtain the serialized req1 (req1 byte stream). The distributed Binder management module of the second electronic device deserializes the req1 byte stream to obtain req1, and parses it to obtain the BinderId C1 in req1.

[0341] The distributed Binder management module of the second electronic device creates recipient S1 and associates it with BinderId C1. The distributed Binder management module of the second electronic device sends an instruction to application 2 to register a death notification; that is, the distributed Binder management module of the second electronic device sends an instruction to application 2 to register a death notification for IBinder S1 (Service S1).

[0342] After the second electronic device successfully registers the death notification, the registration result is returned to the first electronic device.

[0343] At this point, both the first and second electronic devices have completed the registration for death notification. When the service of the second electronic device exits, the first and second electronic devices can clean up the service-related resources according to the death notification mechanism.

[0344] In this embodiment of the application, after the application 2 of the second electronic device exits, the driver of the second electronic device triggers the recipient S1 death notification callback binderDied function. In the binderDied function, local ServiceS1-related resources are cleaned up, including the mapping relationship between ServiceS1 and its ServiceName and BinderId.

[0345] After the second electronic device completes the cleanup, it sends a message to the first electronic device to clean up the services associated with ServiceS1, triggering resource cleanup and application notifications on the first electronic device.

[0346] After receiving the message, the first electronic device locates the recipientC1 of the service ServiceC1 associated with ServiceS1 and uses recipientC1 to call back the death notification interface binderDied function. Upon receiving the callback, the application cleans up the resources associated with ServiceC1 itself.

[0347] After the recipientC1 callback of the first electronic device is completed, firstly clean up the local resources of ServiceC1 and its related resources, such as the mapping relationship between ServiceC1 and its ServiceName and BinderId; secondly, clean up the mapping relationship between recipientC1 and its BinderId.

[0348] In this embodiment of the application, the second electronic device can first clear its local resources, and then send a message to notify the first electronic device to clear its resources (e.g., ...). Figure 22 (The steps are as follows). Alternatively, a message can be sent to the first electronic device to clean up resources first, and then the local resources can be cleaned up. Alternatively, parallel processing can be performed: while the second electronic device is cleaning up its local resources, a message can be sent to the first electronic device to clean up resources. After the second electronic device sends a message to the first electronic device to clean up resources, and after cleaning up the local resources, the resources called in response to the death notification, such as the mapping relationship between recipientC1 and its BinderId, can also be cleaned up.

[0349] It's understandable that service calls are normal during the registration of death notifications. That is, the death notification registration should occur after the first electronic device obtains the service registered by the second electronic device. Registering for a death notification when the service exits is meaningless, as it would fail to promptly notify both ends to clean up their respective service call resources.

[0350] After the first electronic device and the second electronic device complete resource cleanup, the first electronic device needs to re-acquire the services of the second electronic device and re-register the death notification when it makes the next call.

[0351] In summary, Application 1 of the first electronic device can promptly receive the service exit message from the second electronic device, enabling timely cleanup of stored resources and preventing resource redundancy within the first electronic device. Furthermore, after the first electronic device promptly cleans up the resources related to the service call, there is no longer any information related to that service in the first electronic device (e.g., the corresponding second electronic device and service are no longer displayed on Application 1's interface). This prevents subsequent calls to the service from failing (e.g., user clicks on the second electronic device and service are ineffective), thus improving the user experience.

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

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

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

[0355] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0356] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

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

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

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

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

Claims

1. A cross-device data processing method, applied to a first electronic device, characterized in that, The method includes: The first electronic device invokes the target service of the second electronic device; The first electronic device obtains a first file handle object of a preset file and creates a first distributed file based on the first file handle object; wherein, the preset file is used to store preset data, and the preset data is the result of the second electronic device executing the target service; the first distributed file and the second distributed file in the second electronic device are used to support data access between the first electronic device and the second electronic device, and the first file handle object is used by the first electronic device to return the preset data in the first distributed file to the preset file; The first electronic device sends the file name of the first distributed file to the second electronic device, so that the second electronic device opens the corresponding second distributed file based on the file name, and the second distributed file is used to obtain the preset data; The first distributed file of the first electronic device receives the preset data transmitted by the second distributed file of the second electronic device; The first electronic device returns the preset data in the first distributed file to the preset file through the first file handle object.

2. The cross-device data processing method according to claim 1, characterized in that, The first electronic device acquires a first file handle object of a preset file, including: The first electronic device receives a first request from the second electronic device to obtain the first file handle object of the preset file; wherein, the first request is used by the second electronic device to request the first electronic device to obtain the first file handle object.

3. The cross-device data processing method according to claim 1 or 2, characterized in that, Before the first electronic device sends the filename of the first distributed file to the second electronic device, the method further includes: The first electronic device generates a first transmission data packet based on the first file handle object; wherein the first transmission data packet contains the first file handle object; The first electronic device replaces the first file handle object in the first transmission data packet with the file name of the first distributed file to obtain the second transmission data packet; Wherein, the first electronic device sends the file name of the first distributed file to the second electronic device, including: The first electronic device sends the second transmission data packet to the second electronic device.

4. The cross-device data processing method according to claim 1 or 2, characterized in that, Before the first electronic device sends the filename of the first distributed file to the second electronic device, the method further includes: The first electronic device generates a first transmission data packet based on the first file handle object; wherein the first transmission data packet contains the first file handle object; The first electronic device replaces the first file handle object in the first transmission data packet with the file name and preset placeholder of the first distributed file to obtain a second transmission data packet; wherein, the first file handle object is stored in the first byte of the first transmission data packet, and the file name and preset placeholder are stored in the second byte of the second transmission data packet, the first byte and the second byte are of the same size, and the position of the first byte in the first transmission data packet corresponds to the position of the second byte in the second transmission data packet; Wherein, the first electronic device sends the file name of the first distributed file to the second electronic device, including: The first electronic device sends the second transmission data packet to the second electronic device.

5. The cross-device data processing method according to claim 3 or 4, characterized in that, The first electronic device sends the second transmission data packet to the second electronic device, including: The first electronic device performs serialization processing on the second transmitted data packet to obtain the corresponding first serialized data; The first electronic device sends the first serialized data to the second electronic device.

6. The cross-device data processing method according to any one of claims 3-5, characterized in that, The first electronic device generates a first transmission data packet based on the first file handle object, including: The first application of the first electronic device generates a first transmission data packet based on the first file handle object; The process further includes, after the first electronic device generates the first transmission data packet based on the first file handle object: The first application sends the first transmission data packet to the distributed Binder management module of the first electronic device; The distributed Binder management module receives the first transmission data packet and sends a creation instruction for the first distributed file to the distributed file module of the first electronic device based on the first file handle object in the first transmission data packet. The distributed file module creates the first distributed file based on the creation instruction and sends a creation success instruction to the distributed Binder management module; The first electronic device replaces the first file handle object in the first transmission data packet with the filename of the first distributed file to obtain a second transmission data packet, including: In response to the creation success instruction, the distributed Binder management module replaces the first file handle object in the first transmission data packet with the file name of the first distributed file to obtain the second transmission data packet.

7. The cross-device data processing method according to claim 5 or 6, characterized in that, The first electronic device serializes the second transmission data packet to obtain corresponding first serialized data, including: The distributed Binder management module of the first electronic device performs serialization processing on the second transmission data packet to obtain the first serialized data; Wherein, the first electronic device sends the first serialized data to the second electronic device, including: The distributed Binder management module sends the first serialized data to the second electronic device through the communication module of the first electronic device.

8. A cross-device data processing method, applied to a second electronic device, characterized in that, The method includes: The second electronic device receives the file name of a first distributed file from the first electronic device; wherein, the first distributed file is created by the first electronic device based on a first file handle object of a preset file, and the second distributed file in the second electronic device is used to support data access between the first electronic device and the second electronic device, the preset file is used to store preset data, the preset data is the result of the second electronic device performing a target service, and the first file handle object is used by the first electronic device to return the preset data in the first distributed file to the preset file; The second electronic device opens the corresponding second distributed file based on the file name and obtains a second file handle object of the second distributed file; wherein, the second file handle object is used to obtain the preset data from the second distributed file; The second distributed file of the second electronic device obtains the preset data through the second file handle object and transmits the preset data to the first distributed file of the first electronic device, so that the first electronic device returns the preset data in the first distributed file to the preset file through the first file handle object.

9. The cross-device data processing method according to claim 8, characterized in that, Before the first electronic device acquires the first file handle object of the preset file, the method further includes: The second electronic device sends a first request to the first electronic device; wherein the first request is used by the second electronic device to request the first electronic device to obtain a first file handle object of the preset file.

10. The cross-device data processing method according to claim 8 or 9, characterized in that, The second electronic device receives the file name of the first distributed file from the first electronic device, including: The second electronic device receives a second transmission data packet sent by the first electronic device; wherein the second transmission data packet is obtained by the first electronic device replacing the first file handle object in the first transmission data packet with the file name, and the first transmission data packet is generated by the first electronic device based on the first file handle object.

11. The cross-device data processing method according to claim 10, characterized in that, The second electronic device receives a second transmission data packet sent by the first electronic device, including: The second electronic device receives the first serialized data sent by the first electronic device and performs deserialization processing on the first serialized data to obtain the corresponding second transmission data packet; wherein, the first serialized data is obtained by the first electronic device performing serialization processing on the second transmission data packet.

12. The cross-device data processing method according to claim 11, characterized in that, The second electronic device opens the corresponding second distributed file based on the file name and obtains the second file handle object of the second distributed file, including: The second electronic device opens the corresponding second distributed file based on the file name in the second transmission data packet and obtains the second file handle object of the second distributed file. The method further includes, after the second electronic device opens the corresponding second distributed file based on the file name and obtains the second file handle object of the second distributed file: The second electronic device replaces the file name in the second transmission data packet with the second file handle object to obtain the third transmission data packet.

13. The cross-device data processing method according to claim 11 or 12, characterized in that, The second electronic device receives the first serialized data sent by the first electronic device and performs deserialization processing on the first serialized data to obtain the corresponding second transmission data packet, including: The distributed Binder management module of the second electronic device receives the first serialized data sent by the first electronic device through the communication module of the second electronic device; The distributed Binder management module performs deserialization on the first serialized data to obtain the corresponding second transmission data packet.

14. The cross-device data processing method according to claim 12 or 13, characterized in that, The second electronic device opens the corresponding second distributed file based on the file name in the second transmission data packet, and obtains the second file handle object of the second distributed file, including: The distributed Binder management module of the second electronic device sends an open command to the distributed file module of the second electronic device based on the file name; wherein the open command includes the file name; In response to the open command, the distributed file module opens the second distributed file corresponding to the file name and sends the second file handle object of the second distributed file to the distributed Binder management module. The second electronic device replaces the file name in the second transmission data packet with the second file handle object to obtain a third transmission data packet, which includes: The distributed Binder management module of the second electronic device replaces the file name in the second transmission data packet with the second file handle object to obtain the third transmission data packet; The process further includes, after the second electronic device replaces the file name in the second transmission data packet with the second file handle object to obtain the third transmission data packet: The distributed Binder management module sends the third data packet to the second application of the second electronic device.

15. The cross-device data processing method according to claim 14, characterized in that, The second distributed file of the second electronic device obtains the preset data through the second file handle object, and transmits the preset data to the first distributed file of the first electronic device, including: The second application returns the acquired preset data to the second distributed file through the second file handle object in the third transmission data packet; The second distributed file transmits the preset data to the first distributed file of the first electronic device.

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

17. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed in an electronic device, cause the electronic device to perform the method as described in any one of claims 1 to 15.

Images