Cross-device data processing method and electronic device

Abstract

The invention provides a cross-device data processing method and an electronic device, which are applied to a first electronic device, and can create a cache file and execute a target service in response to a received call request of a second electronic device. Under the condition that the target service is executed to obtain the corresponding target data, storing the target data into a cache file; obtaining a first file handle object of the first distributed file, and sending the target data from the cache file to the first distributed file based on the file handle object; the first distributed file and the second distributed file are used for supporting data access between the electronic devices; the second distributed file is created by the second electronic equipment based on a second file handle object of the preset file, and the second file handle object is used for returning target data in the second distributed file to the preset file by the second electronic equipment; and the first electronic equipment returns the target data to the second electronic equipment through the first distributed file. According to the scheme, data transmission of cross-device calling can be realized.

Description

Technical Field

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

[0002] Currently, since different types of electronic devices have different functions, users will use more convenient electronic devices according to different scenarios, and cross-device calling scenarios are becoming more and more common. For example, a mobile phone is easy to carry and has a relatively high pixel, and usually a mobile phone is used to take photos. While the screen of a tablet is relatively larger than that of a mobile phone, and it is more convenient to process photos on the tablet. Then, the tablet can call the camera function of the mobile phone.

[0003] During the above cross-device calling process, there may be a failure in cross-device calling. Summary of the Invention

[0004] Embodiments of this application provide a cross-device data processing method and an electronic device, which are used to solve the transmission problems caused by poor network conditions during the cross-device data transmission process and realize cross-device data transmission.

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

[0006] In a first aspect, a cross-device data processing method is provided, which can be applied to a first electronic device. The method includes: when the first electronic device receives a call request from a second electronic device, it creates a cache file and executes a target service. When the first electronic device executes the target service to obtain corresponding target data, the first electronic device can store the target data in the cache file. The first electronic device obtains a first file handle object of a first distributed file, and based on the first file handle object, sends the target data from the cache file to the first distributed file. Wherein, the first distributed file and the second distributed file are used to support data access between the first electronic device and the second electronic device. The second distributed file is created by the second electronic device based on a second file handle object of a preset file of the second electronic device, and the second file handle object is used for the second electronic device to return the target data in the second distributed file to the preset file. The preset file is used to save the target data. Finally, the first electronic device returns the target data to the second electronic device through the first distributed file. Thus, the second distributed file of the second electronic device can receive the target data returned by the first distributed file and return the target data in the second distributed file to the preset file.

[0007] By adopting the above technical solution, the first electronic device can store the target data in the created cache file after obtaining the target data. During the subsequent transmission of the target data, the first electronic device transmits the target data in the cache file to the first distributed file, and then the first distributed file sends it to the second distributed file of the second electronic device, and thus to the preset file of the second electronic device. Since the cache file is a local file of the first electronic device, the above data transmission process interacts through the local cache file and the distributed file, rather than through the application of the first electronic device that executes the target service and the distributed file. Therefore, the data transmission does not need to depend on the strength of the network environment. In the case of a relatively weak network environment, the cache file on the local device of the first electronic device can also transmit data normally with the first distributed file, improving the user experience of cross-device calling.

[0008] In a possible implementation method of the first aspect, before the first electronic device creates the cache file, it further includes: the first electronic device determines that the network condition where the first electronic device is located does not meet the preset network condition. Among them, the preset network condition can be that the network is in a 5G connection state of Wi-Fi. The first electronic device can obtain the current network connection status. If it is currently in a 5G connection state of Wi-Fi, it means that the current network condition meets the preset network condition; if it is not currently in a 5G connection state of Wi-Fi, it means that the current network condition does not meet the preset network condition. Thus, when the first electronic device determines that the current network connection status is not in a 5G connection state of Wi-Fi, it creates the cache file.

[0009] Alternatively, the preset network condition can be a preset network rate threshold. Among them, the electronic device can judge by obtaining the current network rate and comparing it with the network rate threshold. If the current network rate is less than the network rate threshold, it means that the current network condition does not meet the preset network condition; if the current network rate is not less than the network rate threshold, it means that the current network condition meets the preset network condition. Thus, when the first electronic device determines that the current network rate is less than the network rate threshold, it creates the cache file.

[0010] Thus, when the network condition where the first electronic device is located does not meet the preset network condition, that is, when the network condition is relatively poor, the first electronic device can pre-store the target data obtained by the target application through the created local cache file, which can effectively avoid the ANR problem caused by the excessive response time of the target application due to a weak network environment (poor network condition), improving the user experience. Moreover, the user can perform other operations after the target application exits, without affecting the transmission of the target data.

[0011] In a possible implementation of the first aspect, before the first electronic device obtains the first file handle object of the first distributed file, it further includes: the first electronic device sends a first acquisition request to the second electronic device, for requesting to obtain the second file handle object of the preset file of the second electronic device. Wherein, the first acquisition request is further used to trigger the second electronic device to create a second distributed file based on the second file handle object; the first electronic device receives the file name of the second distributed file sent by the second electronic device.

[0012] In a possible implementation of the first aspect, the above-mentioned first electronic device obtains the first file handle object of the first distributed file, including: the first electronic device obtains the first file handle object corresponding to the first distributed file based on the file name of the second distributed file.

[0013] Wherein, the first electronic device can open the corresponding first distributed file based on the file name of the second distributed file; then, the first electronic device obtains the first file handle object corresponding to the first distributed file.

[0014] In a possible implementation of the first aspect, the method further includes: the first electronic device, in response to receiving a call request from the second electronic device, determines that the network condition where the first electronic device is located meets the preset network condition, and writes the target data into the first distributed file. If the preset network condition is that the network is in the 5G connection state of Wi-Fi, then when the first electronic device determines that the current network connection state is in the 5G connection state of Wi-Fi, that is, when the network state is relatively good, a cache file will not be created. If the preset network condition is a preset network rate threshold, then when the first electronic device determines that the current network rate is not less than the network rate threshold, that is, when the network state is relatively good, a cache file will not be created.

[0015] Then, the first electronic device can directly call the interface of the first distributed file and write the obtained target data into the first distributed file. Thus, the first electronic device can take into account the transmission performance in a strong network environment, achieve faster data transmission in a better network condition, and enhance the user experience of cross-device calling.

[0016] In a possible implementation of the first aspect, the first electronic device returns the target data to the second electronic device through the first distributed file, including: the first electronic device transmits the target data to the second distributed file of the second electronic device through the first distributed file, so that the second electronic device returns the target data in the second distributed file to the preset file through the second file handle object. A connection can be established between the first distributed file and the second distributed file, and the first distributed file transmits the target data in the first distributed file to the second distributed file based on this connection.

[0017] In a possible implementation method of the first aspect, the first electronic device obtains a first file handle object of a first distributed file, and sends target data from a cache file to the first distributed file based on the first file handle object, including: The system application framework of the first electronic device obtains a first file handle object of the first distributed file. The system application framework calls a preset interface and sends the first file handle object and a third file handle object of the cache file to the distributed Binder management module of the first electronic device. The distributed Binder management module sends a file write request to the distributed file module of the first electronic device based on the first file handle object and the third file handle object. In response to the file write request, the distributed file module sends the target data in the cache file to the first distributed file based on the first file handle object and the third file handle object.

[0018] In a possible implementation method of the first aspect, the first electronic device returns target data to the second electronic device through the first distributed file, including: The distributed file module sends a write completion instruction to the system application framework; the write completion instruction is used to instruct the distributed file module to complete sending the target data from the cache file to the first distributed file. In response to the write completion instruction, the system application framework sends a close file write request to the distributed Binder management module; the close file write request is used to instruct the distributed file module to close a file write interface, and the file write interface is used to receive the target data sent by the cache file. The distributed Binder management module sends a close file write request to the distributed file module; in response to the close file write request, the distributed file module closes the file write interface.

[0019] In a possible implementation method of the first aspect, before creating the cache file, it further includes: The first electronic device starts a target application, and the target application is used to execute a target service. The first electronic device starts the target application in the first electronic device in response to receiving a call request from the second electronic device. For example, if a mobile phone receives a camera call request from a tablet, the camera application in the mobile phone will be started.

[0020] In a possible implementation method of the first aspect, creating the cache file includes: The first electronic device creates the cache file in response to starting the target application.

[0021] The data transmission method for creating a local cache file provided by the embodiments of the present application has stronger scenario scalability and can perform video cross-device services with a large amount of data. For example, when a tablet calls the camera application of a mobile phone to record a video, if a local cache file is not created, the video data can only be transmitted across devices after the recording is completed to form a video file. Since video files are generally very large, the transmission of video data will take a long time, and the mobile phone needs to stay on the camera interface for a long time. By adopting the data transmission method for creating a local cache file provided by the embodiments of the present application, the local cache file can be written in segments during video recording, and part of the video data can be transmitted concurrently through the Flush interface, avoiding staying on the camera interface for a long time after the recording is completed and improving the user experience.

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

[0023] In a third aspect, the present application provides a computer-readable storage medium, in which instructions are stored. When the instructions run on a computer, the computer can execute the method described in any one of the first aspects above.

[0024] In a fourth aspect, the present application provides a computer program product containing instructions. When the computer program product runs on a computer, the computer can execute the method described in any one of the first aspects above.

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

[0026] Figure 1 FIG. 1 is a schematic diagram of a scenario for cross-device invocation provided by an embodiment of the present application;

[0027] Figure 2 FIG. 2 is a schematic diagram of a scenario for transmission error provided by an embodiment of the present application;

[0028] Figure 3 FIG. 3 is a schematic diagram of the system architecture of an electronic device provided by an embodiment of the present application;

[0029] Figure 4A timing diagram of a mobile phone registration service and a tablet acquisition service provided by an embodiment of the present application;

[0030] Figure 5 A display schematic diagram of a call entry provided by an embodiment of the present application;

[0031] Figure 6 A schematic diagram of photo confirmation provided by an embodiment of the present application;

[0032] Figure 7 A timing diagram of a camera application obtaining a File Provider object provided by an embodiment of the present application;

[0033] Figure 8 A timing diagram of creating a local cache file and a camera application obtaining a file handle provided by an embodiment of the present application;

[0034] Figure 9 A timing diagram of transmitting camera data provided by an embodiment of the present application;

[0035] Figure 10 Another timing diagram of transmitting camera data provided by an embodiment of the present application;

[0036] Figure 11 A schematic diagram of a cross-device data processing method provided by an embodiment of the present application;

[0037] Figure 12 A schematic diagram of the hardware structure of an electronic device provided by an embodiment of the present application;

[0038] Figure 13 A schematic diagram of the structure of a chip system provided by an embodiment of the present application. Detailed implementation manners

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

[0040] For the convenience of understanding, the terms related to the embodiments of the present application are introduced here in the embodiments of the present application:

[0041] (1) Binder: From the perspective of the Android TM application layer, Binder is the medium through which the client and the server communicate. The server will return a Binder object containing the service calls of the server. Through this Binder object, the client can obtain the services or data provided by the server.

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

[0043] (2) Parcel: Parcel is a container for holding messages and is used for data transmission by leveraging the Binder mechanism. It can carry serialized data and be deserialized at the destination end after IPC transmission. Parcel can also transfer IBinder objects, and at the destination end, it will receive a proxy of the transmitted IBinder object.

[0044] Currently, cross-device scenarios are becoming increasingly common. During cross-device calls, there is usually data transmission between various electronic devices. There may be cases where cross-device calls fail during the cross-device call process.

[0045] Among them, the cross-device call scenario can be a scenario where the second electronic device calls the first electronic device. Taking the first electronic device as a mobile phone and the second electronic device as a tablet or a personal computer (PC) as an example. Please refer to Figure 1 , such as Figure 1 In the schematic diagram of the cross-device call scenario shown, the tablet or PC can send a call instruction to the mobile phone in response to the user's operation. Among them, the call instruction can include a shooting instruction or a scanning instruction. After receiving the shooting instruction, the mobile phone activates the camera in the mobile phone to execute the shooting task. After the shooting by the camera is completed, the mobile phone directly transmits the shooting result (photo) to the tablet or PC. Or, after receiving the scanning instruction, the mobile phone activates the camera in the mobile phone to execute the scanning task. After the scanning by the camera is completed, the mobile phone directly transmits the scanning result (extracted text) to the tablet or PC.

[0046] During the process of the above-mentioned mobile phone transmitting the shooting result to the tablet or PC, or during the process of the mobile phone transmitting the scanning result to the tablet or PC, it may happen that the tablet or PC fails to call the camera function in the mobile phone. In this case, the shooting result or scanning result in the mobile phone cannot be transmitted to the tablet or PC.

[0047] The above transmission error may be caused by insufficient underlying transmission capabilities. Among them, insufficient underlying transmission capabilities may include factors such as 2.4G network connection, bandwidth, concurrency, network environment, interference, etc. If a transmission error occurs, it will be directly fed back to the called application, resulting in anomalies such as an Application Not Response (ANR) dialog box or application crash on the interface of the called application.

[0048] Please refer to Figure 2 , Figure 2 which shows a schematic diagram of a transmission error occurring during a cross-device call. As shown from a in Figure 2 to b in Figure 2 , the tablet calls the camera application of the mobile phone. After the camera application of the mobile phone responds to the user's operation on the shooting button and takes a photo, then the camera application responds to the user's touch operation on the confirmation control 201 and obtains the confirmed photo. After a period of time since the camera application receives the user's touch operation on the confirmation control 201, the interface of the camera application is still as shown in c in Figure 2 , and there is no change in the interface of the camera application, that is, a freeze occurs. As a result, the photo obtained by the camera application cannot be transmitted to the tablet, and the cross-device call fails.

[0049] In some examples, the interface of the camera application can also display a non-responsive prompt message to prompt the user that the camera application is in a non-responsive state.

[0050] In summary, the embodiments of the present application provide a cross-device data processing method, which can be applied to electronic devices. The electronic devices in the embodiments of the present application can be devices such as mobile phones, tablet computers, personal computers, and laptop computers. By adopting the cross-device data processing method, during the process of the second electronic device calling the first electronic device, a cache file is established in the first electronic device to store the call result, and by returning the call result in the cache file to the second electronic device, communication between the first electronic device and the second electronic device is realized.

[0051] The present application mainly takes the call between Android devices as an example for illustration, but is not limited to the call between Android devices.

[0052] Please refer to Figure 3 , Figure 3The schematic diagram of the system architecture of an electronic device is shown. The system architecture of the electronic device can adopt a layered architecture, an event-driven architecture, a microkernel architecture, a microservices architecture, or a cloud architecture. In the embodiments of the present invention, taking the system with a layered architecture as an example, the software structure of the electronic device is illustrated exemplarily.

[0053] The layered architecture divides the software into several layers, and each layer has clear roles and divisions of labor. The communication between layers is through software interfaces. In some embodiments, the system is divided into five layers, from top to bottom are the application layer, the system application framework layer, the collaborative service and scheduling layer, the communication module and device Profile layer, and the kernel layer.

[0054] Among them, the application layer may include a series of application packages. As Figure 3 shown, the application packages may include: Notes, Camera, Mail, Calendar. The application packages may also include Gallery, Calendar, Call, Map, Navigation, WLAN, Bluetooth, Music, Video, Short Message and other applications.

[0055] As Figure 3 shown, the system application framework layer may include ActivityManagerService (AMS), DistributedActivityManagerService (DAMS), PackageManagerService (PMS), DistributedPackageManagerService (DPMS), Service Manager (SM), Distributed Service Manager (DSM), and the system Binder framework. Among them, AMS, PMS and SM are existing system services in the Android system, and the relevant functions are not introduced in detail here. Among them, DAMS, DPMS and DSM are the system functions newly added in the distributed system in the embodiments of the present application, and together they form a distributed application framework for handling service calls between distributed applications in the present application.

[0056] Among them, the distributed application framework can provide a distributed application management service for registering into the distributed service management module to realize service call and management between distributed applications.

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

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

[0059] The service registration module is used for, before device 1 calls the target service of device 2, the service registration module of device 2 registers the target service.

[0060] The service acquisition module is used to, in the scenario where device 1 calls the target service of device 2, after the target service of device 2 is fully registered, the service acquisition module of device 1 acquires the target service of device 2.

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

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

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

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

[0065] The Binder management mapping module is used to manage Binder objects and involves the mapping between local Binders and remote Binders.

[0066] The Binder access authentication module is used to manage the distributed Binder access authentication ability in cross-device or distributed scenarios.

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

[0068] The distributed file management module mainly refers to scenarios such as taking pictures. For example, when a PC wants to call the camera function of a mobile phone, the actual photo cache file is created by the PC. Then, after the mobile phone takes a photo, it needs to obtain the file handle of the photo cache file on the PC side. After obtaining the file handle, it needs to perform a write operation to this photo cache file. That is, cross-device reading and writing is involved here. The distributed file management module can provide cross-device file access. Here, the file handle can be understood as the file path corresponding to the file.

[0069] Among them, the file handle is a relatively complex object, similar to a Binder object.

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

[0071] The device management module refers to the connected devices. The devices may have operations such as going online or offline. Going offline means that the device has been connected and then goes offline, that is, it is no longer connected. Then, all resources related to this device need to be cleaned up or other operations need to be performed. Among them, one or more devices may be connected.

[0072] As Figure 3 shown, the communication module and the device Profile (Device Profile) layer include the communication module, the device Profile module, and the distributed file module.

[0073] Among them, the communication module is the module responsible for transmission, including device discovery connection services and data transmission services, etc. It provides cross-device transmission interfaces and supports automatic networking within the trust ring, one-to-many connections, and waking up sleeping devices. In the scenario of cross-device calls, information is transmitted between devices through the communication module.

[0074] The device Profile module is used to provide device information, provide a service registration interface supported by the device, and other interfaces for querying device services.

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

[0076] The kernel layer includes the Binder driver module, which is mainly used for communication across devices.

[0077] First, taking the first electronic device as the server and the second electronic device as the client as an example, the following details the specific steps for the second electronic device to call the first electronic device. Among them, the server is the end that provides the service, and the client is 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. Among them, the second electronic device can be a PC, a tablet, a mobile phone, etc., and the first electronic device can be a tablet, a mobile phone, etc.

[0078] In the scenario where the second electronic device calls the target service of the first electronic device, first the first electronic device needs to register the target service in its own device, and then the second electronic device obtains the target service registered by the first electronic device. After the second electronic device successfully obtains the target service of the second electronic device, the second electronic device can call the service interface of the first electronic device.

[0079] Taking the second electronic device as a tablet and the first electronic device as a mobile phone, and the note application on the tablet calling the camera application on the mobile phone as an example. In the scenario where the note application on the tablet calls the camera application on the mobile phone for the photo-taking service, first the mobile phone needs to register the distributed application management service in itself, and then the tablet obtains the distributed application management service registered by the mobile phone. After the tablet successfully obtains the distributed application management service of the mobile phone, the note application on the tablet launches the camera application on the mobile phone. After the camera application takes a photo of the specified content, the mobile phone transmits the obtained photo data back to the note application on the tablet.

[0080] Therefore, the overall process of the above cross-device call can include two parts: the mobile phone registers the service and the tablet obtains the service registered by the mobile phone, and the service data (photo data) of the mobile phone is transmitted back to the tablet. The transmission error in the embodiment of this application occurs during the process of transmitting the service data of the mobile phone back to the tablet.

[0081] Please refer to Figure 4 , Figure 4 the sequence diagram for the mobile phone to register the service and the tablet to obtain the service. First, the process of the mobile phone registering the service is introduced. Among them, the mobile phone registers the distributed application management service.

[0082] Among them, the distributed application management service is within the system application framework. When the mobile phone is powered on, the system application framework will be started, that is, the distributed application management service will be started. After the mobile phone is powered on, the communication module is started. After the communication module is started, the service coordination module is started. Therefore, after the service coordination module is started, the mobile phone can register the distributed application management service into the service coordination module.

[0083] Among them, the process of the mobile phone registering the service is also the process of the mobile phone registering the distributed application management service, which specifically includes: registering the distributed application management service of the mobile phone into the distributed service manager (DSM) (refer to Figure 4 Step 1). Among them, the distributed application management service is within the system application framework. After the mobile phone is powered on, the distributed application management service is started.

[0084] The service name (such as "DisApp") and the IBinder object (such as "IBinder S1") of the distributed application management service are stored in the distributed service management module (refer to Figure 4 Step 1.1). Then, the service name and the IBinder object are sent to the distributed Binder management module. The distributed Binder management module caches the IBinder object (the above IBinder S1) and assigns a BinderId (such as "Binder S1") to the IBinder object. That is, a mapping relationship is established between IBinder S1 and Binder S1 (refer to Figure 4 Step 1.1.1). Then, the distributed Binder management module returns the registration result to the system application framework (refer to Figure 4 Step 1.2).

[0085] In the embodiment of the present application, after the distributed Binder management module of the mobile phone assigns a BinderId to the IBinder object and establishes a mapping relationship, it means that the registration of the distributed application management service of the mobile phone is successful. The distributed Binder management module of the mobile phone can send a notification message of successful registration to the system application framework of the mobile phone. At this time, the tablet can obtain the distributed application management service registered by the mobile phone.

[0086] Among them, the application (such as the camera application) is an interface provided by the distributed application framework, and the distributed application framework is within the system application framework. After the tablet obtains the distributed application management service registered by the mobile phone, it can call the camera application of the mobile phone through the distributed application framework and obtain the service provided by the camera application.

[0087] Secondly, the process of obtaining services for a tablet is introduced. After the distributed application management service of a mobile phone is successfully registered, the tablet can obtain the distributed application management service registered by the mobile phone.

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

[0089] Among them, there is a call entry in the note application of the tablet. Figure 5 As shown, an insert button 502 is provided on the display interface 501 of the note application of the PC. After the PC responds to the user's touch operation on the insert button 502, the PC displays the devices that can provide services and the capability list corresponding to the devices on the display interface. The displayed devices may be a mobile phone 1 and a tablet 1. The capability list includes the services that each device can provide, such as Figure 5 Among them, mobile phone 1 corresponds to taking pictures, scanning, etc., and tablet 1 corresponds to taking pictures, scanning, etc.

[0090] In some examples, the tablet may call the camera service of the mobile phone for the first time, or it may call it multiple times. Then, after the tablet obtains the camera service of the camera for the first time, the obtained call information of the camera service can be cached locally. Therefore, the tablet can first search for the mobile phone and distributed application management service from the local cache. If it is found, it will be directly returned to the note application. If it is not found, it can be searched from the mobile phone.

[0091] The embodiment of the present application specifically introduces the process of obtaining the distributed application management service when the tablet calls the camera service of the mobile phone's camera for the first time.

[0092] In the embodiment of the present application, after the distributed application management service of the mobile phone is successfully registered, and in response to the user's touch operation on the call entry of the note application interface, the note application of the tablet can obtain the distributed context of the mobile phone (refer to Figure 4 Step 2), that is, obtaining the "DisApp" service of the mobile phone. Specifically, the system application framework of the tablet sends a request to obtain the "DisApp" service to the distributed service management module of the tablet (refer to Figure 4 Then, the distributed service management module of the tablet sends a request for obtaining the "DisApp" service to the message center (Message Center)-communication module of the second tablet (refer to Figure 4 Step 2.2).

[0093] After the communication module of the tablet receives a request to obtain the "DisApp" service, it creates a channel (session) with the mobile phone (refer to Figure 4 Step 2.2.1). After the channel is successfully created, the distributed service management module of the tablet sends an instruction to obtain the "DisApp" service to the communication module of the tablet (refer to Figure 4 Step 2.2.2). The communication module of the tablet receives the instruction to obtain the "DisApp" service, assembles a message, and sends the message to the communication module of the mobile phone.

[0094] After the communication module of the mobile phone receives the message, it parses the message to obtain the instruction to obtain the "DisApp" service (refer to Figure 4 Step 2.2.3). The communication module of the mobile phone sends the instruction to the distributed Binder management module of the mobile phone (refer to Figure 4 Step 2.2.4).

[0095] After the distributed Binder management module of the mobile phone receives the instruction, it searches for the "DisApp" service in the distributed service management module. Among them, as can be seen from Step 1.1, the distributed service management module stores the service name and the corresponding IBinder object. Thus, the distributed Binder management module can search in the distributed service management module whether the service is stored according to the service name ("DisApp") in the above instruction. If the service ("DisApp" service) is found, the corresponding IBinder object (IBinder S1) is determined.

[0096] Then, the distributed service management module of the mobile phone returns the IBinder object (IBinder S1) to the distributed Binder management module of the mobile phone. The distributed Binder management module of the mobile phone determines the BinderId (BinderId S1) corresponding to the IBinder object (IBinder S1) according to the established mapping relationship between the IBinder object and the BinderId (refer to Figure 4 Step 2.2.4). Then, the BinderId (BinderId S1) is sent to the communication module of the mobile phone (refer to Figure 4 Step 2.2.5).

[0097] After the communication module of the mobile phone receives the BinderId (BinderId S1) of the "DisApp" service, it assembles it into a message (the message carries BinderId S1), and sends the message to the communication module of the tablet.

[0098] The communication module of the tablet receives the message, parses the information content, and obtains the BinderId (BinderId S1) of the "DisApp" service (refer to Figure 4 Step 2.2.6). The communication module of the tablet sends the BinderId (BinderId S1) of the "DisApp" service to the distributed service management module of the tablet. The distributed service management module of the tablet sends the BinderId (BinderId S1) of the "DisApp" service to the distributed Binder management module of the tablet. Then, the distributed Binder management module newly creates a corresponding local IBinder object (IBinder C1) according to BinderId S1, that is, the distributed Binder management module creates a mapping relationship between BinderId S1 and IBinder C1 and stores the mapping relationship (refer to Figure 4 Step 2.2.7).

[0099] Then, the distributed Binder management module of the tablet returns the service name ("DisApp") and the corresponding IBinder object (IBinder C1) to the communication module of the tablet, the system application framework (refer to Figure 4 Step 2.2.8), and finally returns to the note application of the tablet (refer to Figure 4 Step 2.3).

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

[0101] Among them, the specific process of the note application of the tablet opening the camera application of the mobile phone is as follows: The note application sends a startactivity for result(intent) message to the system application framework of the tablet, and the Intent contains the uri and device information (set as information 1). The note application makes a call through the locally created IBinder C1, and the system application framework sends information 1 to the distributed Binder management module in the service collaboration module of the tablet.

[0102] The distributed Binder management module of the tablet then sends the above information 1 to the distributed Binder management module in the service collaboration module of the mobile phone. The distributed Binder management module of the mobile phone sends information 1 to the system application framework of the mobile phone. The system application framework of the mobile phone sends a start activity message to the camera application and starts the camera by calling the start activity method through the locally created IBinder S1. Then, the system application framework sends the result data returned by the camera application (the camera has been turned on) to the distributed Binder management module in the service collaboration module of the mobile phone. The service collaboration module of the mobile phone sends the result data to the service collaboration module of the tablet. Specifically, the communication module of the mobile phone sends the result data to the communication module of the tablet. The communication module of the tablet then forwards the result data to the distributed Binder management module in the service collaboration module of the tablet. The distributed Binder management module of the tablet sends the result data to the system application framework of the tablet. At this time, the camera is successfully turned on.

[0103] In the embodiment of the present application, during the process of turning on the above camera application, after the system application framework of the mobile phone receives information 1, that is, receives the message to start the camera application, in addition to sending a start instruction to the camera application, it will also create a local cache file.

[0104] Thus, after the tablet obtains the "DisApp" service registered by the mobile phone, the local cache file is successfully created, and the camera application of the mobile phone is opened, the camera application can take pictures of the information that needs to be uploaded to the note in response to the user's shooting operation. And the camera application, in response to the user's confirmation operation on the captured data, sends the obtained captured data back to the note application. For example, when inserting the blackboard writing content of an offline class in the note application, then, after the camera application is opened, the camera application takes a picture of the blackboard writing content in response to the user's touch operation on the shooting button, obtaining a blackboard photo (the captured data of the blackboard writing content). Then, the camera application sends the blackboard photo back to the note application. Among them, the captured data is the target data.

[0105] Among them, the camera application, in response to the user's click operation on the shooting button, obtains a photo, and then can confirm whether the photo meets the user's requirements. The camera, in response to the user's click operation on the confirmation button, that is, after confirming that the photo meets the user's requirements, obtains the confirmed photo. The camera sends the confirmed photo back to the note. That is to say, after the camera responds to the user's click operation on the confirmation button, the camera sends the captured data back to the note on the tablet. Please refer to Figure 6 , Figure 6 which shows a schematic diagram of photo confirmation. As Figure 6As shown, during the process of the tablet invoking the phone's camera to take a photo, the phone responds to the touch operation of the user's confirmation control 601 and obtains the confirmed photo. The camera uploads the confirmed photo back to the note on the tablet.

[0106] Among them, for the camera application, after taking a photo, when it needs to upload the photo-taking data back to the note application, it needs to first obtain the file handle of the photo cache file of the note application, and then based on the file handle, upload the photo-taking data to the photo cache file of the note application. Since the handle is a local resource of the tablet, the phone cannot directly obtain it. Therefore, the file handle can be hosted in a certain service (such as the Provider service), and the camera application obtains the FileProvider object (file provider object) of the note application, and then obtains the file handle through this object.

[0107] Therefore, the specific steps for the phone's photo-taking data to be uploaded to the tablet include: the camera application obtains the IContent Provider object (i.e., the File Provider object) of the note application, the camera application obtains the file handle of the photo cache file of the note application, and the camera application writes the photo-taking data back to the note application. Among them, the photo-taking data refers to the result of the phone executing the distributed application management service.

[0108] Please refer to Figure 7 , Figure 7 which is the timing diagram for obtaining the File Provider object of the note provided by the embodiment of this application. As Figure 7 shown, when the camera application uses IBinder S1 to call the corresponding interface of the note application, it enters the distributed Binder management module of the service collaboration module, and the input parameters in the interface call (by calling the transact method) can be encapsulated in a Parcel package (i.e., the request parcel).

[0109] The distributed Binder management module of the service collaboration module processes the request parcel (set as reqA) (refer to Figure 7 step 1.3). Specifically, first, it is judged whether reqA contains an anonymous IBinder object. By parsing reqA, it can be determined that reqA does not contain an anonymous IBinder object.

[0110] It is understandable that if the IBinder object is not included, the distributed Binder management module can directly perform serialization processing on the Parcel package. If the IBinder object is included, after mapping and replacing the IBinder object, serialization processing is performed on the Parcel package. Since reqA is only used to obtain the File Provider object of the note and no further calls are required, there is no anonymous IBinder object in reqA. Then, the distributed Binder management module can directly perform serialization processing on reqA.

[0111] After the distributed Binder management module performs serialization processing on reqA, it forwards the call request (reqA byte stream) to the communication module of the mobile phone (refer to Figure 7 Step 1.4). The communication module of the mobile phone assembles a message and sends the reqA byte stream to the communication module of the tablet. The message contains the BinderId S1 of the "DisApp" service.

[0112] The communication module of the tablet receives the message and parses it (refer to Figure 7 Step 1.5), determines that the message carries a Binder call request, and then sends the message to the distributed Binder management module of the tablet. The distributed Binder management module of the tablet parses the message to obtain the reqA byte stream (i.e., the serialized reqA), deserializes the reqA byte stream to obtain reqA. The distributed Binder management module of the tablet finds the corresponding local IBinder object (IBinder C1) according to the received BinderId S1 (refer to Figure 7 Step 1.5.1). Then it calls transact to perform the actual service call (that is, obtain the File Provider object of the note) (refer to Figure 7 Step 1.5.2).

[0113] The system application framework of the tablet writes the File Provider object of the note application into the Parcel package, that is, Reply Parcel (set as repB), and then returns repB to the camera application of the mobile phone. Specifically, the system application framework calls ontransact (refer to Figure 7Step 1.6). The distributed Binder management module of the tablet processes repB. Specifically, it checks if repB contains IFile Pc (equivalent to an IBinder object), and then assigns BinderId2 to the IFilePc object (that is, establishes a mapping relationship between the IFilePc object and BinderId2). Then, the distributed Binder management module serializes repB. Before serialization, the IFilePc object in repB is replaced with BinderId2, and the generated new ReplyParcel is set as repB1, and other spaces belonging to the IFile Pc object are filled with placeholders (refer to Figure 7 Step 1.6.1).

[0114] Then, the tablet sends the serialized repB1 (i.e., the repB1 byte stream) to the mobile phone. Specifically, the distributed Binder management module of the tablet constructs a message that carries the repB1 byte stream (refer to Figure 7 Step 1.6.2). The distributed Binder management module of the tablet sends the constructed message to the communication module of the tablet, and then the communication module of the tablet sends the message to the communication module of the second electronic device.

[0115] After the communication module of the mobile phone receives the message, it parses the message to obtain the message corresponding to repB1. Then, the communication module of the mobile phone sends the parsed message to the distributed Binder management module of the mobile phone for processing.

[0116] That is, the distributed Binder management module of the mobile phone processes the repB1 byte stream (refer to Figure 7 Step 1.7). Specifically, first, the repB1 byte stream is deserialized to obtain the repB1 object. Then, since the mobile phone can determine that repB1 contains an IBinder object, that is, by parsing repB1, it can be determined that the corresponding BinderId2 is written in repB1. Therefore, the mobile phone can obtain the BinderId2 of the tablet, and then create an Ibinder object of the mobile phone (set as IFilePs), where a mapping relationship is established between BinderId2 and the IFilePs object of the mobile phone. Then, the distributed Binder management module of the mobile phone writes the created IFilePs object into the reply package (set as repB2) and returns it to the camera application (refer to Figure 7 Step 1.8).

[0117] After the camera application obtains the File Provider object of the note application, it can obtain the file handle of the photo cache file of the note based on this FileProvider object.

[0118] Please refer to Figure 8 , Figure 8 FIG. shows a timing diagram of creating a local cache file and the camera application obtaining a file handle according to an embodiment of the present application. As Figure 8 shown, the system application framework of the tablet sends a request to start the camera to the distributed Binder management module of the tablet. The distributed Binder management module of the tablet sends a request to start the camera to the distributed Binder management module of the mobile phone. The distributed Binder management module of the mobile phone sends a request to start the camera to the system application framework of the mobile phone. After receiving the request to start the camera, the system application framework of the mobile phone creates a local cache file and sends a request to start the camera to the camera application. After receiving the request to start the camera sent by the system application framework, the camera application starts the camera.

[0119] In an embodiment of the present application, after creating a local cache file, the system application framework can set a cache flag. For example, if the cache flag is true or 1, it means that the system application framework has created a local cache file.

[0120] In response to the user's operation, the camera application takes a photo and obtains the photo. Then, after the camera application responds to the user's click operation on the confirmation button, it sends a request to obtain the File Provider object of the note application to the tablet. The specific steps for the camera application to obtain the File Provider object please refer to Figure 7 , Figure 8 The specific steps are not shown.

[0121] Among them, after the camera application responds to the user's click operation on the confirmation button, the camera application can store the obtained photo data in the local cache file.

[0122] After the camera application obtains the File Provider object of the note application, the camera application sends a request to obtain the file handle (file path) of the note application to the system application framework of the mobile phone. The system application framework then sends a request to obtain the file handle (file path) of the note application to the distributed Binder management module and passes in the set cache flag (refer to Figure 8Step 1.1). When the camera application calls the corresponding interface of the note application using the IFilePs object, it enters the distributed Binder management module of the service collaboration module. The input parameters in the interface call (by calling the transact method) can be encapsulated in a Parcel package (i.e., the request parcel).

[0123] The distributed Binder management module receives a file handle request message (denoted as reqD) (refer to Figure 8 Step 1.2), and processes reqD (refer to Figure 8 Step 1.3). Specifically, first, it determines whether reqD contains an anonymous IBinder object. By parsing reqD, it can be determined that reqD does not contain an anonymous IBinder object. It can be understood that since reqD is only used to obtain the file handle of the note and does not require further calls, it can be determined that reqD does not contain an anonymous IBinder object. Then, the distributed Binder management module can directly perform serialization processing on reqD.

[0124] Among them, the distributed Binder management module parses the received cache flag bit. Through the cache flag bit, it can be known whether a local cache file has been created in the system application framework.

[0125] After the distributed Binder management module performs serialization processing on reqD, it forwards the call request (reqD byte stream) to the communication module of the mobile phone (refer to Figure 8 Step 1.4). The communication module of the mobile phone assembles a message and sends the reqD byte stream to the communication module of the tablet. The message contains BinderId2.

[0126] The communication module of the tablet receives the message and parses it (refer to Figure 8 Step 1.5), determines that the message carries a Binder call request, and then sends the message to the Binder management module of the tablet. The Binder management module of the tablet parses the message to obtain the serialized reqD (reqD byte stream), deserializes the reqD byte stream to obtain reqD. The distributed Binder management module of the tablet finds the corresponding local IBinder object (IFilePc) according to the received BinderId2 (refer to Figure 8 Step 1.5.1). Then, based on IFilePc, it calls transact for actual service calls (i.e., obtaining the file handle of the note) (refer to Figure 8 Step 1.5.2).

[0127] The note application of the tablet pre-registers the File Descriptor object Fdc in the system application framework of the tablet. Then, the system application framework of the tablet writes the File Descriptor object Fdc into a Parcel package, that is, Reply Parcel (set as repE) (refer to Figure 8 Step 1.5.3), and then returns repE to the camera application of the mobile phone. Specifically, the note application calls on Transact (refer to Figure 8 Step 1.6). The distributed Binder management module of the tablet processes repE. Specifically, it checks whether Fdc (equivalent to the IBinder object) is included in repE (refer to Figure 8 Step 1.6.1), and then sends an instruction to create a distributed file to the distributed file module of the tablet (refer to Figure 8 Step 1.6.2). Let the name of the created distributed file be "DisPicture".

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

[0129] After the distributed file module successfully creates the distributed file, it sends an instruction of successful creation to the distributed Binder management module of the tablet (refer to Figure 8 Step 1.6.3). Among them, the created distributed file will have a corresponding name. The distributed Binder management module of the tablet writes the name of the distributed file to the original position of Fdc in repE and takes up the position, generating repE1 (refer to Figure 8 Step 1.6.4). Then, the distributed Binder management module performs serialization processing on repE1.

[0130] Then, the tablet sends the serialized repE1 (i.e., the repE1 byte stream) to the mobile phone. Specifically, the distributed Binder management module of the tablet constructs a message, and this message carries repE1 (refer to Figure 8In step 1.6.5), the name "DisPicture" corresponding to the distributed file is included in repE1. The distributed Binder management module of the tablet sends the constructed message to the communication module of the tablet, and then the communication module of the tablet sends the message to the communication module of the mobile phone.

[0131] After receiving the message, the communication module of the mobile phone parses the message to obtain the message corresponding to repE1. Then, the communication module of the mobile phone sends the parsed message to the distributed Binder management module of the mobile phone for processing.

[0132] That is, the distributed Binder management module of the mobile phone processes the repE1 byte stream (refer to Figure 8 step 1.7). Specifically, the distributed Binder management module of the mobile phone performs deserialization processing on the repE1 byte stream to obtain the repE1 object. Then, the distributed Binder management module can detect that the distributed file name is included in repE1, that is, the relevant information of the corresponding file handle is contained in repE1 (refer to Figure 8 step 1.7.1). When the cache flag bit is true, the distributed Binder management module can open the corresponding distributed file by reading the name of the distributed file ("DisPicture") in repE1 (refer to Figure 8 step 1.7.2).

[0133] Among them, when the distributed Binder management module opens the corresponding distributed file, it will call the interface of the distributed file - open the cache file "opencachefile()", and the input parameters are nodeid: the identifier (id) of the peer device, and fdname: the file name. It can be understood that the corresponding distributed file opened by the distributed Binder management module can be regarded as the cache file in the mobile phone.

[0134] Then, the distributed file module of the mobile phone returns the file handle of the distributed file to the distributed Binder management module of the mobile phone (refer to Figure 8 step 1.7.3). The distributed Binder management module writes the file handle VFd into the reply packet (set as repE2) (refer to Figure 8 step 1.7.4), and returns it to the system application framework (refer to Figure 8 step 1.8).

[0135] After receiving the file handle VFd, the system application framework can write the photo data of the camera application through the Flush interface. Specifically, the system application framework can call the flush interface and pass the file handle of the local cache file (set as Fd1) and the file handle of the distributed file (set as VFd) to the distributed Binder management module (refer to Figure 8 Step 1.9). The distributed Binder management module sends a file write request to the distributed file module through the flush interface (preset interface) (refer to Figure 8 Step 1.10). The file write request also includes the file handle Fd1 of the local cache file (the third file handle object) and the file handle VFd of the distributed file (the first file handle object), indicating that the distributed file module should transfer the photo data in the local cache file to the distributed file. After receiving the file write request, the distributed file module moves the photo data in the local cache file created by the system framework to the distributed file (refer to Figure 8 Step 1.11).

[0136] Among them, the called flush interface is: int flush(), and the input parameters are: ParcelfileDescriptor (file descriptor data packet) srcPfd, and ParcelfileDescriptor remotePfd. Among them, srcPfd refers to the file handle of the local cache file, and remotePfd refers to the file handle of the distributed file.

[0137] After that, after the system application framework receives the instruction indicating the completion of the move (write completion instruction) sent by the distributed file module, it calls the Close interface to close the corresponding distributed file. The write completion instruction is used to indicate that the distributed file module has completed sending the target data from the cache file to the first distributed file. Specifically, the system application framework sends a close file write request to the distributed Binder management module (refer to Figure 8 Step 1.12). The distributed Binder management module sends a close file write request to the distributed file module (refer to Figure 8 Step 1.13). After receiving the close file write request, the distributed file module sends the camera data to the tablet through a remote procedure call (RPC) to complete the writing of the specified file.

[0138] Among them, the called Close interface is: int Close(), and the input parameter is: remotePfd: the file handle of the distributed file.

[0139] Among them, the distributed file module of the mobile phone can initiate a request to create a session with the distributed file module of the tablet based on the received open instruction. In fact, the distributed file module of the mobile phone sends a request to create a connection to the communication module of the mobile phone. After the communication module of the mobile phone creates a connection with the communication module of the tablet, the distributed file module of the mobile phone and the distributed file module of the tablet complete the creation of the connection.

[0140] Thus, after the distributed file module of the mobile phone receives the photo-taking data, it is transmitted into the distributed file of the tablet through the channel created by the distributed file module of the mobile phone and the distributed file module of the tablet as described above, and then returned to the note application. The photo-taking data obtained by the camera application of the mobile phone is successfully transmitted into the note application of the tablet.

[0141] In summary, when the first electronic device receives a call request from the second electronic device, it can create a local cache file in the first electronic device. When returning the call result to the second electronic device, it sends the data pre-obtained in the local cache file to the second electronic device, realizing cross-device data transmission with the second electronic device.

[0142] By adopting the above technical solution, the first electronic device can store the target data in the created cache file after obtaining the target data. In the subsequent process of target data transmission, the first electronic device transmits the target data in the cache file to the first distributed file, and then the first distributed file sends it to the second distributed file of the second electronic device, and thus to the preset file of the second electronic device. Since the cache file is a local file of the first electronic device, the above data transmission process interacts through the local cache file and the distributed file, rather than through the application that executes the target service on the first electronic device and the distributed file. Then, the data transmission does not need to depend on the strength of the network environment. In the case of a relatively weak network environment, the local cache file of the first electronic device can also transmit data normally with the first distributed file, improving the user experience of cross-device calls.

[0143] In some feasible embodiments, after the first electronic device receives a call request from the second electronic device, it can determine whether to create a local cache file based on the current network status. Among them, the first electronic device can preset network conditions for the network status. If the current network status meets the preset network conditions, then it can not create a local cache file. If the current network status does not meet the preset network conditions, then the first electronic device can create a local cache file.

[0144] Among them, the preset network condition can be that the network is in the 5G connection state of Wi-Fi. Alternatively, the preset network condition can be a preset network rate threshold. Among them, the electronic device can obtain the current network rate and make a judgment with the network rate threshold. If the current network rate is less than the network rate threshold, it means that the current network condition does not meet the preset network condition; if the current network rate is not less than the network rate threshold, it means that the current network condition meets the preset network condition.

[0145] This application does not limit the setting of the preset network condition, which can be adjusted according to the actual network condition.

[0146] In the embodiments of this application, still taking the first electronic device as a mobile phone and the second electronic device as a tablet, and the tablet invoking the camera application of the mobile phone as an example. Assume that the preset network condition is that the network is in the 5G connection state of Wi-Fi. That is to say, the mobile phone obtains the current network connection state. If the current is in the 5G connection state of Wi-Fi, it means that the current network condition meets the preset network condition; if the current is not in the 5G connection state of Wi-Fi, it means that the current network condition does not meet the preset network condition.

[0147] Please refer to Figure 9 , Figure 9 , which is a timing diagram for transmitting camera data provided by the embodiments of this application. As Figure 9 shown, the system application framework of the tablet sends a request to start the camera to the distributed Binder management module of the tablet. The distributed Binder management module of the tablet sends a request to start the camera to the distributed Binder management module of the mobile phone. The distributed Binder management module of the mobile phone sends a request to start the camera to the system application framework of the mobile phone. After receiving the request to start the camera, the system application framework of the mobile phone determines whether the current network condition meets the preset network condition, that is, whether it is currently in the 5G connection state of Wi-Fi (5G Wi-Fi environment).

[0148] Among them, if the system application framework determines that the current network condition is in the 5G connection state of Wi-Fi, it directly sends a request to start the camera to the camera application. After receiving the request to start the camera sent by the system application framework, the camera application starts the camera.

[0149] In some feasible embodiments, if the system application framework does not create a local cache file, it can also set a cache flag bit. For example, if the cache flag bit is false or 0, it means that the system application framework has not created a local cache file. Subsequently, the distributed Binder management module can determine whether a local cache file has been created based on the incoming cache flag bit.

[0150] The camera application takes a photo in response to the user's operation and obtains the photo. Then, in response to the user clicking the confirmation button, the camera application initiates a request to obtain the File Provider object of the note application from the tablet. For the specific steps of the camera application obtaining the File Provider object, please refer to Figure 7 , Figure 9 The specific steps are not shown.

[0151] After the camera application obtains the File Provider object of the note application, the camera application sends a request to the system application framework of the mobile phone to obtain the file handle (file path) of the note application. The system application framework then sends a request to the distributed Binder management module to obtain the file handle (file path) of the note application (refer to Figure 9 Step 1.1). When the camera application uses the IFilePs object to call the corresponding interface of the note application, it enters the distributed Binder management module of the service collaboration module, and the input parameters in the interface call (by calling the transact method) can be encapsulated in a Parcel package (that is, the request parcel).

[0152] The distributed Binder management module receives a file handle request message (set to reqD) (refer to Figure 9 Step 1.2) and process reqD (refer to Figure 9 Specifically, first determine whether reqD contains an anonymous IBinder object. By parsing reqD, it can be determined that reqD does not contain an anonymous IBinder object.

[0153] After the distributed Binder management module serializes reqD, it forwards the call request (reqD byte stream) to the communication module of the mobile phone (refer to Figure 9 Step 1.4). The communication module of the mobile phone sends the reqD byte stream to the communication module of the tablet by assembling the message, and the message contains BinderId2.

[0154] The tablet's communication module receives the message and parses it (refer to Figure 9 Step 1.5) determines that the message carries a Binder call request, and then sends the message to the tablet's Binder management module. The tablet's Binder management module parses the message to obtain the serialized reqD (reqD byte stream), deserializes the reqD byte stream to obtain reqD. The tablet's distributed Binder management module finds the corresponding local IBinder object (IFilePc) based on the received BinderId2 (refer to Figure 9Step 1.5.1). Then, based on IFilePc, transact is called to perform the actual service call (i.e., obtain the file handle of the note) (refer to Figure 9 Step 1.5.2).

[0155] The note application of the tablet registers the File Descriptor object Fdc in advance in the system application framework of the tablet. Then, the system application framework of the tablet writes the File Descriptor object Fdc into the Parcel package, that is, Reply Parcel (set as repE) (refer to Figure 9 Step 1.5.3), and then returns repE to the camera application of the mobile phone. Specifically, the note application calls on Transact (refer to Figure 9 Step 1.6). The distributed Binder management module of the tablet processes repE. Specifically, it checks whether Fdc (equivalent to the IBinder object) is included in repE (refer to Figure 9 Step 1.6.1), and then sends an instruction to create a distributed file to the distributed file module of the tablet (refer to Figure 9 Step 1.6.2). Let the name of the created distributed file be "DisPicture".

[0156] After the distributed file module successfully creates the distributed file, it sends an instruction of successful creation to the distributed Binder management module of the tablet (refer to Figure 9 Step 1.6.3). Among them, the created distributed file will have a corresponding name. The distributed Binder management module of the tablet writes the name of the distributed file to the original position of Fdc in repE and takes up the position to generate repE1 (refer to Figure 9 Step 1.6.4). Then, the distributed Binder management module performs serialization processing on repE1.

[0157] Then, the tablet sends the serialized repE1 (i.e., the repE1 byte stream) to the mobile phone. Specifically, the distributed Binder management module of the tablet constructs a message, and this message carries repE1 (refer to Figure 9 Step 1.6.5), and the name "DisPicture" corresponding to the distributed file is included in repE1. The distributed Binder management module of the tablet sends the constructed message to the communication module of the tablet, and then the communication module of the tablet sends this message to the communication module of the mobile phone.

[0158] After the communication module of the mobile phone receives the message, it parses the message to obtain the message corresponding to repE1. Then, the communication module of the mobile phone sends the parsed message to the distributed Binder management module of the mobile phone for processing.

[0159] That is, the distributed Binder management module of the mobile phone processes the repE1 byte stream (refer to Figure 9 Step 1.7). Specifically, the distributed Binder management module of the mobile phone performs deserialization processing on the repE1 byte stream to obtain the repE1 object. Then, the distributed Binder management module can detect that the repE1 contains the name of the distributed file, that is, the repE1 contains the relevant information of the corresponding file handle (refer to Figure 9 Step 1.7.1). When the cache flag bit is true, the distributed Binder management module can open the corresponding distributed file by reading the name of the distributed file ("DisPicture") in repE1 (refer to Figure 9 Step 1.7.2).

[0160] Then, the distributed file module of the mobile phone returns the file handle of the distributed file to the distributed Binder management module of the mobile phone (refer to Figure 9 Step 1.7.3). The distributed Binder management module writes the file handle VFd into the reply packet (set as repE2) (refer to Figure 9 Step 1.7.4), and returns it to the system application framework (refer to Figure 9 Step 1.8).

[0161] At this time, the mobile phone obtains the file handle VFd of the note application. Then, the camera application of the mobile phone can write the captured photo data back to the tablet, that is, the camera application writes the captured photo data into the distributed file of the mobile phone through the file handle, then transfers it to the distributed file of the tablet, and finally returns it to the note application of the tablet. Among them, a channel can be created between the distributed file modules of the mobile phone and the tablet. After the camera application calls the write data interface of the distributed file of the mobile phone through the file handle, it writes the captured photo data, and transfers it to the distributed file of the tablet through the created channel, and then returns it to the note application.

[0162] Therefore, when the mobile phone's network condition meets the preset network conditions, the mobile phone's system application framework will not create a local cache file, and can directly obtain the file handle of the distributed file and complete the writing of the camera data through the file's write (wirte) system interface. After the distributed file monitors that the camera data is written, it directly completes the file transfer to the tablet through the RPC capability and writes the photo cache file of the note application, which can achieve faster data transmission and enhance the user experience.

[0163] See also Figure 10 , Figure 10 Another timing diagram for transmitting camera data provided by an embodiment of the present application. Figure 10 As shown, the system application framework of the tablet sends a request to start the camera to the distributed Binder management module of the tablet. The distributed Binder management module of the tablet sends a request to start the camera to the distributed Binder management module of the mobile phone. The distributed Binder management module of the mobile phone sends a request to start the camera to the system application framework of the mobile phone. After receiving the request to start the camera, the system application framework of the mobile phone determines whether the current network status meets the preset network conditions, that is, whether it is currently in the 5G connection state of Wi-Fi.

[0164] Among them, the system application framework determines that the current network condition is not in the 5G connection state of Wi-Fi, then creates a local cache file and sends a request to start the camera to the camera application. After receiving the request to start the camera sent by the system application framework, the camera application starts the camera.

[0165] In the embodiment of the present application, after the system application framework creates the local cache file, it can set the cache flag. For example, if the cache flag is true or 1, it means that the system application framework has created the local cache file.

[0166] The camera application takes a photo in response to the user's operation and obtains the photo. Then, in response to the user clicking the confirmation button, the camera application initiates a request to obtain the File Provider object of the note application from the tablet. For the specific steps of the camera application obtaining the File Provider object, please refer to Figure 7 , Figure 10 The specific steps are not shown.

[0167] After the camera application responds to the user's click operation on the confirmation button, the camera application may store the acquired photo data in a local cache file.

[0168] Among them, the specific steps for the camera application to obtain the file handle (file path) of the note application from the system application framework of the mobile phone, and the specific steps for the system application framework to send the photo data in the local cache file to the tablet based on the received file handle VFd can refer to Figure 8 the steps, which are not elaborated in this application. Among them, Figure 10 the serial numbers of the respective steps of Figure 8 correspond to the serial numbers of the respective steps in

[0169] Thus, when the network condition of the mobile phone does not meet the preset network condition, the system application framework of the mobile phone can create a local cache file and transfer the photo data in the local cache file into the distributed file. After the distributed file monitors that the camera data writing is completed, it directly completes the file transfer to the tablet through the RPC capability and writes it into the photo cache file of the note application. In summary, through the created local cache file, the mobile phone can pre-store the photo data obtained by the camera application, effectively avoiding the ANR problem or camera crash caused by the long camera response time in a weak network environment, and improving the user experience of cross-device calling. Moreover, the user can perform other operations after the camera exits, without affecting the transmission of photo data.

[0170] The data transmission method for creating a local cache file provided by the embodiments of this application has stronger scenario scalability and can perform video cross-terminal services with a larger amount of data. For example, when the tablet calls the camera application of the mobile phone to record a video, if a local cache file is not created, the video data can only be cross-terminally transmitted after the recording is completed to form a video file. Since video files are generally very large, the transmission of video data will take a long time, and the mobile phone needs to stay on the camera interface for a long time. By adopting the data transmission method for creating a local cache file provided by the embodiments of this application, the local cache file can be written in segments during video recording, and partial video data transmission can be completed concurrently through the Flush interface, avoiding staying on the camera interface for a long time after the recording is completed and improving the user experience.

[0171] In the embodiments of this application, the transmission method for creating a local cache file can be called a cache transmission model, and the transmission method without creating a local cache file can be called a non-cache transmission model.

[0172] Please refer to Figure 11 , Figure 11 which is a schematic diagram of a cross-device data processing method provided by the embodiments of this application. As Figure 11 shown, the tablet calls the target service of the mobile phone, and the steps of this method can specifically include steps S1101 - S1105, as follows:

[0173] Step S1101: The mobile phone creates a cache file in response to receiving a call request from the tablet.

[0174] Among them, the target service can be the camera service in the foregoing embodiments, such as taking a photo in the camera service. The cache file can be used to store the photo data obtained by the camera application when performing the photo-taking operation.

[0175] In some examples, the mobile phone can determine whether to create a cache file based on the current network condition. When the current network condition of the mobile phone is relatively good, the cache file may not need to be created. When the current network status of the mobile phone is relatively poor, the mobile phone can create a cache file. Among them, the first electronic device can preset network conditions for the network condition. If the current network condition meets the preset network conditions, then the local cache file may not need to be created. If the current network condition does not meet the preset network conditions, then the first electronic device can create a local cache file.

[0176] Among them, the preset network condition can be that the network is in a 5G connection state of Wi-Fi. Or, the preset network condition can be a preset network rate threshold. Among them, the electronic device can obtain the current network rate and judge it with the network rate threshold. If the current network rate is less than the network rate threshold, it means that the current network condition does not meet the preset network conditions; if the current network rate is not less than the network rate threshold, it means that the current network condition meets the preset network conditions.

[0177] Step S1102: The mobile phone executes the target service.

[0178] In the embodiments of the present application, the mobile phone obtains photo data in response to the user's operation on the photo-taking button in the camera application.

[0179] Step S1103: When the mobile phone executes the target service to obtain the corresponding target data, the target data is stored in the cache file.

[0180] In different cross-device call scenarios, the target data is different. For example, if the cross-device call scenario is the above-mentioned cross-device call camera service, then the target data can be photo-taking data. If the cross-device call scenario is the cross-device call gallery content service scenario, then the target data can be the photos in the gallery. If the cross-device call scenario is the cross-device call handwriting service scenario, then the target data can be handwriting data. If the cross-device call scenario is the cross-device call document scanning service scenario, then the target data can be scanning data. If the cross-device call scenario is the cross-device video recording service scenario, then the target data can be video data.

[0181] The mobile phone can store the target data in the cache file, which can avoid the situation where the target data is lost in case of a transmission error before the target data is transmitted to the tablet.

[0182] Step S1104: The mobile phone obtains a first file handle object of the first distributed file, and based on the first file handle object, sends the target data from the cache file to the first distributed file.

[0183] In the embodiment of the present application, for the application of the tablet to receive the photographed data, for example, taking the note application of the tablet as an example. Then, the note application of the tablet will create a photo cache file (preset file) for receiving the photographed data.

[0184] The tablet creates a corresponding second distributed file based on the file handle object of the photo cache file (set as the second file handle object), where the first distributed file and the second distributed file are used to support data access between the mobile phone and the tablet. That is to say, the second distributed file can receive the target data transmitted by the first distributed file. Then, the second file handle object can be used for the tablet to return the target data in the second distributed file to the photo cache file.

[0185] After obtaining the first file handle object of the first distributed file, the mobile phone can send the photographed data in the cache file to the first distributed file based on the first file handle object, for subsequent returning the photographed data to the tablet through the first distributed file.

[0186] Step S1105: The mobile phone returns the target data to the tablet through the first distributed file.

[0187] Thus, after the target data in the cache file of the mobile phone is transmitted to the first distributed file, the target data is sent to the second distributed file of the tablet through the first distributed file. The second distributed file of the tablet can return the target data to it based on the second file handle object of the photo cache file.

[0188] Thus, for the above cross-device data processing method, the mobile phone can pre-store the photo data obtained by the camera application through the created local cache file, which can effectively avoid the ANR problem caused by the long camera response time in a weak network environment and improve the user experience. And, after the camera exits, the user can perform other operations without affecting the transmission of photo data.

[0189] The above embodiments are mainly described by taking the cross-terminal call camera service scenario as an example, but are not limited to the cross-terminal call camera service scenario.

[0190] In some other feasible embodiments, the cross-device data processing method provided by the embodiments of the present application can also be applied to scenarios of cross-terminal calling of gallery content services: For example, in a note application on a tablet or a mobile phone, in response to a user's operation, photos in the gallery of the mobile phone / tablet can be quickly inserted into a specified position through cross-terminal calling. Or, the cross-device data processing method can also be applied to scenarios of cross-terminal calling of handwriting services: For example, when a user needs to write or quickly draw content while using a note application on a computer, the handwriting service on the mobile phone / tablet can be called, and after use, the obtained handwriting data can be automatically sent to a specified position on the computer. Or, the cross-device data processing method can also be applied to scenarios of cross-device calling of document scanning services: For example, when a note application on a tablet needs to insert a scanned document, in response to a user's operation through a cross-terminal service, the scanned data obtained by scanning with the mobile phone / tablet can be inserted into a specified position. Or, the cross-device data processing method can also be applied to scenarios of cross-device video recording services: For example, in an application on a tablet or a mobile phone, in response to a user's operation through cross-terminal calling, the capabilities of other devices can be used to complete video recording and saving.

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

[0192] In the embodiments of the present application, the electronic device can be divided into a private device and a public device. It can be understood that a private device is used to indicate a device that can only be used by the device owner (i.e., the owner of the device). For example, a private device can be a mobile phone, a smart watch, smart glasses, headphones, etc. A public device is used to indicate a device that can be used by any user. That is to say, there may be multiple accounts logged in to the public device, and there is an association between multiple different accounts. For example, a public device can be a television, a stereo, a tablet computer, etc.

[0193] The execution subject of the cross-device data processing method provided by the present application can be a cross-device data processing device, and the execution device can be Figure 12The electronic device shown. At the same time, the execution device can also be the Central Processing Unit (CPU) of the electronic device, or the control module for cross-device data processing in the electronic device. In the embodiments of the present application, the cross-device data processing method provided by the present application is described by taking the electronic device executing the cross-device data processing method as an example.

[0194] Hereinafter, the implementation manners of the embodiments of the present application will be described in detail with reference to the drawings. Taking the above electronic device as a mobile phone as an example, the hardware structure of the electronic device (such as the electronic device 300) will be introduced. Among them, Figure 12 The electronic device 300 shown is only 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 12 The various components shown can be implemented in hardware, software, or a combination of hardware and software including one or more signal processing and / or application specific integrated circuits.

[0195] Please refer to Figure 12 , Figure 12 which shows a schematic structural diagram of the electronic device. As shown in Figure 12 , 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 interface, a sensor module 380, a key 390, a motor 391, an indicator 392, a camera 393, a display screen 394, and a subscriber identification module (SIM) card interface 395, etc.

[0196] Among them, the above sensor module 380 may include sensors such as a pressure sensor, a gyroscope sensor, a barometric pressure sensor, a magnetic sensor, an acceleration sensor, a distance sensor, a proximity light sensor, a fingerprint sensor, a temperature sensor, a touch sensor, an ambient light sensor, and a bone conduction sensor.

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

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

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

[0200] A memory may also be provided in the processor 310 for storing instructions and data. In some embodiments, the memory in the processor 310 is a cache memory. This memory may save the instructions or data that the processor 310 has just used or recycled. If the processor 310 needs to use the instruction or data again, it can directly call it from the memory. This avoids repeated accesses, reduces the waiting time of the processor 310, and thus improves the efficiency of the system.

[0201] In some embodiments, the processor 310 may include one or more interfaces. The 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.

[0202] It can be understood that the interface connection relationships between the modules illustrated in this embodiment are only illustrative descriptions and do not constitute a structural limitation on the electronic device 300. In other embodiments, the electronic device 300 may also adopt different interface connection methods in the above embodiments, or a combination of multiple interface connection methods.

[0203] The charging management module 340 is used to receive a charging input from a charger. Among them, the charger is a wired charger in the embodiments of the present application, and the charging management module 340 can receive the charging input of the wired charger through the USB interface 330 (i.e., the above-mentioned charging interface). While charging the battery 342, the charging management module 340 can also supply power to the electronic device through the power management module 341.

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

[0205] The wireless communication function of the electronic device 300 can be implemented by the antenna 1, the antenna 2, the mobile communication module 350, the wireless communication module 360, the modulation and demodulation processor, and the baseband processor, etc.

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

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

[0208] The mobile communication module 350 can also amplify the signal modulated by the modulation and demodulation processor, and convert it into electromagnetic waves through the antenna 1 for radiation. In some embodiments, at least some functional modules of the mobile communication module 350 may be provided 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 may be provided in the same device.

[0209] The wireless communication module 360 can provide solutions for wireless communications applied to the electronic device 300, including wireless local area networks (WLANs) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite systems (GNSSs), frequency modulation (FM), near field communication (NFC), infrared technology (IR), etc. For example, in the embodiments of the present application, the electronic device 300 can access a Wi-Fi network through the wireless communication module 360.

[0210] The wireless communication module 360 may be one or more devices integrating at least one communication processing module. The wireless communication module 360 receives electromagnetic waves through the antenna 2, performs frequency modulation and filtering on the electromagnetic wave signals, and sends the processed signals to the processor 310. The wireless communication module 360 can also receive the signal to be sent from the processor 310, perform frequency modulation and amplification on it, and convert it into electromagnetic waves through the antenna 2 for radiation.

[0211] 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, such that electronic device 300 can communicate with a network and other devices through wireless communication technologies. The wireless communication technologies may include Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Time-Division Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technologies, etc. The GNSS may include 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).

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

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

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

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

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

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

[0218] The electronic device 300 can implement audio functions through an audio module 370, a speaker 370A, a receiver 370B, a microphone, a headphone interface, and an application processor, etc. For example, music playback, recording, etc.

[0219] The audio module 370 is used to convert digital audio information into an analog audio signal for output, and is also used to convert an analog audio input into a digital audio signal. The audio module 370 can also be used for encoding and decoding audio signals. In some embodiments, the audio module 370 can be disposed in the processor 310, or some functional modules of the audio module 370 can be disposed in the processor 310. The speaker 370A, also called a "loudspeaker", is used to convert an audio electrical signal into a sound signal. The receiver 370B, also called a "handset", is used to convert an audio electrical signal into a sound signal. The microphone, also called a "microphone", "transmitter", is used to convert a sound signal into an electrical signal.

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

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

[0222] Although Figure 12 not shown, the electronic device 300 may also include a flash, a micro projection device, a Near Field Communication (NFC) device, etc., which will not be elaborated here.

[0223] The embodiment of the present application also provides a chip system. As Figure 13 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 can be interconnected by a line. For example, the interface circuit 902 can be used to receive signals from other devices (such as the memory of the electronic device). For another example, the interface circuit 902 can be used to send signals to other devices (such as the processor 901). Exemplarily, the interface circuit 902 can read the instructions stored in the memory and send the instructions to the processor 901. When the instructions are executed by the processor 901, the electronic device can execute each step in the above embodiments. Of course, the chip system may also include other discrete devices, and the embodiments of the present application do not make specific limitations on this.

[0224] The embodiment of the present application also provides a computer storage medium. The computer storage medium includes computer instructions. When the computer instructions run on the above-mentioned electronic device, the electronic device is caused to execute each function or step that the mobile phone executes in the above method embodiment.

[0225] The embodiment of the present application also provides a computer program product. When the computer program product runs on a computer, the computer is caused to execute each function or step that the mobile phone executes in the above method embodiment.

[0226] From the description of the above embodiments, those skilled in the art can clearly understand that for the convenience and brevity of description, 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 is divided into different functional modules to complete all or part of the functions described above.

[0227] In several embodiments provided in the present application, it should be understood that the disclosed device and method can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the modules or units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the displayed or discussed couplings or direct couplings or communication connections to each other can be through some interfaces. The indirect couplings or communication connections of the devices or units can be in electrical, mechanical or other forms.

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

[0229] In addition, each functional unit in various embodiments of the present application can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit. The above integrated units can be implemented in the form of hardware or in the form of software functional units.

[0230] If the above integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiments of the present application, in essence, or the part that contributes to the prior art, or all or part of this technical solution, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions for causing a device (which can be a single-chip microcomputer, a chip, etc.) or a processor to execute all or part of the steps of the methods described in various embodiments of the present application. And the aforementioned storage medium includes: USB flash drives, mobile hard disks, read only memory (ROM), random access memory (RAM), magnetic disks or optical discs and other various media that can store program codes.

[0231] The above content is only a specific implementation manner of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present application should be covered by the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A cross-device data processing method, characterized in that, Applied to a first electronic device, the method includes: The first electronic device creates a cache file and executes a target service in response to receiving a call request from a second electronic device; When the first electronic device executes the target service to obtain corresponding target data, the first electronic device stores the target data in the cache file; The first electronic device obtains a first file handle object of a first distributed file, and based on the first file handle object, sends the target data from the cache file to the first distributed file; the first distributed file and a second distributed file are used to support data access between the first electronic device and the second electronic device; the second distributed file is created by the second electronic device based on a second file handle object of a preset file of the second electronic device, and the second file handle object is used for the second electronic device to return the target data in the second distributed file to the preset file; the preset file is used to store the target data; The first electronic device returns the target data to the second electronic device through the first distributed file.

2. The method according to claim 1, wherein Before creating the cache file, it further includes: The first electronic device determines that the network condition where the first electronic device is located does not meet a preset network condition.

3. The method according to claim 1 or 2, characterized in that, Before the first electronic device obtains a first file handle object of a first distributed file, it further includes: The first electronic device sends a first acquisition request to the second electronic device, for requesting to obtain a second file handle object of a preset file of the second electronic device; wherein, the first acquisition request is further used to trigger the second electronic device to create the second distributed file based on the second file handle object; The first electronic device receives the file name of the second distributed file sent by the second electronic device; Wherein, the first electronic device obtains a first file handle object of a first distributed file, including: The first electronic device obtains the first file handle object corresponding to the first distributed file based on the file name of the second distributed file.

4. The method according to any one of claims 1 to 3, characterized in that, The method further includes: The first electronic device determines that the network condition where the first electronic device is located meets a preset network condition in response to receiving the call request from the second electronic device, and writes the target data into the first distributed file.

5. The method according to any one of claims 1 to 4, characterized in that, The first electronic device returns the target data to the second electronic device through the first distributed file, including: The first electronic device transmits the target data to the second distributed file of the second electronic device through the first distributed file, so that the second electronic device returns the target data in the second distributed file to the preset file through the second file handle object.

6. The method according to any one of claims 1-5, characterized in that, The first electronic device obtains a first file handle object of a first distributed file, and based on the first file handle object, sends the target data from the cache file to the first distributed file, including: The system application framework of the first electronic device obtains the first file handle object of the first distributed file; The system application framework calls a preset interface and sends the first file handle object and the third file handle object of the cached file to the distributed Binder management module of the first electronic device; Based on the first file handle object and the third file handle object, the distributed Binder management module sends a file writing request to the distributed file module of the first electronic device; In response to the file writing request, the distributed file module sends the target data in the cached file to the first distributed file based on the first file handle object and the third file handle object.

7. The method according to claim 6, wherein The first electronic device returns the target data to the second electronic device through the first distributed file, including: The distributed file module sends a write completion instruction to the system application framework; the write completion instruction is used to indicate that the distributed file module has completed sending the target data from the cached file to the first distributed file; In response to the write completion instruction, the system application framework sends a close file writing request to the distributed Binder management module; the close file writing request is used to indicate that the distributed file module closes the file writing interface, and the file writing interface is used to receive the target data sent by the cached file; The distributed Binder management module sends the close file writing request to the distributed file module; In response to the close file writing request, the distributed file module closes the file writing interface.

8. The method according to any one of claims 1-7, characterized in that, Before creating the cached file, it further includes: The first electronic device starts a target application, and the target application is used to execute the target service; Among them, creating the cached file includes: In response to starting the target application, the first electronic device creates the cached file.

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

10. A computer-readable storage medium, characterized in that, Instructions are stored in the computer-readable storage medium. When the instructions run on the electronic device, the electronic device executes the method according to any one of claims 1 to 8.

11. A computer program product, characterized in that, The computer program product includes a computer program. When the computer program runs on the electronic device, the electronic device executes the method according to any one of claims 1 to 8.

Images