A cross-device data processing method and an electronic device

Abstract

The application provides a cross-device data processing method and an electronic device, and relates to the technical field of electronic devices. The method is applied to a first electronic device and comprises the following steps: the first electronic device executes a target service in response to receiving a calling request of a second electronic device; the first electronic device sends a connection request to the second electronic device to request to establish a first communication connection between the first electronic device and the second electronic device when the first electronic device obtains corresponding target data by executing the target service; the first electronic device executes re-networking in response to a connection failure signal to complete the first communication connection between the first electronic device and the second electronic device in the process of establishing the first communication connection between the first electronic device and the second electronic device; the connection failure signal is used to indicate that there is a preset conflict in the first communication connection. After the first communication connection between the first electronic device and the second electronic device is established, the first electronic device returns the target data to the second electronic device based on the first communication connection.

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 use the more convenient electronic device according to different scenarios, and cross-device calls are becoming increasingly common. For example, a tablet (PAD) calls the camera function of a mobile phone, or mobile phone 1 calls the camera function of mobile phone 2, etc.

[0003] During cross-device calls, data transfer typically occurs between the various electronic devices. Cross-device call failures can occur during these processes. Summary of the Invention

[0004] This application provides a cross-device data processing method and an electronic device that can realize data transmission for cross-device calls.

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

[0006] Firstly, a cross-device data processing method is provided, applicable to electronic devices. The method includes: a first electronic device, in response to receiving a call request from a second electronic device, executing a target service. Upon obtaining corresponding target data by executing the target service, the first electronic device sends a connection request to the second electronic device; the connection request is used to request the establishment of a first communication connection between the first and second electronic devices. During the establishment of the first communication connection, the first electronic device, in response to a connection failure signal, performs a re-networking operation to complete the first communication connection; the connection failure signal indicates a preset conflict in the first communication connection. After establishing the first communication connection, the first electronic device returns the target data to the second electronic device based on the first communication connection.

[0007] By adopting the above technical solution, if a P2P conflict occurs during the process of establishing a P2P connection between the first electronic device and the second electronic device, the first electronic device can preempt the network, re-establish the network, and establish a P2P connection with the second electronic device to achieve communication with the second electronic device.

[0008] In one possible implementation, after the first electronic device executes the target service and obtains the corresponding target data, the method further includes: the first electronic device sending a first acquisition request to the second electronic device to request a first file handle object of a preset file of the second electronic device. The first file handle object is used by the second electronic device to create a first distributed file, and the preset file is used to store the target data. The first distributed file and a second distributed file in the first electronic device support data access between the first and second electronic devices. The first file handle object is used by the second electronic device to return the target data from the first distributed file to the preset file. The first electronic device receives the filename of the first distributed file sent by the second electronic device.

[0009] In one possible implementation, sending a connection request to a second electronic device includes: the first electronic device sending a connection request to the second electronic device based on a file name.

[0010] In one possible implementation, renetworking includes: a first electronic device sending a second acquisition request to a second electronic device, requesting to reacquire a first file handle object of a preset file from the second electronic device. The first electronic device receives the filename of the first distributed file sent by the second electronic device. The first electronic device performs renetworking based on the filename.

[0011] In one possible implementation, before the first electronic device receives the filename of the first distributed file sent by the second electronic device, the process further includes: the first electronic device deleting the filename of the first distributed file.

[0012] In one possible implementation, the first electronic device returns target data to the second electronic device based on a first communication connection, including: the first electronic device opening a corresponding second distributed file based on the filename of the first distributed file, the second distributed file being used to retrieve the target data; and the second distributed file of the first electronic device transmitting the target data to the first distributed file of the second electronic device, so that the second electronic device returns the target data in the first distributed file to a preset file through a first file handle object.

[0013] In one possible implementation, reconnection includes: if the first electronic device establishes a second communication connection with the third electronic device, the first electronic device disconnects the second communication connection and establishes a first communication connection with the second electronic device.

[0014] In one possible implementation, the first electronic device, in response to a connection failure signal, performs a network reconfiguration, including: displaying a prompt message to the user indicating a transmission problem with the target data; and performing the network reconfiguration in response to the user's confirmation control in the prompt message. Thus, the electronic device can determine whether to preempt the network based on the user's choice. In this way, if the user does not wish to interrupt existing services, data transmission from the first electronic device to the second electronic device can be stopped.

[0015] In one possible implementation, before sending a connection request to the second electronic device, the first electronic device's service coordination module receives the filename of the distributed file sent by the second electronic device.

[0016] In one possible implementation, sending a connection request to the second electronic device includes: the service coordination module sending an open command to the distributed file module of the first electronic device based on the file name, the open command being used to open the second distributed file corresponding to the file name. The distributed file module responds to the open command by sending a connection request to the second electronic device.

[0017] In one possible implementation, the first electronic device, in response to a connection failure signal, performs a renetwork reconfiguration, including: a distributed file module receiving a connection failure signal from a second electronic device, and sending an opening failure message to a service coordination module based on the connection failure signal. The opening failure message indicates that the distributed file module failed to open the second distributed file. Based on the received opening failure message, the distributed file module sends an exception message to the distributed application framework of the first electronic device. The exception message indicates that the first electronic device encountered an error in acquiring the first file handle object. The distributed application framework performs a renetwork reconfiguration based on the exception message. The service coordination module of the first electronic device can save the names of previously received distributed files. Upon receiving a preemption command, it can directly perform a renetwork reconfiguration based on the saved distributed file names, without needing to retrieve the names of the distributed files from the second electronic device again.

[0018] In one possible implementation, displaying the prompt message includes: the distributed application framework of the first electronic device sending a display request to the display interface of the first electronic device based on the exception information, requesting the display interface to display the prompt message. The display interface responds to the display request and displays the prompt message.

[0019] In one possible implementation, in response to a user's action on a confirmation control in a prompt message, the first electronic device performs a re-networking process, including: the display interface, in response to the user's action on a confirmation control in a display request, sends a re-networking request to the distributed application framework, the re-networking request being used to perform the re-networking. The distributed application framework receives the re-networking request and sends it to the service collaboration module. The service collaboration module, upon receiving the re-networking request, sends it to the distributed file module. The distributed file module performs re-networking with the second electronic device based on the re-networking request.

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

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

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

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

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

[0025] Figure 2 A schematic diagram of a P2P conflict scenario provided for an embodiment of this application;

[0026] Figure 3 A schematic diagram illustrating another P2P conflict scenario provided for an embodiment of this application;

[0027] Figure 4 A schematic diagram of the system architecture of an electronic device provided in this application embodiment;

[0028] Figure 5A timing diagram of a mobile phone registration service and a tablet acquisition service provided in an embodiment of this application;

[0029] Figure 6 A schematic diagram showing a call entry point provided in an embodiment of this application;

[0030] Figure 7 A schematic diagram illustrating photo verification as provided in an embodiment of this application;

[0031] Figure 8 A timing diagram for obtaining a File Provider object and a file handle in a camera application, as provided in an embodiment of this application;

[0032] Figure 9 A timing diagram for a camera application to acquire a file handle is provided in an embodiment of this application;

[0033] Figure 10 A schematic diagram of a pop-up window provided for an embodiment of this application;

[0034] Figure 11 A timing diagram for renetworking provided in an embodiment of this application;

[0035] Figure 12 Another timing diagram for renetworking provided in this application embodiment;

[0036] Figure 13 A schematic diagram illustrating another reconfiguration method provided in this application embodiment;

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

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

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

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

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

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

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

[0044] During cross-device calls, data transmission typically occurs between the various electronic devices. Cross-device call failures can occur during these calls.

[0045] One scenario for cross-device communication is when a second electronic device calls a first electronic device. For example, the first electronic device might be a mobile phone, and the second electronic device might be a tablet or a personal computer (PC). Please refer to [link / reference]. Figure 1 ,like Figure 1 In the illustrated cross-device call scenario, a tablet or PC can respond to a user's operation by sending a call command to the mobile phone. This call command can include a shooting command or a scanning command. Upon receiving a shooting command, the mobile phone activates its camera to perform a shooting task. After the camera finishes shooting, the mobile phone directly sends the result (photo) back to the tablet or PC. Alternatively, upon receiving a scanning command, the mobile phone activates its camera to perform a scanning task. After the camera finishes scanning, the mobile phone directly sends the scan result (extracted text) back to the tablet or PC.

[0046] During the process of the mobile phone sending the shooting results back to the tablet or PC, or the process of the mobile phone sending the scanning results back to the tablet or PC, there may be a situation where the tablet or PC fails to call the camera function of the mobile phone, and then the shooting results or scanning results of the mobile phone cannot be sent back to the tablet or PC.

[0047] The aforementioned transmission error may be caused by peer-to-peer (P2P) conflicts.

[0048] P2P is a technology that allows devices to connect directly, enabling one-to-one or one-to-many communication without the need for a local area network (LAN) or access point (AP). The P2P architecture includes a group owner (GO) and a group client (GC). Devices supporting P2P functionality can be called GOs or GCs. In a P2P group, only one GO exists, functioning like an AP. Other GCs can connect to the GO for communication. During group formation, it's used to negotiate which of the two P2P devices will become the GO and which will become the GC, thus forming a new group.

[0049] In this context, a P2P conflict refers to a situation where, assuming the first P2P device negotiates to be GO in the first P2P group, it will be designated GC when a second P2P group is formed; or, assuming the first P2P device negotiates to be GC in the first P2P group, it will be designated GO when a second P2P group is formed. In this case, the formation of the second P2P group fails, preventing the first P2P device from communicating with other P2P devices within the second P2P group.

[0050] In the aforementioned cross-device call scenario, taking the first P2P device as a PC, the second P2P device as mobile phone 1, and the third P2P device as mobile phone 2 as an example, please refer to... Figure 2 ,like Figure 2In the illustrated P2P conflict scenario, assume that phone 1 and phone 2 have established a P2P connection 1, and within the P2P group 1 formed after this connection, phone 1 and phone 2 negotiate and determine that phone 1 is G0 and phone 2 is GC. Then, the PC calls phone 1's camera to take a picture. During the process of phone 1 sending the photo back to the PC, the PC and phone 1 need to establish a P2P connection 2 to form a P2P group 2. Since the PC can only act as GO in the P2P group, phone 1 can only act as GC in P2P group 2. However, phone 1 is already acting as GO in P2P group 1, so there will be a conflict between phone 1's role in P2P group 1 (G0) and its role in P2P group 2 (GC). Therefore, phone 1 cannot establish a P2P connection with the PC, and thus cannot send the photo back to the PC, resulting in the failure of the PC's cross-device call to phone 1.

[0051] Alternatively, in the aforementioned cross-device call scenario, let's take a tablet as the first P2P device, a mobile phone as the second P2P device, and a PC as the third P2P device as an example. Please refer to [link / reference]. Figure 3 ,like Figure 3 In the illustrated P2P conflict scenario, assuming mobile phone 1 and PC have established a P2P connection 3, within the P2P group 3 formed after this connection, since PC can only act as GO (Go), mobile phone 1 can only act as GC (GC). Later, the tablet uses mobile phone 1's camera to take a picture. During the process of mobile phone 1 transferring the photo back to the tablet, mobile phone 1 and tablet need to establish a P2P connection 4 to form P2P group 4. During the formation of P2P group 4, if mobile phone 1 negotiates to be GO and the tablet negotiates to be GC, but mobile phone 1 is already acting as GC in P2P group 3, then there will be a conflict between mobile phone 1's role in P2P group 3 (GC) and its role in P2P group 4 (GO). Therefore, mobile phone 1 cannot establish a P2P connection with the tablet, and thus cannot transfer the photo back to the tablet, leading to the failure of the tablet's cross-device access to mobile phone 1.

[0052] In summary, this application provides a cross-device data processing method that can be applied to electronic devices, such as mobile phones, tablets, personal computers, and laptops. In this cross-device data processing method, if a P2P conflict occurs during the establishment of a P2P connection between a first electronic device and a second electronic device, the first electronic device can preempt the network, re-establish the network, and establish a P2P connection with the second electronic device to achieve communication with the second electronic device.

[0053] This application primarily uses calls between Android devices as an example for illustration, but is not limited to calls between Android devices.

[0054] Please see Figure 4 , Figure 4 A schematic diagram of a system architecture for an electronic device is shown. 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.

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

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

[0057] like Figure 4 As 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.

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

[0059] like Figure 4As 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0079] First, taking the first electronic device as the server and the second electronic device as the client as an example, the specific steps for the second electronic device to call the first electronic device are detailed below. Here, 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. The second electronic device can call the service of the first electronic device. The second electronic device can be a PC, tablet, mobile phone, etc., and the first electronic device can be a tablet, mobile phone, etc.

[0080] In a scenario where a second electronic device invokes a target service of a first electronic device, the first electronic device must first register the target service within its own memory. Then, the second electronic device retrieves the registered target service from the first electronic device. After successfully retrieving the target service, the second electronic device can then invoke the service interface of the first electronic device.

[0081] Taking a tablet as the second electronic device and a mobile phone as the first, and illustrating the scenario where the tablet's note-taking application calls the phone's camera application, the following steps are taken: First, the phone registers with the distributed application management service. Then, the tablet obtains the registered distributed application management service from the phone. After successfully obtaining the phone's distributed application management service, the tablet's note-taking application launches the phone's camera application. The camera takes a picture of the specified content, and the phone sends the captured data back to the tablet's note-taking application.

[0082] Therefore, the overall process of the aforementioned cross-device invocation can include two parts: the mobile phone registration service and the tablet obtaining the mobile phone registration service, and the mobile phone's service data (photo data) being sent back to the tablet. The P2P conflict in this embodiment occurs during the process of the mobile phone's service data being sent back to the tablet.

[0083] Please see Figure 5 , Figure 5 This is a sequence diagram for the mobile phone registration service and the tablet acquisition service. First, the process of the mobile phone registration service is introduced. Mobile phone registration involves the distributed application management service.

[0084] The distributed application management service is located within the system application framework. When the phone boots up, the system application framework, which in turn starts the distributed application management service. After the phone boots up, the communication module starts. Following the communication module, the service collaboration module starts. Therefore, after the service collaboration module starts, the phone can register the distributed application management service with it.

[0085] The mobile phone registration service process is also the process of registering the mobile phone for the distributed application management service. Specifically, it includes: registering the mobile phone's distributed application management service with the distributed service manager (DSM) module (see...). Figure 5 Step 1). Among them, the distributed application management service is located in the system application framework and is started after the mobile phone is powered on.

[0086] 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 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 5 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 5 Step 1.2).

[0087] In this embodiment, after the mobile phone's distributed Binder management module assigns a BinderId to the IBinder object and establishes a mapping relationship, it indicates that the mobile phone's distributed application management service has been successfully registered. The mobile phone's distributed Binder management module can send a registration success notification to the mobile phone's system application framework. At this time, the tablet can obtain the distributed application management service registered by the mobile phone.

[0088] In this context, applications (such as camera applications) are interfaces provided by the distributed application framework, which is located within the system application framework. After the tablet obtains the distributed application management service registered with the phone, it can call the phone's camera application through the distributed application framework to access the services provided by the camera application.

[0089] Secondly, the process of obtaining services on the tablet is introduced. After the distributed application management service on the phone is successfully registered, the tablet can then access the distributed application management service registered on the phone.

[0090] Understandably, the tablet had already opened the notes app before accessing the camera service, and responded to the user's touch input to the notes app's interface by displaying the device and capability lists. In other words, when the tablet receives the user's action, it can assume the user intends to make cross-device calls, thus requiring it to access the distributed application management service provided by the phone.

[0091] The entry point for accessing this feature is located within the tablet's note-taking application. For example... Figure 6 As shown, the PC's note-taking application display interface 601 includes an insert button 602. Upon user touch operation of the insert button 602, the PC displays a list of devices that can provide services and their corresponding capabilities. The displayed devices can be a mobile phone 1 and a tablet 1. The capability list includes the services each device can provide, such as... Figure 6 Mobile phone 1 has functions for taking photos and scanning, while tablet 1 has functions for taking photos and scanning.

[0092] In some examples, the tablet may be making its first call to the phone's camera service, or there may be multiple calls. Therefore, after the tablet first obtains the camera service call information, it can cache this call information locally. Thus, the tablet can first search for the phone and distributed application management service in the local cache. If found, it directly returns the service to the note-taking application; otherwise, it can search for it on the phone.

[0093] The following embodiments of this application specifically describe the process of obtaining the distributed application management service when the tablet first calls the camera service of the mobile phone.

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

[0095] After receiving a request to obtain the "DisApp" service, the tablet's communication module creates a session with the phone (see [reference]). Figure 5 Step 2.2.1). After the channel is successfully created, the tablet's distributed service management module sends a command to the tablet's communication module to obtain the "DisApp" service (refer to...). Figure 5 Step 2.2.2). The tablet's communication module receives the instruction to obtain the "DisApp" service, assembles a message, and sends the message to the phone's communication module.

[0096] After receiving the message, the phone's communication module parses it and obtains the instruction to retrieve the "DisApp" service (see [reference]). Figure 5 Step 2.2.3). The phone's communication module sends this instruction to the phone's distributed Binder management module (refer to...). Figure 5 Step 2.2.3).

[0097] After receiving the instruction, the phone's distributed Binder management module 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. If the service ("DisApp") is found, the corresponding IBinder object (IBinder S1) is determined.

[0098] Then, the phone's distributed service management module returns the IBinder object (IBinder S1) to the phone's distributed Binder management module. Based on the established mapping relationship between IBinder objects and BinderIds, the phone's distributed Binder management module determines the corresponding BinderId (BinderId S1) for this IBinder object (IBinder S1) (see reference). Figure 5 Step 2.2.4). Then, send the BinderId (BinderId S1) to the phone's communication module (see step 2.2.4). Figure 5 Step 2.2.5).

[0099] After receiving the BinderId (BinderId S1) from the "DisApp" service, the phone's communication module assembles it into a message (the message carries BinderId S1) and sends the message to the tablet's communication module.

[0100] The tablet's communication module receives the message, parses the information content, and obtains the BinderId (BinderId S1) for the "DisApp" service (see reference). Figure 5 Step 2.2.6). The tablet's communication module sends the BinderId (BinderId S1) of the "DisApp" service to the tablet's distributed service management module. The tablet's distributed service management module then sends the BinderId (BinderId S1) of the "DisApp" service to the tablet's distributed Binder management module. Then, the distributed Binder management module creates a corresponding local IBinder object (IBinder C1) based on BinderId S1; that is, the distributed Binder management module creates a mapping relationship between BinderId S1 and IBinder C1 and stores this mapping relationship (see [reference]). Figure 5 Step 2.2.7).

[0101] Then, the tablet's distributed Binder management module returns the service name ("DisApp") and the corresponding IBinder object (IBinder C1) to the tablet's communication module, system application framework (see...). Figure 2 Step 5.2.8), finally returned to the tablet's note-taking application (see...). Figure 5 Step 2.3).

[0102] In this embodiment of the application, after the tablet obtains the "DisApp" service registered by the mobile phone, the tablet can open the camera application of the mobile phone.

[0103] The specific process by which the tablet's note-taking application opens the phone's camera application is as follows: The note-taking application sends a "start activity for result (intent)" message to the tablet's system application framework. The Intent contains the URI and device information (let's call it Information 1). The note-taking application makes the call through a locally created IBinder C1, and the system application framework sends Information 1 to the distributed Binder management module in the tablet's service collaboration module.

[0104] The tablet's service collaboration module then sends the aforementioned information 1 to the phone's service collaboration module. The phone's service collaboration module then sends information 1 to the phone's system application framework. The phone's system application framework sends a `startActivity` message to the camera application, which then calls the `startActivity` method to launch the camera using the locally created IBinder S1. Next, the system application framework sends the result data returned by the camera application (camera is now on) to the distributed Binder management module within the phone's service collaboration module. The phone's service collaboration module then sends the result data to the tablet's service collaboration module. Specifically, the phone's communication module sends the result data to the tablet's communication module. The tablet's communication module then forwards the result data to the distributed Binder management module within the tablet's service collaboration module. The tablet's distributed Binder management module then sends the result data to the tablet's system application framework. At this point, the camera is successfully launched.

[0105] Once the tablet accesses the "DisApp" service registered on the phone and the phone's camera app is open, the camera app can respond to the user's shooting action by taking a picture of the information that needs to be transferred back to the notes app. Furthermore, the camera app responds to the user's confirmation of the photo data and sends the acquired photo data back to the notes app. For example, if you insert blackboard content from an offline classroom into the notes app, after the camera app is opened, it responds to the user's touch of the shooting button to take a picture of the blackboard content, obtaining a photo of the blackboard content. Then, the camera app sends the photo of the blackboard content back to the notes app.

[0106] The camera app responds to the user's click of the shutter button, acquires the 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, acquires the confirmed photo. The camera then sends the confirmed photo back to the notes app. In other words, after the camera responds to the user's click of the confirmation button, the camera sends the captured data back to the tablet's notes app. Please refer to [link / reference]. Figure 7 , Figure 7 A schematic diagram illustrating photo verification is shown. (For example...) Figure 7 As shown, during the process of the tablet calling the phone to take a photo, the phone responds to the user's touch operation of the confirmation control 701 and obtains the confirmed photo. The camera then sends the confirmed photo back to the tablet's notes.

[0107] For the camera app, after taking a photo, when it needs to send the photo data back to the notes app, it first needs to obtain the file handle of the notes app's photo cache file, and then write the photo data back to the notes app's photo cache file. Since the file handle is a local resource of the tablet, it cannot be directly obtained by the phone. Therefore, the file handle can be hosted in a service (such as a Provider service). The camera app obtains the Notes app's File Provider object, and then uses that object to obtain the file handle.

[0108] Therefore, the specific steps for sending the phone's photo data back to the tablet 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 note-taking application's photo cache file; and the camera application writing the photo data back to the note-taking application. Here, the photo data refers to the result of the phone executing the distributed application management service. The P2P conflict in this embodiment occurs during the process of the camera application obtaining the file handle of the note-taking application's photo cache file.

[0109] Please see Figure 8 , Figure 8 This diagram illustrates a timing diagram of a camera application obtaining a File Provider object and a file handle according to an embodiment of this application. Figure 8 As shown, after the user clicks the confirmation button, the camera app sends a request to the tablet to obtain the File Provider object from the notes app (see reference). Figure 8 Step 1). Since the Notes app's File Provider object is registered in the tablet's distributed application framework, the camera app sends a request to the phone's distributed application framework to retrieve the Notes app's File Provider object, and the phone's distributed application framework then retrieves the Notes app's File Provider object from the tablet's distributed application framework.

[0110] After the camera app obtains the Notes app's File Provider object, it can then use that File Provider object to retrieve the file handle of the note's photo cache files. The camera app sends a request to the phone's distributed application framework to obtain the file handle from the Notes app (see...). Figure 8 (Step 2). The distributed application framework then sends the retrieval request to the phone's service coordination module, which then forwards the request to the phone's communication module. The phone's communication module assembles the message and sends the retrieval request to the tablet's communication module.

[0111] After receiving the request, the tablet's communication module sends it to the tablet's service collaboration module. The service collaboration module then forwards the request to the tablet's distributed application framework. The file handle of the photo cache file in the notes application is pre-registered in the distributed application framework. Therefore, based on the request, the distributed application framework returns the file handle to the service collaboration module (see reference). Figure 8 Step 2.1). The service collaboration module sends a command to the distributed file module of the tablet to create a distributed file based on the file handle (see step 2.1). Figure 8 Step 2.2).

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

[0113] After successfully creating the distributed file, the distributed file module sends a success message to the tablet's service collaboration module (see reference). Figure 8 Step 2.2.1). The created distributed file will have a corresponding name. The tablet's service collaboration module sends the name of the distributed file to the phone's communication module via the tablet's communication module (see...). Figure 8 Step 2.3). The phone's communication module then sends the name of the distributed file to the phone's service coordination module for processing. The service coordination module can use the obtained name of the distributed file to send an open command to the phone's distributed file module to open the corresponding distributed file (see step 2.3). Figure 8 Step 2.4).

[0114] Then, the phone's distributed file module returns the file handle of the distributed file to the phone's service collaboration module (see...). Figure 8 (Step 2.5). The service collaboration module returns the file handle to the phone's distributed application framework, which then returns it to the camera application.

[0115] The above steps describe how the camera application successfully opens a distributed file based on the obtained name of the distributed file.

[0116] In this embodiment, during the process of the mobile phone's service collaboration module opening a distributed file, the service collaboration module sends an open command to the mobile phone's distributed file module. Upon receiving the open command, the mobile phone's distributed file module initiates a request to create a connection (session) with the tablet's distributed file module based on the open command. Creating a session between the mobile phone's and tablet's distributed file modules refers to establishing a P2P connection. During the process of establishing a P2P connection between the mobile phone's and tablet's distributed file modules, P2P conflicts may occur.

[0117] To address the aforementioned issues, the cross-device data processing method provided in this application embodiment can trigger a re-networking process if a P2P conflict is detected during the establishment of a P2P connection between two devices. After successful re-networking, communication between the two devices is realized.

[0118] Please see Figure 9 , Figure 9 This is a timing diagram illustrating how a camera application acquires a file handle, as provided in an embodiment of this application. Figure 9 As shown, at this point, assuming the camera application has already obtained the Notes application's File Provider object, it uses this File Provider object to obtain the file handle of the Notes' photo cache file. The camera application sends a request to the phone's distributed application framework to obtain the file handle of the Notes application (see...). Figure 9 Step 1). The distributed application framework then sends the retrieval request to the phone's service coordination module, which then forwards the request to the phone's communication module. The phone's communication module assembles the message and sends the retrieval request to the tablet's communication module.

[0119] After receiving the request, the tablet's communication module sends it to the tablet's service coordination module. The service coordination module then forwards the request to the tablet's distributed application framework. Based on the request, the distributed application framework returns a file handle (see reference) to the service coordination module. Figure 9 Step 1.1). The service collaboration module sends a command to the tablet's distributed file module to create a distributed file based on the file handle (see step 1). Figure 9 Step 1.2).

[0120] After successfully creating the distributed file, the distributed file module sends a success message to the tablet's service collaboration module (see reference). Figure 9Step 1.3). The created distributed file will have a corresponding name. The tablet's service collaboration module sends the name of the distributed file to the phone's communication module via the tablet's communication module. The phone's communication module then sends the name of the distributed file to the phone's service collaboration module for processing. The service collaboration module can then send an open command to the phone's distributed file module using the obtained name of the distributed file (refer to...). Figure 9 Step 1.4). The phone's distributed file module initiates a session creation request to the tablet's distributed file module based on this open command (see step 1.4). Figure 9 Step 1.4.1). In fact, the mobile phone's distributed file module sends a connection creation request to the mobile phone's communication module. After the mobile phone's communication module and the tablet's communication module establish a connection, the mobile phone's distributed file module and the tablet's distributed file module complete the connection creation.

[0121] At this point, if a P2P conflict exists, the tablet's distributed file module sends a P2P conflict warning message (e.g., an error code) to the phone's distributed file module (see reference). Figure 9 Step 1.4.2). After receiving this prompt message, the phone's distributed file module indicates that the phone's distributed file module failed to open the distributed file. Then, the phone's distributed file module sends a failure message indicating that opening the distributed file failed to the phone's service coordination module (see...). Figure 9 Step 1.4.3). Based on this failure message, the service collaboration module sends an exception message to the phone's distributed application framework indicating an error in the file handle of the note-taking application (see step 1.4.3). Figure 9 Step 1.5). At this point, the distributed application framework can send a preemption command to the mobile phone's service coordination module (refer to...). Figure 9 Step 1.6), this preemption command is used to instruct the phone to preempt the currently existing P2P connection. Preempting the currently existing P2P connection is also the process by which the phone performs a network reconfiguration.

[0122] After receiving the preemption command, the service coordination module sends the preemption command to the phone's distributed file module. Specifically, the service coordination module sends an open command for the distributed file to the phone's distributed file module, which includes the preemption command (see [reference]). Figure 9 Step 1.7).

[0123] The distributed file module preempts the existing P2P connection based on this preemption command. Assume the existing P2P connection is P2P connection 1, established by the phone with the PC before receiving the shooting command from the tablet. In P2P connection 1, the PC is the GO (Go) role, and the phone is the GC (GC) role. However, in P2P connection 2, which the phone is about to establish with the tablet, the phone, after negotiation with the tablet, assumes the GO role, and the tablet assumes the GC role. Therefore, the P2P conflict at this point is that the phone's role in P2P connection 1 (GC) conflicts with its role in P2P connection 2 (GO).

[0124] The specific steps for the distributed file module to preempt the existing P2P connection include: the mobile phone first disconnects from the PC's P2P connection, and then the mobile phone's distributed file module sends a request to the tablet's distributed file module to establish a P2P connection (establish a session). The mobile phone's distributed file module and the tablet's distributed file module then complete the establishment of a P2P connection.

[0125] After the distributed file module on the phone and the distributed file module on the tablet establish a P2P connection, the phone's distributed file module successfully opens the corresponding distributed file. The phone's distributed file module returns a handle to the distributed file to the phone's service collaboration module (see...). Figure 9 Step 1.8). Then, the service collaboration module returns the handle of the distributed file to the mobile phone's distributed application framework (see step 1.8). Figure 9 In step 1.9), the distributed application framework then returns the handle of the distributed file to the camera application. Thus, the camera application obtains the file handle of the distributed file.

[0126] Then, the camera app can write the captured data back to the tablet. That is, the camera app writes the captured data to the phone's distributed file using the file handle of the distributed file, then passes it to the tablet's distributed file, and finally returns it to the tablet's note-taking app.

[0127] In other words, after the camera app calls the phone's distributed file write data interface via the file handle, it writes the photo data, which is then passed to the tablet's distributed file through the channel created by the phone's and tablet's distributed file modules, and finally returned to the notes app. Thus, the photo data obtained by the phone's camera app is successfully transferred to the tablet's notes app.

[0128] In other examples, after receiving an exception message indicating a file handle error in a request to the note-taking application, the distributed application framework may include the cause of the error (P2P conflict) in the error message. The framework can then display a pop-up message on the phone's interface, prompting the user whether to attempt to seize network access. This allows the electronic device to choose whether to continue the current cross-device call or stop it and continue with its original service, based on the user's preference.

[0129] For example, such as Figure 10 The diagram shown illustrates a pop-up window. Figure 10 In the process, the phone interface 801 displays a pop-up window 802, with a prompt message including: "Continuing the file transfer will be interrupted and the services currently in use by Smart Connect will be reloaded. Do you want to continue?". The phone can receive the user's touch operation on the confirmation control ("Continue") 803 and generate a preemption command. Alternatively, the phone can receive the user's touch operation on the cancel control 804 and cancel the preemption. The services currently in use by Smart Connect here can refer to cross-device access to the camera service.

[0130] Please see Figure 11 , Figure 11 This is a timing diagram for a reconfiguration method provided in an embodiment of this application. For example... Figure 11 As shown, at this point, assuming the camera application has already obtained the Notes application's File Provider object, it uses this File Provider object to obtain the file handle of the Notes' photo cache file. The camera application sends a request to the phone's distributed application framework to obtain the file handle of the Notes application (see...). Figure 11 Step 1). The distributed application framework then sends the retrieval request to the phone's service coordination module, which then forwards the request to the phone's communication module. The phone's communication module assembles the message and sends the retrieval request to the tablet's communication module.

[0131] After receiving the request, the tablet's communication module sends it to the tablet's service coordination module. The service coordination module then forwards the request to the tablet's distributed application framework. Based on the request, the distributed application framework returns a file handle (see reference) to the service coordination module. Figure 11 Step 1.1). The service collaboration module sends a command to the tablet's distributed file module to create a distributed file based on the file handle (see step 1). Figure 11 Step 1.2).

[0132] After successfully creating the distributed file, the distributed file module sends a success message to the tablet's service collaboration module (see reference). Figure 11Step 1.2.1). The created distributed file will have a corresponding name. The tablet's service collaboration module sends the name of the distributed file to the phone's communication module via the tablet's communication module (see...). Figure 11 Step 1.3). The phone's communication module then sends the name of the distributed file to the phone's service coordination module for processing. The service coordination module can then send an open command to the phone's distributed file module using the obtained name of the distributed file (see step 1). Figure 11 Step 1.4). The phone's distributed file module initiates a session creation request to the tablet's distributed file module based on this open command (see step 1.4). Figure 11 Step 1.4.1).

[0133] At this point, if a P2P conflict exists, the tablet's distributed file module sends a P2P conflict warning message (e.g., an error code) to the phone's distributed file module (see reference). Figure 11 Step 1.4.2). After receiving this prompt message, the phone's distributed file module indicates that the distributed file module failed to open the distributed file (refer to...). Figure 11 Step 1.4.3). Then, the phone's distributed file module sends a failure message indicating that opening the distributed file failed to the phone's service collaboration module. Based on this failure message, the service collaboration module sends an exception message indicating that the file handle requested from the note-taking application is abnormal to the phone's distributed application framework (see step 1.4.3). Figure 11 Step 1.5).

[0134] The mobile phone's distributed application framework displays a pop-up window on the phone's interface, which shows a prompt message (see reference). Figure 11 Step 2). The mobile phone's distributed application framework responds to the user's touch operation on the confirmation control in the pop-up window by generating a preemption command (refer to...). Figure 11 Step 2.1).

[0135] Based on this preemption command, the mobile phone's distributed application framework sends a preemption command to the mobile phone's service coordination module (see...). Figure 11 Step 2.2) is used to instruct the preemption of the currently existing P2P connection. After receiving the preemption instruction, the service coordination module then sends the preemption instruction to the mobile phone's distributed file module (see step 2.2). Figure 11 Step 2.3). Here, the service collaboration module sends an open command for the distributed file to the mobile phone's distributed file module again, and this open command includes a preemption command. For the specific steps of the distributed file module preempting the existing P2P connection, please refer to the relevant steps in the aforementioned embodiments.

[0136] After the distributed file module on the phone and the distributed file module on the tablet establish a P2P connection, the phone's distributed file module successfully opens the corresponding distributed file. The phone's distributed file module returns a handle to the distributed file to the phone's service collaboration module (see...). Figure 11 Step 2.4). Then, the service collaboration module returns the handle of the distributed file to the mobile phone's distributed application framework (see step 2.4). Figure 11 In step 2.5), the distributed application framework then returns the handle of the distributed file to the camera application. Thus, the camera application obtains the file handle of the distributed file.

[0137] Then, the camera app can write the captured data back to the tablet. That is, the camera app writes the captured data to the phone's distributed file using the file handle of the distributed file, then passes it to the tablet's distributed file, and finally returns it to the tablet's note-taking app.

[0138] In the example above, if the mobile phone's service collaboration module saves the name of the obtained distributed file, then after receiving the preemption instruction from the mobile phone's distributed application framework, it can directly send the open instruction for the distributed file to the mobile phone's distributed file module again based on the saved name of the distributed file, and preempt the existing P2P connection during the process of opening the distributed file.

[0139] In some embodiments, after the distributed file module of the mobile phone fails to open a distributed file, it sends a failure message to the service coordination module of the mobile phone. At this time, the service coordination module can consider the obtained name of the distributed file to be invalid and delete the name of the distributed file obtained from the service coordination module. Then, after receiving the preemption command, the distributed application framework of the mobile phone can re-trigger the process of obtaining the file handle of the note-taking application across devices.

[0140] Please see Figure 12 , Figure 12 This is a timing diagram for another renetworking method provided in an embodiment of this application. (See diagram below.) Figure 12 As shown, the steps before the mobile phone's distributed file module receives the open command for the distributed file sent by the mobile phone's service collaboration module (refer to...) Figure 12 Steps 1, 1.1, 1.2, 1.2.1, 1.3, and 1.4 are the same as those in the previous embodiments and will not be repeated here.

[0141] The phone's distributed file module initiates a session creation request to the tablet's distributed file module based on this open command (see reference). Figure 12Step 1.4.1). At this point, if a P2P conflict exists, the tablet's distributed file module sends a P2P conflict warning message (e.g., an error code) to the phone's distributed file module (see step 1.4.1). Figure 12 Step 1.4.2). After receiving this prompt message, the phone's distributed file module indicates that the phone's distributed file module failed to open the distributed file. Then, the phone's distributed file module sends a failure message indicating that opening the distributed file failed to the phone's service coordination module (see...). Figure 12 Step 1.4.3). Based on this failure message, the service collaboration module sends an exception message to the phone's distributed application framework indicating an error in the file handle of the note-taking application (see step 1.4.3). Figure 12 Step 1.5).

[0142] The mobile phone's distributed application framework displays a pop-up window on the phone's interface, which shows a prompt message (see reference). Figure 12 Step 1.5). Upon receiving the user's touch operation on the confirmation control in the pop-up window, the mobile phone generates a preemption command (refer to...). Figure 12 Step 2).

[0143] The phone's distributed application framework receives the preemption command and sends a message to the phone's service coordination module to re-trigger the openOutputStream process, which is to re-trigger the process of the phone obtaining the file handle of the tablet's note-taking application across devices (see...). Figure 12 Step 2.1). Specifically, the steps for the mobile phone to obtain the file handle of the tablet's note-taking application across devices (refer to...) Figure 12 Steps 2.3, 2.4.1, and 2.5 are the same as those in the aforementioned embodiments, and will not be repeated here.

[0144] The preemption instruction is carried in the flags of the openOutputStream process. The preemption instruction can occupy a field in the flags, for example, it can be set to true or 1. If the preemption instruction is true or 1, it means that the existing P2P connection will be preempted.

[0145] Among them, after receiving the process of sending a new trigger for openOutputStream, the mobile phone's service coordination module obtains the preemption instruction in the flag bit and then cleans the flag bit, that is, restores the flag bit to its original state.

[0146] After the mobile phone's service collaboration module receives the filename of the newly created distributed file from the tablet's service collaboration module, it sends another command to the mobile phone's distributed file module to open the distributed file (see...). Figure 12Step 2.6) involves a preemption instruction within the open instruction. The distributed file module preempts the existing P2P connection based on this preemption instruction. The specific steps for the distributed file module to preempt the existing P2P connection can be referred to the steps in the aforementioned embodiments.

[0147] After the distributed file module on the phone and the distributed file module on the tablet establish a P2P connection, the phone's distributed file module successfully opens the corresponding distributed file. The phone's distributed file module returns a handle to the distributed file to the phone's service collaboration module (see...). Figure 12 Step 2.7). Then, the service collaboration module returns the handle of the distributed file to the mobile phone's distributed application framework (see step 2.7). Figure 12 In step 2.8), the distributed application framework then returns the handle of the distributed file to the camera application. Thus, the camera application obtains the file handle of the distributed file.

[0148] Then, the camera app can write the captured data back to the tablet. That is, the camera app writes the captured data to the phone's distributed file using the file handle of the distributed file, then passes it to the tablet's distributed file, and finally returns it to the tablet's note-taking app.

[0149] Therefore, the above solution can respond to whether the user's operation choice is preempted, providing a better user experience.

[0150] In some embodiments, please refer to Figure 13 , Figure 13 This is a schematic diagram illustrating another reconfiguration method provided in an embodiment of this application. For example... Figure 13 As shown, the steps before the mobile phone's distributed file module receives the open command for the distributed file sent by the mobile phone's service collaboration module (refer to...) Figure 13 Steps 1, 1.1, 1.2, 1.2.1, 1.3, and 1.4 are the same as those in the previous embodiments and will not be repeated here.

[0151] The phone's distributed file module initiates a session creation request to the tablet's distributed file module based on this open command (see reference). Figure 13 Step 1.4.1). At this point, if a P2P conflict exists, the tablet's distributed file module sends a P2P conflict warning message (e.g., an error code) to the phone's distributed file module (see step 1.4.1). Figure 13 Step 1.4.2). After receiving this prompt message, the phone's distributed file module indicates that the phone's distributed file module failed to open the distributed file. Then, the phone's distributed file module sends a failure message indicating that opening the distributed file failed to the phone's service coordination module (see...). Figure 13Step 1.4.3). Based on this failure message, the service collaboration module sends an exception message to the phone's distributed application framework indicating an error in the file handle of the note-taking application (see step 1.4.3). Figure 13 Step 1.5).

[0152] At this point, the distributed application framework can, upon recognizing a P2P conflict, send a request to the mobile phone's service coordination module to re-trigger the process of opening the output stream (openOutputStream) (see reference). Figure 13 Step 2), which is to re-trigger the process of the phone obtaining the file handle of the tablet's note-taking application across devices. The specific steps for the phone obtaining the file handle of the tablet's note-taking application across devices are the same as those in the aforementioned embodiments (refer to...). Figure 13 Steps 2.1, 2.2, 2.2.1 and 2.3 are the same, and will not be repeated here.

[0153] The openOutputStream process includes a preemption instruction in its flags. This preemption instruction is used to preempt an existing P2P connection.

[0154] After the mobile phone's service collaboration module receives the name of the newly created distributed file from the tablet's service collaboration module, it sends another command to the mobile phone's distributed file module to open the distributed file (see...). Figure 13 Step 2.4) involves a preemption instruction within the open instruction. The distributed file module preempts the existing P2P connection based on this preemption instruction. The specific steps for the distributed file module to preempt the existing P2P connection can be referred to the steps in the aforementioned embodiments.

[0155] Therefore, after the distributed file module on the phone and the distributed file module on the tablet establish a P2P connection, the phone's distributed file module successfully opens the corresponding distributed file. The phone's distributed file module returns a handle to the distributed file to the phone's service collaboration module (see...). Figure 13 Step 2.5). Then, the service collaboration module returns the handle of the distributed file to the mobile phone's distributed application framework (see step 2.5). Figure 13 In step 2.6), the distributed application framework then returns the handle of the distributed file to the camera application. Thus, the camera application obtains the file handle of the distributed file.

[0156] Then, the camera app can write the captured data back to the tablet. That is, the camera app writes the captured data to the phone's distributed file using the file handle of the distributed file, then passes it to the tablet's distributed file, and finally returns it to the tablet's note-taking app.

[0157] In summary, in the cross-device data processing method provided in this application embodiment, if a P2P conflict occurs during the process of establishing a P2P connection between the first electronic device and the second electronic device, the second electronic device can preempt the network, re-establish the network, and establish a P2P connection with the first electronic device to achieve communication with the first electronic device.

[0158] Please refer to the following: Figure 14 , Figure 14 This is a schematic diagram illustrating a cross-device data processing method provided in an embodiment of this application. For example... Figure 14 As shown, before the tablet calls the target service of the mobile phone, a P2P connection has already been established between the mobile phone and the PC. The specific steps of this method may include steps S1401-S1404, as follows:

[0159] Step S1401: The mobile phone responds to the call request received from the tablet and executes the target service.

[0160] The target service can be the camera service in the aforementioned embodiments.

[0161] Step S1402: After the mobile phone obtains the corresponding target data by executing the target service, it sends a connection request to the tablet.

[0162] This connection request is used to establish the first communication connection between the phone and the tablet. This first communication connection can refer to a peer-to-peer (P2P) connection. The target data can be photographed data, scanned text, etc.

[0163] Step S1403: During the process of establishing the first communication connection between the mobile phone and the tablet, the mobile phone responds to the connection failure signal and performs network reconfiguration.

[0164] The connection failure signal indicates that a preset conflict exists in the first communication connection. This preset conflict can be, for example, a P2P conflict. For an explanation of the P2P conflict, please refer to the foregoing embodiments; it will not be repeated here.

[0165] The process of reconnecting the phone to the network involves the phone disconnecting from the PC's P2P connection 1 and establishing a P2P connection (the first communication connection) between the phone and the tablet. Thus, after successfully reconnecting the phone to the network, the first communication connection between the phone and the tablet is established.

[0166] Step S1404: After the mobile phone and the tablet establish the first communication connection, the mobile phone returns the target data to the tablet based on the first communication connection.

[0167] Therefore, in the above-mentioned cross-device data processing method, if a P2P conflict occurs during the process of establishing a P2P connection between the first electronic device and the second electronic device, the first electronic device can preempt the network, re-establish the network, and establish a P2P connection with the second electronic device to achieve communication with the second electronic device.

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

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

[0170] The execution entity of the cross-device data processing method provided in this application can be a cross-device data processing apparatus, and the execution apparatus can be... Figure 15 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 data processing. This application embodiment uses an electronic device performing a cross-device data processing method as an example to illustrate the cross-device data processing method provided by this application embodiment.

[0171] 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 15 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 15The 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.

[0172] Please see Figure 15 , Figure 15 A schematic diagram of the electronic device is shown, such as... Figure 15 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.

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

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

[0175] 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. Different processing units may be independent devices or integrated into one or more processors.

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

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

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

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

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

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

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

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

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

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

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

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

[0188] 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. The GNSS may include Global Positioning System (GPS), Global Navigation Satellite System (GLONASS), BeiDou Navigation Satellite System (BDS), Quasi-Zenith Satellite System (QZSS), and / or Satellite Based Augmentation Systems (SBAS).

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

[0190] 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 MiniLED, a MicroLED, a Micro-OLED, a quantum dot light-emitting diode (QLED), etc.

[0191] Electronic device 300 can achieve shooting functions through ISP, camera 393, video codec, GPU, display screen 394, and application processor. The ISP processes data fed back by camera 393. Camera 393 captures 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 processes digital signals, including digital image signals and other digital signals. For example, when electronic device 300 selects a frequency point, the digital signal processor performs Fourier transforms on the frequency energy. The video codec compresses or decompresses digital video. The NPU (Neural-Network Processing Unit) is a neural network (NN) computing processor that, by borrowing from biological neural network structures, such as the transmission patterns between neurons in the human brain, rapidly processes input information and can continuously learn. The NPU enables intelligent cognitive applications of electronic device 300, such as image recognition, face recognition, speech recognition, and text understanding.

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

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

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

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

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

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

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

[0199] although Figure 15 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.

[0200] This application also provides a chip system, such as... Figure 16 As shown, the chip system 900 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.

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

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

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

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

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

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

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

[0208] 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, characterized in that, Applied to a first electronic device, the method includes: The first electronic device, in response to receiving a call request from the second electronic device, executes the target service; When the first electronic device obtains the corresponding target data by performing the target service, it sends a connection request to the second electronic device; the connection request is used to request the establishment of a first communication connection between the first electronic device and the second electronic device. During the process of establishing the first communication connection between the first electronic device and the second electronic device, the first electronic device, in response to a connection failure signal, generates a preemption command and performs re-networking based on the preemption command to complete the first communication connection between the first electronic device and the second electronic device; the connection failure signal is used to indicate that there is a preset conflict in the first communication connection; wherein, the re-networking based on the preemption command includes: the first electronic device sending a second acquisition request to the second electronic device to request to reacquire the first file handle object of the preset file of the second electronic device, the second acquisition request carrying the preemption command; the first electronic device receiving the file name of the first distributed file sent by the second electronic device, the first electronic device performing the re-networking based on the file name and the preemption command; the first distributed file is created by the second electronic device based on the first file handle object of the preset file, the preset file is used to store the target data; the first distributed file and the second distributed file in the first electronic device are used to support data access between the first electronic device and the second electronic device; After the first electronic device establishes the first communication connection with the second electronic device, the first electronic device returns the target data to the second electronic device based on the first communication connection.

2. The method according to claim 1, characterized in that, After the first electronic device executes the target service and obtains the corresponding target data, the process further includes: The first electronic device sends a first acquisition request to the second electronic device to request a first file handle object of a preset file of the second electronic device. The first file handle object is used by the second electronic device to create a first distributed file. The first file handle object is also used by the second electronic device to return target data from the first distributed file to the preset file. The first electronic device receives the file name of the first distributed file sent by the second electronic device; The step of sending a connection request to the second electronic device includes: The first electronic device sends a connection request to the second electronic device based on the file name.

3. The method according to claim 1, characterized in that, Before the first electronic device receives the filename of the first distributed file sent by the second electronic device, the process further includes: The first electronic device deletes the filename of the first distributed file.

4. The method according to claim 1 or 2, characterized in that, The first electronic device returns the target data to the second electronic device based on the first communication connection, including: The first electronic device opens a corresponding second distributed file based on the file name of the first distributed file, and the second distributed file is used to obtain the target data. The second distributed file of the first electronic device transmits the target data to the first distributed file of the second electronic device, so that the second electronic device returns the target data in the first distributed file to the preset file through the first file handle object.

5. The method according to claim 1 or 2, characterized in that, The first electronic device, based on the file name and the preemption command, performs the renetwork reconfiguration, including: When the first electronic device establishes a second communication connection with the third electronic device, the first electronic device disconnects the second communication connection and establishes the first communication connection with the second electronic device based on the preemption command and the file name.

6. The method according to claim 1 or 2, characterized in that, In response to a connection failure signal, the first electronic device generates a preemption command and performs network reconfiguration based on the preemption command, including: In response to a connection failure signal, the first electronic device displays a prompt message, which is used to inform the user that there is a transmission problem with the target data. The first electronic device responds to the user's operation of the confirmation control in the prompt information, generates the preemption command, and performs network reconfiguration based on the preemption command.

7. The method according to claim 6, characterized in that, Before sending the connection request to the second electronic device, the method further includes: The service coordination module of the first electronic device receives the file name of the distributed file sent by the second electronic device; The step of sending a connection request to the second electronic device includes: The service collaboration module sends an open command to the distributed file module of the first electronic device based on the file name. The open command is used to open the second distributed file corresponding to the file name. In response to the open command, the distributed file module sends a connection request to the second electronic device.

8. The method according to claim 7, characterized in that, In response to a connection failure signal, the first electronic device generates a preemption command and performs network reconfiguration based on the preemption command, including: The distributed file module receives a connection failure signal sent by the second electronic device, and sends an opening failure information to the service coordination module based on the connection failure signal. The opening failure information is used to indicate that the distributed file module failed to open the second distributed file. Based on the received opening failure information, the distributed file module sends an exception message to the distributed application framework of the first electronic device. The exception message is used to indicate that the first electronic device encountered an error in obtaining the first file handle object. The distributed application framework generates a preemption command based on the anomaly information, and executes the renetworking based on the preemption command.

9. The method according to claim 8, characterized in that, The displayed prompt information includes: The distributed application framework of the first electronic device sends a display request to the display interface of the first electronic device based on the abnormal information, in order to request the display interface to display prompt information; The display interface responds to the display request and displays the prompt information; Wherein, in response to the user's operation of the confirmation control in the prompt message, the first electronic device performs a re-networking operation, including: In response to the user's operation on the confirmation control in the display request, the display interface sends a network request to the distributed application framework, and the network request is used to perform the re-networking. The distributed application framework receives the networking request and sends the networking request to the service collaboration module; The service collaboration module receives the networking request and sends the networking request to the distributed file module; The distributed file module performs re-networking with the second electronic device based on the network request.

10. 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 to 9.

11. 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 9.

Images