Information interaction method, electronic device and collaborative work system

Abstract

Embodiments of the present application provide a method for information interaction, an electronic device and a collaborative work system, which are applied to the technical field of terminals. The method comprises: when a user performs a service operation on a first service of a first electronic device and a second electronic device, a control center APK acquires a first service scheduling instruction, and when the first service APK or the control center APK is not in a running state, the first service scheduling instruction is sent to a control center SDK to realize interaction with the APK of the first service through the control center SDK. In this way, when one of the service APK or the control center APK is not in a running state, the other one in a running state is pulled up, and the normal progress of service scheduling is realized.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to a method for information interaction, an electronic device, and a collaborative work system. Background Technology

[0002] Multi-device collaboration is a technology applied to multiple electronic devices. Using multi-device collaboration technology, two or more electronic devices can collaborate across systems and devices, enabling resource sharing and collaborative operation.

[0003] As users' demands for terminal technology increase, unified management of multi-device collaboration has become a key aspect of the development of collaborative technologies. Unified management of multi-device collaboration refers to users establishing collaborative service connections with different devices through a single device control center interface. To achieve unified management of multi-device collaboration, a layered architecture including a control layer and a service layer can be deployed at the application layer of electronic devices. The control layer controls the implementation logic of collaborative services, while the service layer completes collaborative service operations, such as service disconnection, service connection establishment, or service mode switching.

[0004] Therefore, enabling interaction between the control layer and the business layer is extremely important. This interaction refers to the control layer issuing commands to trigger specific business processes within the business layer to perform operations such as establishing business connections. However, the specific business processes in the control layer and the business layer may not be running simultaneously, leading to a failure to interact properly between them. Consequently, this can result in the inability to connect multiple electronic devices that need to work collaboratively. Summary of the Invention

[0005] The purpose of this application is to provide a method for information interaction, an electronic device, and a collaborative work system. The aim is to enable interaction between the control side and the control center SDK through the control center software development kit (SDK), and then to enable interaction between the control center SDK and the business layer when specific business processes in the control layer or business layer are not in operation.

[0006] Firstly, this application provides a method for information interaction, applied to a first electronic device, wherein the first electronic device has an Android application package APK for collaborative services and a control center APK installed. The control center APK is used to control the first electronic device to implement collaborative services through the collaborative service APK. The method includes:

[0007] When a user performs a service operation on the first electronic device and the second electronic device, a first service scheduling instruction is obtained. This first service scheduling instruction indicates that the control center APK interacts with the service APK through the control center SDK. The second electronic device is a device capable of connecting to the first electronic device.

[0008] When the first service APK is not running, or the control center APK is not running, the first service scheduling instruction is sent to the control center SDK so that the control center APK and the first service APK can interact.

[0009] For example, when either the first service APK or the control center APK is not running, the first service scheduling instruction is sent to the control center SDK of the first electronic device by calling the control center application programming interface (API) component and the second data call component of the control center APK using the ContentProvider.call method. This allows the running device to start up the non-running device, completing normal information exchange between the control center APK and the service APK.

[0010] In one possible implementation, the control center SDK is integrated into the APK of the first business application. This allows for direct interaction between the control center APK and the business APK via API interfaces, making the operation simple.

[0011] In one possible implementation, the method further includes: controlling a first electronic device and a second electronic device to establish a connection to collaboratively process a first service; and invoking a service component of the first service's APK to send the service operation result of the first service back to the control center APK. In another possible implementation, invoking the service component of the first service's APK includes: when the first service's APK is not running, creating a first invoked component of the first service's APK and creating an application component of the first service's APK, wherein creating the application component of the first service's APK is used to send a first service scheduling instruction to the first service's APK; invoking the invoked component and forwarding the first service scheduling instruction to the service component of the first service's APK; creating and starting the service component of the first service's APK to send the service operation result of the first service back to the control center APK; and when the first service's APK is running and the service component of the first service's APK exists, invoking the service component of the first service's APK to send the service operation result of the first service back to the control center APK.

[0012] Because the service component's lifecycle is later than the first called component, it ensures that the first called component for the business callback has already been created when the service component executes its instructions. Furthermore, since the execution of connection and other instructions is time-consuming, delegating this to the service component prevents the first called component from being blocked and unable to respond to the next instruction in a timely manner.

[0013] In one possible implementation, a pre-check is performed before calling the service component of the first service's APK. Specifically, the first service APK determines whether the operating environment for the first electronic device to execute the first service is correctly completed. Only after this is confirmed is the service component of the first service APK called, thereby improving the callback success rate. This also avoids repeatedly writing redundant check code in methods such as connect, disconnect, and operate.

[0014] In one possible implementation, the method further includes: sending a second service scheduling instruction to the control center APK when the first service cannot be executed. The second service scheduling instruction instructs the control center APK to establish a connection with the second electronic device, and enables the control center APK of the second electronic device to interact with the service APK of the second electronic device through the control center SDK of the second electronic device. This achieves the establishment of a collaborative service connection from the second electronic device.

[0015] In one possible implementation, when the service APK determines that there is missing information in the first service scheduling instruction, the control center APK sends an information request instruction to the second electronic device, requesting the second electronic device to receive the missing information from the first service scheduling instruction sent by the first electronic device. The service APK receives additional communication instructions sent by the second electronic device to fill in the missing information in the first service scheduling instruction, thus establishing a service connection.

[0016] In one possible implementation, the first business scheduling instruction is an instruction encapsulated in a TCP / IP-like format. This standardized message or instruction encapsulation eliminates the need for manually filling in instruction parameters sequentially, reducing code complexity and improving coding efficiency at the business layer.

[0017] Secondly, this application provides a method for information interaction, applied to a second electronic device. The second electronic device has an Android application package APK for collaborative services and a control center APK installed. The control center APK is used to control the second electronic device to implement collaborative services through the collaborative service APK. The method includes:

[0018] When a user performs a service operation on a first electronic device and a second electronic device for a first service, and the first electronic device is unable to perform the first service, a second service scheduling instruction is received from the control center APK of the first electronic device. This second service scheduling instruction instructs the control center APK of the second electronic device and the control center APK of the first electronic device to establish a connection, and enables the control center APK to interact with the APK of the first service through the control center software development kit (SDK). When the APK of the first service is not running, and / or the control center APK is not running, the second service scheduling instruction is sent to the control center SDK to enable information exchange between the control center APK and the APK of the first service.

[0019] For example, when either the first service APK or the control center APK is not running, the second service scheduling instruction is sent to the control center SDK of the second electronic device by calling the control center application programming interface (API) component and the second data call component of the control center APK using the ContentProvider.call method. This allows the running device to start up the non-running device, completing normal information exchange between the control center APK and the service APK.

[0020] In one possible implementation, the control center SDK is integrated into the APK of the primary business application. This allows for direct interaction between the control center APK and the business application APK via API interfaces, simplifying the process.

[0021] In one possible implementation, the control unit establishes a connection between the first electronic device and the second electronic device to collaboratively process the first service, and invokes the service component of the first service's APK to send the service operation result of the first service back to the control center APK.

[0022] In one possible implementation, the service component that calls the APK of the first service includes: when the APK of the first service is not running, creating a first called component of the APK of the first service and creating an application component of the APK of the first service, wherein creating the application component of the APK of the first service is used to send the scheduling instruction of the first service to the APK of the first service; calling the called component and forwarding the scheduling instruction of the first service to the service component of the APK of the first service; creating the service component of the APK of the first service and starting the service component of the APK of the first service to call back the service operation result of the first service to the control center APK; when the APK of the first service is running and the service component of the APK of the first service exists, calling the service component of the APK of the first service to call back the service operation result of the first service to the control center APK.

[0023] Because the service component's lifecycle is later than the first called component, it ensures that the first called component for the business callback has already been created when the service component executes its instructions. Furthermore, since the execution of connection and other instructions is time-consuming, delegating this to the service component prevents the first called component from being blocked and unable to respond to the next instruction in a timely manner.

[0024] In one possible implementation, a pre-check is performed before calling the service component of the first service's APK. Specifically, the first service APK determines whether the operating environment for the first electronic device to execute the first service is correctly completed. Only after this is confirmed is the service component of the first service APK called, thereby improving the callback success rate. This also avoids repeatedly writing redundant checking code in methods such as connect, disConnect, and operate.

[0025] In one possible implementation, the method further includes: when the first service cannot be executed, sending a second service scheduling instruction to the control center APK. The second service scheduling instruction instructs the control center APK to establish a connection with the second electronic device, and enables the control center APK of the second electronic device to interact with the service APK of the second electronic device through the control center SDK of the second electronic device. This achieves collaborative service connection establishment from the second electronic device.

[0026] In one possible implementation, when the service APK determines that there is missing information in the first service scheduling instruction, the control center APK sends an information request instruction to the second electronic device, requesting the second electronic device to receive the missing information from the first service scheduling instruction sent by the first electronic device. The service APK receives additional communication instructions sent by the second electronic device to fill in the missing information in the first service scheduling instruction, thus establishing a service connection.

[0027] In one possible implementation, the first business scheduling instruction is an instruction encapsulated in a TCP / IP-like format. This standardized message or instruction encapsulation eliminates the need for manually filling in instruction parameters sequentially, reducing code complexity and improving coding efficiency at the business layer.

[0028] Thirdly, this application also provides an electronic device, including: a memory and a processor, the memory being coupled to the processor; the memory storing program instructions that, when executed by the processor, cause the electronic device to perform the method described in any of the first aspects.

[0029] Fourthly, this application also provides an electronic device, including a memory and a processor, the memory being coupled to the processor; the memory storing program instructions that, when executed by the processor, cause the electronic device to perform the method described in any of the second aspects.

[0030] Fifthly, this application also provides a collaborative working system, including the electronic devices of the third aspect and the fourth aspect.

[0031] It should be understood that the descriptions of technical features, technical solutions, beneficial effects, or similar language in this application do not imply that all features and advantages can be achieved in any single embodiment. Rather, it is understood that the description of a feature or beneficial effect means that a specific technical feature, technical solution, or beneficial effect is included in at least one embodiment. Therefore, the descriptions of technical features, technical solutions, or beneficial effects in this specification do not necessarily refer to the same embodiment. Furthermore, the technical features, technical solutions, and beneficial effects described in this embodiment can be combined in any suitable manner. Those skilled in the art will understand that embodiments can be implemented without one or more specific technical features, technical solutions, or beneficial effects of a particular embodiment. In other embodiments, additional technical features and beneficial effects may be identified in specific embodiments that do not embody all embodiments. Attached Figure Description

[0032] Figure 1 A schematic diagram illustrating a unified management system for multiple devices in accordance with an embodiment of this application;

[0033] Figure 2 A schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application;

[0034] Figure 3 This is a software structure block diagram of the electronic device 100 according to an embodiment of this application;

[0035] Figure 4 An architectural block diagram of an application layer provided in this application embodiment;

[0036] Figure 5 This application provides an architecture deployment diagram of an application layer.

[0037] Figure 6 A schematic diagram of a call provided in an embodiment of this application;

[0038] Figure 7A This application provides a schematic diagram of a direct service connection establishment method.

[0039] Figure 7B This application provides a schematic diagram of a second electronic device initiating a service connection establishment mode.

[0040] Figure 7C This is a schematic diagram illustrating a second electronic device initiating a service connection and requiring additional communication before connection establishment, as provided in an embodiment of this application.

[0041] Figure 7D This is a schematic diagram illustrating a second electronic device initiating a service connection and requiring additional communication before connection establishment, as provided in an embodiment of this application.

[0042] Figure 8A A schematic diagram illustrating a direct service connection communication provided in an embodiment of this application;

[0043] Figure 8B A flowchart illustrating a method for a service component to execute a business callback, as provided in an embodiment of this application;

[0044] Figure 9 This is a schematic diagram illustrating a service connection establishment process for invoking a peer device's service, as provided in an embodiment of this application.

[0045] Figure 10A This application provides an implementation of an additional communication mechanism.

[0046] Figure 10B This is a schematic diagram illustrating a method for monitoring registration business messages provided in an embodiment of this application. Detailed Implementation

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

[0048] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0049] The terms "first" and "second," etc., used in the specification and claims of this application are used to distinguish different objects, not to describe a specific order of objects. For example, "first target object" and "second target object," etc., are used to distinguish different target objects, not to describe a specific order of target objects.

[0050] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0051] In the description of the embodiments in this application, unless otherwise stated, "multiple" means two or more. For example, multiple processing units means two or more processing units; multiple systems means two or more systems.

[0052] Multi-device collaboration is a distributed technology applied to multiple electronic devices. Using multi-device collaboration technology, two or more electronic devices can collaborate across systems and devices to achieve resource sharing and collaborative operation.

[0053] Multi-device collaboration can be applied between electronic devices of the same or different types. These electronic devices include, but are not limited to, mobile phones, tablets, laptops, large-screen devices (e.g., smart TVs, smart screens), personal computers (PCs), handheld computers, netbooks, personal digital assistants (PDAs), wearable electronic devices, in-vehicle devices, virtual reality devices, and so on.

[0054] Multi-device collaboration requires communication connections between devices. These connections can be wired or wireless. Wired solutions could include, for example, USB On-The-Go (OTG) technology; wireless solutions could include, for example, wireless fidelity (Wi-Fi), Wi-Fi Direct, Bluetooth (BT), near-field communication (NFC), and infrared (IR) technology.

[0055] With the continuous development of terminal technology, multi-device collaboration has given rise to various types of collaboration (also known as collaboration services), such as multi-screen collaboration (including screen extension, screen mirroring, and screen sharing), keyboard and mouse collaboration, call collaboration, and call continuation collaboration. Among these:

[0056] Screen mirroring: Mirrors all content displayed on the screen of electronic device A onto the screen of electronic device B. The content displayed on electronic device B is identical to the content displayed on electronic device A, and changes as the content displayed on electronic device A changes.

[0057] Screen extension: The screen of electronic device B is used as a secondary screen for electronic device A. Electronic device A can transfer a portion of the content it needs to display to the secondary screen for display. The screens of electronic device A and electronic device B can display content together, thus extending the display capabilities of electronic device A.

[0058] Screen sharing: Projecting the user interface of electronic device A onto the screen of electronic device B for display, allowing users to interact with the user interface of electronic device A from within electronic device B, and transferring files from electronic device B to electronic device A by performing specific operations on electronic device B (e.g., dragging and dropping files from the user interface of electronic device B to the user interface of electronic device A), thus enabling cross-device operation and cross-device file transfer between electronic devices A and B. The user interface of electronic device A can be displayed in any area of ​​the screen of electronic device B, or it can be displayed full-screen.

[0059] Keyboard and mouse collaboration: Electronic device A and electronic device B can share each other's existing input devices, such as a mouse and keyboard. For example, electronic device A's input devices can be shared with electronic device B, and the shared input devices can be used for input on both electronic device A and electronic device B. Additionally, in keyboard and mouse sharing, file transfer can also be performed between electronic device A and electronic device B.

[0060] Seamless Collaboration: When a user is running an application on electronic device A, the interface of electronic device B can prompt the user to open the application running on electronic device A on electronic device B, thus transferring the user to electronic device B to continue the operation, such as watching a video or editing a document. For example, if a document application (such as a memo or Word document) is running on electronic device A, and the user is editing the document on electronic device A, when electronic device B is close to electronic device A, a prompt message is displayed on electronic device B. The user clicks the prompt message on electronic device B, and in response to the user's click, electronic device B opens the document application and displays the user's current editing position, thus allowing the user to continue editing on electronic device B.

[0061] Call coordination: When electronic device A receives an incoming voice or video call, the incoming call interface can be displayed simultaneously on electronic device B. In this way, the user can choose to answer or hang up the call on electronic device B.

[0062] Notification Collaboration: When electronic device A receives a notification message, the notification message can be displayed synchronously on electronic device B. It also allows users to perform operations such as replying to, deleting, and marking as read on the notification message on electronic device B.

[0063] The above-listed collaboration types include several types. Some are initiated by the first electronic device (usually the initiator of multi-device collaboration) in response to user actions, moving to the second electronic device (usually a participant in multi-device collaboration). These can be called manual collaboration services, such as screen extension, screen sharing, and keyboard / mouse collaboration. Other collaboration types are automatically triggered when the user enables the function and the triggering rules are met. These can be called automatic collaboration services, such as call collaboration, notification collaboration, and call continuation collaboration.

[0064] Taking manual collaboration as an example:

[0065] If the first electronic device is a mobile phone and the second electronic device is a tablet computer, the supported collaboration types can include screen sharing.

[0066] If the first electronic device is a non-foldable screen phone and the second electronic device is a PC, the supported collaboration types can include keyboard and mouse collaboration and screen sharing. Specifically, when a non-foldable screen phone and a PC first connect, the default collaboration type can be screen sharing.

[0067] If the first electronic device is a foldable phone and the second electronic device is a PC, the supported collaboration types can include keyboard and mouse collaboration, screen sharing, screen mirroring, and screen extension. When the foldable phone and PC first connect, the default collaboration type is screen sharing.

[0068] If the first electronic device is a mobile phone and the second electronic device is a large-screen device, the supported collaboration types can include screen mirroring.

[0069] If the first electronic device is a tablet and the second electronic device is a mobile phone, the types of collaboration they support can include.

[0070] If the first electronic device is a tablet and the second electronic device is a PC, the supported collaboration types can include screen mirroring, screen extension, and keyboard and mouse collaboration. When the tablet and PC first connect, the default collaboration type is screen mirroring.

[0071] If the first electronic device is a tablet and the second electronic device is a large-screen device, the supported collaboration types can include screen mirroring.

[0072] If the first electronic device is a PC and the second electronic device is a non-foldable screen phone, the supported collaboration types can include keyboard and mouse collaboration and screen sharing. When the PC and the non-foldable screen phone first connect, the default collaboration type can be screen sharing.

[0073] If the first electronic device is a PC and the second electronic device is a foldable phone, the supported collaboration types can include keyboard and mouse collaboration, screen sharing, screen mirroring, and screen extension. When the PC and foldable phone first connect, the default collaboration type is screen sharing.

[0074] If the first electronic device is a PC and the second electronic device is a tablet, the supported collaboration types can include screen mirroring, screen extension, and keyboard and mouse collaboration. When the PC and tablet first connect, the default collaboration type is screen mirroring.

[0075] If the first electronic device is a PC and the second electronic device is a large-screen device, the supported collaboration types can include screen mirroring.

[0076] Take automated collaboration services as an example:

[0077] Electronic devices that support collaborative calls can include mobile phones, tablets, PCs, large-screen display devices, etc.

[0078] Electronic devices that support notification collaboration can include mobile phones, tablets, PCs, etc.

[0079] Electronic devices that support seamless collaboration can include mobile phones, tablets, PCs, large-screen display devices, etc.

[0080] Currently, with the increasing demands of users for terminal technology, unified management of multi-device collaboration has become a key aspect of the development of collaborative technologies. Unified management of multi-device collaboration refers to the ability for users to establish collaborative connections with different devices through a single device control center interface. For example, the mobile device control center interface displays all other devices that can establish connections with the mobile device, namely device A, device B, and device C. Within this interface, users can enable collaboration between the mobile device and device A, as well as with devices B and C, and can also terminate ongoing collaborative services between device A and other devices.

[0081] Example illustration: See Figure 1This diagram illustrates a unified management system for multiple devices, as provided in this application embodiment. The first electronic device is a mobile phone (represented by a blue ball enclosing a "pad" icon). Devices to be connected include a tablet (represented by a white ball enclosing a "pad"), a laptop (represented by a white ball enclosing a "magic book" icon), a large-screen display device (represented by a white ball enclosing a "smart TV"), and another tablet (represented by a white ball enclosing a "pad" icon). On the main control center interface, dragging the white "pad" icon to the first electronic device triggers a connection between the "magic book" and the "pad"; dragging the white "smart TV" icon to the first electronic device triggers a connection between the "pad" and the "smart TV". From a business perspective, each device may run multiple services simultaneously, such as multi-screen collaboration. Dragging the "pad" icon essentially involves commands issued by the control centers of both the first and second electronic devices, triggering connection operations between the two devices.

[0082] However, triggering business operations requires both the control layer and the business layer's Android application packages to be running in order to interact. But in actual operation, it's possible that the control layer's Android application and the business layer's Android application are not both running; that is, the control layer's Android application is running, but the business layer's Android application is not, or vice versa. In this case, the business operation cannot be triggered. Therefore, when the control layer and business layer's Android applications are not both running, how to achieve flexible interaction between the control layer and the business layer to trigger business operations becomes crucial.

[0083] This application provides a method for information interaction, aiming to integrate a control center SDK into the service layer, allowing the service layer to interact with the control layer through the control center SDK. Specifically, the control layer issues scheduling instructions, such as connection establishment instructions, disconnection instructions, and mode switching instructions, to the service scheduling of the first electronic device. The service layer obtains the scheduling instructions through the control center SDK and executes the service scheduling. In this way, information interaction can be achieved without both the control layer and the service layer being in a running state.

[0084] The information interaction method of this application embodiment can be applied to various types of electronic devices with display functions.

[0085] See Figure 2 This is a schematic diagram of the hardware structure of the electronic device provided in an embodiment of this application. This device can serve as either the first electronic device or the second electronic device in a multi-device collaborative setup. Figure 2As shown, the electronic device 100 may include a processor 110, a memory 120, a universal serial bus (USB) interface 130, a radio frequency circuit 140, a mobile communication module 150, a wireless communication module 160, a camera 170, a display screen 180, a touch sensor 190, a barometric pressure sensor 210, and buttons 220, etc.

[0086] Processor 110 may include one or more processing units, such as an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural network processing unit (NPU). Different processing units may be independent devices or integrated into one or more processors, such as in a system-on-a-chip (SoC). Processor 110 may also include memory for storing instructions and data. In some embodiments, the memory in processor 110 is a cache memory. This memory can store instructions or data that have just been used or are being reused by processor 110.

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

[0088] The memory 120 can be used to store executable program code, including instructions. The memory 120 may include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during the use of the electronic device 100 (such as audio data, phonebook, etc.). Furthermore, the memory 120 may include one or more storage units, such as volatile memory (e.g., dynamic random access memory, DRAM, static random access memory, SRAM), etc.; and non-volatile memory (NVM), such as read-only memory (ROM), flash memory, etc. The processor 110 executes various functional applications and data processing of the electronic device 100 by running instructions stored in the memory 120 and / or instructions stored in memory located in the processor.

[0089] It should be noted that the operating systems referred to in the embodiments of this application include, but are not limited to, Android operating system, iOS operating system, iPad OS, Harmony OS, Windows operating system, Linux operating system, MAC OS operating system, embedded systems, etc.

[0090] The wireless communication function of the electronic device 100 can be implemented through the radio frequency circuit 140, the mobile communication module 150, the wireless communication module 160, the modem processor, and the baseband processor.

[0091] The radio frequency circuit 140 may include at least one antenna 141 for transmitting and receiving electromagnetic wave signals. Each antenna in the electronic device 100 may be used to cover one or more communication frequency bands. In some embodiments, the antenna may be used in conjunction with a tuning switch.

[0092] The mobile communication module 150 can provide solutions for wireless communication applications on the electronic device 100, including 2G / 3G / 4G / 5G. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves via the antenna 141, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to the modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via the antenna 141. In some embodiments, at least some functional modules of the mobile communication module 150 may be housed in the processor 110. In some embodiments, at least some functional modules of the mobile communication module 150 and at least some modules of the processor 110 may be housed in the same device.

[0093] The modem processor may include a modulator and a demodulator. The modulator modulates the low-frequency baseband signal to be transmitted into a mid-to-high frequency signal. The demodulator demodulates the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After processing by the baseband processor, the low-frequency baseband signal is transmitted to the application processor. The application processor outputs sound signals through audio devices (including but not limited to speakers, receivers, etc.) or displays images or videos through the display screen 180. In some embodiments, the modem processor may be a separate device. In other embodiments, the modem processor may be independent of the processor 110 and may be housed in the same device as the mobile communication module 150 or other functional modules.

[0094] The wireless communication module 160 may include a Wi-Fi module, a Bluetooth (BT) module, a GNSS module, a near-field communication (NFC) module, an infrared (IR) module, etc. The wireless communication module 160 may be one or more devices integrating at least one of the above modules. The wireless communication module 160 receives electromagnetic waves via antenna 141, modulates and filters the electromagnetic wave signal, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, modulate and amplify them, and then convert them into electromagnetic waves for radiation via antenna 141.

[0095] In this embodiment, the wireless communication functions of the electronic device 100 may include, for example, 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), 5th Generation Mobile Networks New Radio (5G NR), BT, GNSS, WLAN, NFC, FM, and / or IR. 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).

[0096] Camera 170 is used to capture still images or videos. Camera 170 includes a lens and a photosensitive element. An object is projected onto the photosensitive element through the lens to generate an optical image. The photosensitive element can be a charge-coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the light signal into an electrical signal, which is then passed to an ISP for conversion into a digital image signal. The ISP outputs the digital image signal to a DSP for processing. The DSP converts the digital image signal into image signals in standard formats such as RGB, YUV, and RYYB. In some embodiments, electronic device 100 may include one or N cameras 170, where N is a positive integer greater than 1.

[0097] An NPU (Neural Processing Unit) is a computational processor for neural networks (NNs). By borrowing the structure of biological neural networks, such as the transmission patterns between neurons in the human brain, it can rapidly process input information and continuously learn on its own. NPUs enable intelligent cognitive applications in electronic devices, such as image recognition, facial recognition, speech recognition, and text understanding.

[0098] The display screen 180 is used to display images, videos, etc. The display screen 180 includes a display panel. The display panel may 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. In some embodiments, the electronic device 100 may include one or N displays 180, where N is a positive integer greater than 1.

[0099] Touch sensor 190, also known as a "touch device," can be disposed on display screen 180. The touch sensor 190 and display screen 180 together form a touchscreen, also known as a "touchscreen." Touch sensor 190 is used to detect touch operations applied to or near it. The touch sensor can transmit the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through display screen 180. In other embodiments, touch sensor 190 may also be disposed on the surface of electronic device 100, in a different location than display screen 180.

[0100] The barometric pressure sensor 210 is used to measure air pressure. In some embodiments, the electronic device 100 calculates altitude using the air pressure value measured by the barometric pressure sensor 210 to assist in positioning and navigation.

[0101] Buttons 220 include a power button, volume buttons, etc. Buttons 220 can be mechanical buttons or touch-sensitive buttons. Electronic device 100 can receive button input and generate key signal inputs related to user settings and function control of electronic device 100.

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

[0103] The software system of electronic device 100 can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This embodiment of the invention uses the layered architecture Android system as an example to exemplify the software structure of electronic device 100.

[0104] Figure 3 This is a software structure block diagram of the electronic device 100 according to an embodiment of this application.

[0105] A layered architecture divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into four layers, from top to bottom: the application layer, the application framework layer, the Android runtime and system libraries, and the kernel layer.

[0106] The application layer can include a series of application packages.

[0107] like Figure 3 As shown, the application package may include applications such as camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, and multi-device collaboration applications.

[0108] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0109] like Figure 3 As shown, the application framework layer may include a window manager, content provider, view system, phone manager, resource manager, notification manager, etc.

[0110] The window manager is used to manage windowed applications. It can retrieve screen size, determine the presence of a status bar, lock the screen, and capture screenshots, among other things.

[0111] Content providers store and retrieve data, making that data accessible to applications. This data may include videos, images, audio, made and received phone calls, browsing history and bookmarks, phone books, etc.

[0112] A view system includes visual controls, such as controls for displaying text and controls for displaying images. View systems can be used to build applications. A display interface can consist of one or more views. For example, a display interface including a text notification icon could include views for displaying text and views for displaying images.

[0113] The phone manager is used to provide communication functions for electronic device 100. For example, it manages call status (including connection and disconnection).

[0114] The file explorer provides applications with various resources, such as localized strings, icons, images, layout files, video files, and more.

[0115] The notification manager allows applications to display notifications in the status bar. These notifications can be used to deliver informational messages and can disappear automatically after a short pause, requiring no user interaction. For example, the notification manager can be used to notify users of completed downloads or message alerts. The notification manager can also display notifications as icons or scrolling text in the top status bar, such as notifications from background applications, or as dialog boxes on the screen. Examples include displaying text messages in the status bar, emitting sounds, vibrating electronic devices, and flashing indicator lights.

[0116] The Android Runtime consists of core libraries and a virtual machine. The Android runtime is responsible for the scheduling and management of the Android system.

[0117] The core library consists of two parts: one part is the functionalities that need to be called by the Java language, and the other part is the Android core library.

[0118] The application layer and application framework layer run in a virtual machine. The virtual machine executes the Java files of the application layer and application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0119] System libraries can include multiple functional modules. For example: surface manager, media libraries, 3D graphics processing libraries (e.g., OpenGL ES), 2D graphics engines (e.g., SGL), etc.

[0120] The Surface Manager is used to manage the display subsystem and provides the blending of 2D and 3D layers for multiple applications.

[0121] The media library supports playback and recording of various common audio and video formats, as well as still image files. It supports multiple audio and video encoding formats, such as MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG.

[0122] The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.

[0123] A 2D graphics engine is a drawing engine for 2D drawing.

[0124] The kernel layer is the layer between hardware and software. The kernel layer contains at least the display driver, camera driver, audio driver, and sensor driver.

[0125] Furthermore, the information interaction method provided in this application embodiment can also be applied to a collaborative work system. The collaborative work system includes the hardware structure of the aforementioned first electronic device and second electronic device.

[0126] The information interaction method described in this application is mainly applied to the application layer of an electronic device. Specifically, it is applied to the capability layer, business layer, and control layer of the application layer. See also Figure 4 This is an architectural block diagram of an application layer provided in an embodiment of this application.

[0127] The business layer includes the control center display interface and a set of business applications. The control center interface is a human-computer interaction interface used to display multi-device collaborative interaction interfaces, including the system user interface (SystemUI), notification bar cards, and the full-screen control center interface.

[0128] SystemUI provides a loading window for the drop-down status bar cards, through which the service status of online services on the device can be loaded.

[0129] Notification bar cards are used to display the business status content of status bar cards.

[0130] The full-screen interface of the control center is used to display the full-screen UI.

[0131] The business application set is used to provide business services, receive business scheduling, and perform business processing. The business application set integrates collaborative services such as keyboard and mouse collaboration, call collaboration, call connection collaboration, and multi-screen collaboration, as well as the corresponding profile software development kits (profile SDKs). The profile SDK is used for writing and reading data to the device service management module. The device service management module is used for device data synchronization. The business application set can also integrate other collaborative services and their corresponding profile SDKs. In this embodiment, other collaborative services are those that enable the first electronic device to connect with other multiple devices. In this embodiment, the business layer also integrates a control center SDK for interaction with the control layer.

[0132] The control layer, as the core module of the multi-device collaborative unified management architecture, includes a communication module, a device management module, a service status management module, a service scheduling management module, and a settings management module. It also includes a communication module SDK for the communication module, a profile SDK for the device management module, and a profile SDK for the service status management module.

[0133] The communication module enables communication between the two control centers, including cross-device command distribution and cross-device querying, and connects to the capability layer's communication module via the communication module SDK. The communication module also facilitates communication between the control centers before connection establishment. If the first electronic device issues a connection command but the current device cannot initiate it, requiring the second electronic device to initiate the connection, the command will be sent to the second electronic device to establish the connection.

[0134] The Device Management module uses the Profile SDK to obtain real-time information on the online / offline status, capability information, and service status of devices under the same account as the first electronic device. The Device Management module includes online devices, connection status management, and all device capability sets. Online devices are used to query currently online devices; connection status management is used to query whether a device is connected and whether it can connect; and all device capability sets are used to obtain multiple device statuses for all devices. Device status includes device online / offline information, capability information, and service status.

[0135] The service status management module uses the Profile SDK to read in real-time service information supported by the first electronic device and surrounding online devices from the device service management module. This includes information such as the list of services supported by this application, service on / off status, whether a service can be scheduled by the control center, specific device types supported by a particular service, connection schemes supported by a particular service, and the current service operating status. The service status management module includes the device's service set and service status management. The device's service set queries the set of services supported by this device, while service status management queries the service status supported by surrounding devices and receives updates on external service status changes, synchronizing these updates to the control center's display interface.

[0136] The service scheduling management module is used to determine service conflicts, issue prompts to users, and issue service instructions based on user intent. Specifically, it handles service connection, switching, and disconnection based on user selection and service conflict callbacks. The module includes service conflict scheduling and service connection management. Service conflict scheduling resolves conflicts. For example, both mobile phones and tablets support screen mirroring, but due to notification restrictions, they cannot coexist, requiring service conflict scheduling to resolve the conflict. Service connection management manages whether multiple devices have collaborative services and whether they can connect.

[0137] The settings management module is used to manage the relevant settings of the control center, including mode settings, etc.

[0138] The capability layer includes the communication module's same-account discovery, legacy service discovery compatibility, and connection transmission, used to realize device connection establishment, transmission, and discovery. The capability layer also includes a device service management module, used to realize device data synchronization, such as online / offline information, capability information, service status, and other device data synchronization, and to store it in the DataController of the data layer for schema persistent storage.

[0139] See Figure 5 This is a schematic diagram of the application layer architecture deployment provided in this application embodiment, applied to the Android platform.

[0140] In the Android platform, the architecture diagram exists as an Android Package (APK). Specifically, the business layer, including the System User Interface (SystemUI), notification bar cards, and the full-screen control center interface, exists as APKs. Business application sets, such as notification collaboration, call-to-action collaboration, and multi-screen collaboration, also exist as APKs. Therefore, the business layer is also called the business APK layer, which includes multiple business APKs. Figure 5The example provided includes systemUI.APK, AA.APK, and PCA.APK. Each service APK represents a specific collaborative service. The communication module, device management module, service status management module, service scheduling management module, and settings management module in the control layer all exist in APK form. Therefore, the control layer exists in the form of a control center APK.

[0141] In the capability layer, the communication module's functions such as same-account discovery, legacy service discovery compatibility, and connection transmission are implemented through XMagiclink.APK, while the device service management module is implemented through XDevice Profile.APK. The service APK interacts with the control center APK through the control center SDK. The control center APK communicates with XMagiclink.APK through the communication module SDK and interacts with XDevice Profile.APK through the device service management SDK.

[0142] To better illustrate the information interaction method provided in this application embodiment, the following uses an Android device as an example to provide a detailed description of the information interaction between the business APK and the control center APK.

[0143] When performing collaborative business operations on a combination of first and second electronic devices, such as Figure 1 As shown, when a user drags a white ball on the main interface of the control center, the control center APK sends scheduling instructions to the business APK through the control center SDK, enabling interaction between the control center APK and the business APK, thereby achieving collaborative business operations.

[0144] In order to enable information interaction between the control center APK and the control center SDK, in this embodiment of the application, when a user performs a service operation on the first electronic device and the second electronic device, the first service scheduling instruction corresponding to the service operation is obtained. When the APK of the first service is not running, or the APK of the second service is not running, the first service scheduling instruction is sent to the control center SDK, so that the control center APK interacts with the service APK of the first service.

[0145] Specifically, when either the first service's APK or the second service's APK is not running, communication is conducted through a preset invocation mechanism. In this embodiment, the preset invocation mechanism allows service invocation to still occur even when one of the control center APK or the service APK is not running.

[0146] In one possible implementation, the default invocation mechanism is ContentProvider.call(). Specifically, both the Control Center APK and Control Center SDK have a ContentProvider component. Through ContentProvider.call(), combined with a default access instruction, such as a Uniform Resource Identifier (URI), the Control Center APK and Control Center SDK access the ContentProvider specified by the URI, thus enabling communication between them. The URI is in the format "standard prefix.authority.data path". The standard prefix indicates that a Content Provider controls this data; the authority uniquely identifies the Content Provider, allowing the target Content Provider to be located; and the data path determines which dataset it is.

[0147] See Figure 6 This diagram illustrates a call mechanism provided in an embodiment of this application. For the control center SDK, the ContentProvider component includes a first data call component (i.e., the ContentResolver of the illustrated business APK), a first called component (i.e., the ControlCenterAARProvider shown in the diagram), and a service component (DccAarService, not labeled in the diagram). For the control center APK, the ContentProvider component includes a second data call component (i.e., the ContentResolver of the illustrated control center APK) and a second called component (i.e., the ControlCenterProvider shown in the diagram). The control center SDK is invoked by the second called component of the control center APK based on the first data call component and in conjunction with preset access instructions. The control center APK is invoked by the first called component of the control center SDK based on the first data call component and in conjunction with preset access instructions, and the relevant business operations, such as business connection establishment, business disconnection, and mode switching, are then performed by the service component.

[0148] Compared to other invocation mechanisms, such as ADIL, the ContentProvider invocation mechanism has high coupling. Furthermore, its implementation only requires integrating the SDK into the business layer to directly use the API interface, enabling business invocation even when either the control center APK or the business APK is not running.

[0149] For devices that may have only one control center APK installed, but multiple centralized control center SDK service APKs, this application employs a dynamic authority approach to differentiate between different services and identify their respective APKs using pre-defined access commands. In one possible implementation, the dynamic authority can be in the form of "application package name.ControlCenterAARProvider". Specifically, the authority is declared in the control center SDK's declaration file as a dynamically concatenated form of "application package name.ControlCenterAARProvider". During control center APK initialization, a mapping relationship between service IDs and application package names is pre-defined. Figure 1 When a user drags a white ball on the main interface of the control center, the system can automatically obtain dynamic authority commands based on the business ID of the white ball and the mapping relationship between the preset business ID and the application package name. Based on the dynamic authority commands, the system can access the ControlCenterAARProvider inside the target business APK.

[0150] The default access command uses a dynamic authority form. This eliminates the need for the business layer to inherit from ControlCenterAARProvider and manually declare the authority, enabling plug-and-play functionality of the control center SDK to the business layer and reducing the error rate of manually declaring access commands.

[0151] To better illustrate the interaction between the control center APK and the control center SDK, the following explanation uses collaborative services as an example for service connection establishment. It is important to note that those skilled in the art will understand that this service connection establishment is merely an example; the underlying communication methods will still be used even if the service is disconnected or the mode is switched.

[0152] In this embodiment, when a user drags a second electronic device to a first electronic device to establish a collaborative service connection, there are four service connection modes: direct service connection, service connection initiated by the second electronic device, direct service connection with additional communication required before connection, and service connection initiated by the second electronic device with additional communication required before connection. The following is a combination of... Figures 7A-7DThe document details four service connection modes. Specifically, `callInnerBusiness` is the first service scheduling instruction, used to instruct the control center APK to interact with the service APK via the control center software development kit (SDK). `callDistributedBusiness` is the second service scheduling instruction, used to instruct the control center APK of the second electronic device and the control center APK of the first electronic device to establish a connection, and to enable the control center APK to interact with the first service APK via the control center SDK.

[0153] See Figure 7A This diagram illustrates a direct service connection establishment method provided in this application embodiment. The control center APK (i.e., controlcenter.APK in the diagram) of the first electronic device issues a first service scheduling instruction, callInnerBusiness, to the service APK. The control center SDK (i.e., controlcenter.SDK in the diagram) of the service APK receives callInnerBusiness. The service APK of the first electronic device initiates a connection establishment operation to the service APK of the second electronic device, and the connection is successfully established, thus realizing direct service connection establishment. In this embodiment, the scheduling instruction callInnerBusiness is an instruction including service information, such as at least one of device ID, device type, service ID, service type, operation type, or service mode, used to determine the specific service for service connection establishment. The service mode includes at least one of disconnection, connection establishment, or switching. The service APK establishes a service connection with the second electronic device according to the instruction received by controlcenter.SDK. The manual collaborative services mentioned above, such as screen extension, screen sharing, and keyboard and mouse collaboration, all belong to the direct service connection establishment mode.

[0154] See Figure 7BThe diagram illustrates a service connection establishment mode initiated by a second electronic device according to an embodiment of this application. Specifically, the controlcenter.APK of the first electronic device sends a service scheduling instruction `callInnerBusiness` to the controlcenter.SDK of the service APK, which receives `callInnerBusiness`. The service APK of the first electronic device then initiates a connection establishment operation to the service APK of the second electronic device. When the service APK cannot establish a service connection, it generates a service call instruction `callDistributedBusiness` to call the peer device. Using the API interface of controlcenter.SDK, `callDistributedBusiness` is sent to the controlcenter.APK of the first electronic device, and forwarded to the controlcenter.APK of the second electronic device through the communication modules of the first and second electronic devices. The controlcenter.APK of the second electronic device obtains the scheduling instruction `callDistributedBusiness` and sends it to the controlcenter.SDK of the service APK, thus establishing the service connection.

[0155] For example, assuming wireless screen mirroring can only be initiated by a mobile phone, when the first electronic device is a tablet and the second electronic device is a mobile phone, the aforementioned service connection is initiated by the second electronic device. In this embodiment, the scheduling instruction `callInnerBusiness` is an instruction that includes service information, such as at least one of device ID, device type, service ID, service type, operation type, or service mode, used to determine the specific service for service connection establishment. The scheduling instruction `callDistributedBusiness` includes at least one of the second electronic device's device ID, service ID, device type, service type, and operation type, used to obtain information about the second electronic device and cause the second electronic device to perform service connection establishment.

[0156] See Figure 7CThe diagram illustrates a direct service connection establishment method provided in this application embodiment, where additional communication is required before connection establishment. The controlcenter.APK of the first electronic device issues a scheduling command `callInnerBusiness`, and the controlcenter.SDK of the service APK receives `callInnerBusiness`. The collaborative service determines whether direct service connection establishment is possible. Additional communication is required before service connection establishment. For example, in a wireless screen projection collaborative service between a mobile phone and a large-screen display device, in addition to the existing scheduling command `callInnerBusiness` (which includes device ID, device type, and service ID), a Bluetooth communication address is also required. However, this Bluetooth communication address is not included in `callInnerBusiness`, necessitating additional communication to obtain the Bluetooth communication address before normal service connection establishment can proceed.

[0157] In this embodiment, the method for implementing additional communication is as follows: the controlcenter.APK of the first electronic device sends an additional communication instruction to the service APK of the first electronic device. If the controlcenter.APK of the first electronic device contains information missing from the first scheduling instruction, it directly sends the additional communication instruction to the service APK of the first electronic device, enabling the service APK of the first electronic device and the service APK of the second electronic device to establish a direct connection. Otherwise, the controlcenter.APK of the first electronic device forwards the communication content to the controlcenter.APK of the second electronic device through the API interface. The controlcenter.APK of the second electronic device initiates an additional communication instruction to the service APK of the second electronic device, obtains the information missing from the first scheduling instruction, and forwards it to the controlcenter.APK of the second electronic device. The controlcenter.APK of the second electronic device forwards the communication content to the controlcenter.APK of the first electronic device and sends the additional communication instruction to the service APK of the first electronic device again. This completes the service establishment operation. For specific additional communication requirements, see [link to relevant documentation]. Figure 10A This will not be discussed further here.

[0158] See Figure 7DThe diagram illustrates a scenario where a second electronic device initiates a service connection, requiring additional communication before connection establishment, according to an embodiment of this application. The first electronic device's controlcenter.APK sends a service scheduling instruction `callInnerBusiness` to the first electronic device's controlcenter.SDK receives `callInnerBusiness`, and the first electronic device's service APK initiates a connection establishment operation to the second electronic device's service APK. When the service APK cannot establish a service connection, it generates a service call instruction `callDistributedBusiness` to invoke the peer device's service. Using the API interface of controlcenter.SDK, `callDistributedBusiness` is sent to the first electronic device's controlcenter.APK, and then forwarded to the second electronic device's controlcenter.APK via the communication modules of the first and second electronic devices. The second electronic device's controlcenter.APK obtains the second electronic device's scheduling instruction `callDistributedBusiness` and sends it to the second electronic device's service APK's controlcenter.SDK to establish the service connection.

[0159] In this embodiment, the method for implementing additional communication involves the first electronic device's controlcenter.APK sending an additional communication instruction to the first electronic device's service APK. If the first electronic device's controlcenter.APK contains information missing from the first scheduling instruction, it directly sends the additional communication instruction to the first electronic device's service APK, enabling direct connection between the first electronic device's service APK and the second electronic device's service APK. Otherwise, the first electronic device's controlcenter.APK forwards the communication content to the second electronic device's controlcenter.APK via an API interface. The second electronic device's controlcenter.APK initiates an additional communication instruction to the second electronic device's service APK, obtains the missing information from the first scheduling instruction, and forwards it to the second electronic device's controlcenter.APK. The second electronic device's controlcenter.APK forwards the communication content to the first electronic device's controlcenter.APK and sends the additional communication instruction to the first electronic device's service APK again. This completes the service establishment operation.

[0160] By combining additional communication commands and scheduling commands, the service connection operation between the second electronic device service APK and the first electronic device service APK is realized.

[0161] The process of a user dragging a second electronic device to a first electronic device to establish a collaborative service connection involves three communication modes: a direct service connection communication mechanism, a service connection establishment mechanism that invokes the peer device's services, and an additional communication mechanism. These will be described in detail below.

[0162] S1: Direct business connection communication mechanism.

[0163] See Figure 8A This is a schematic diagram illustrating a direct service connection communication method provided in an embodiment of this application. The specific implementation is as follows:

[0164] S81: When a user performs a service connection between the first electronic device and the second electronic device on the control center page of the first electronic device, a scheduling instruction is sent to the control center API interface component to schedule the API interface component.

[0165] In this embodiment, when a user establishes a service connection between a first electronic device and a second electronic device, a scheduling instruction `callInnerBusiness` is generated for the first electronic device. This scheduling instruction includes instructions containing service information, such as at least one of the following: device ID, device type, service ID, service type, operation type, or service mode. For example, the scheduling instruction `callInnerBusiness` can be `callInnerBusiness{first electronic device ID, first electronic device type, second electronic device ID, second electronic device type, operation type, service mode}`.

[0166] According to the device scheduling instruction `callInnerBusiness`, the control center application programming interface (API) component is invoked to interact with the control center SDK in the business APK. The control center API component generates a service call message string `DccMessage` and constructs a business message `CallBusinessMessage` based on `DccMessage`. The service call message string `CallInnerBusiness` contains business information strings, such as the sending device ID, sending business ID, receiving device ID, receiving business ID, business message type, and message content. The business message includes the local device ID, this business ID, the remote device ID, the remote business ID, the operation type, the business mode, and additional messages. The sending device ID corresponds to the local device ID, the sending business ID corresponds to this business ID, the receiving device ID corresponds to the remote device ID, and the receiving business ID corresponds to the remote business ID. Based on the message content, the operation type, business mode, and additional messages can be determined.

[0167] In one possible implementation, the control center API interface component checks whether the parameters of the business message are correct. That is, whether the parameters of the business message meet preset conditions. If the preset conditions are met, the parameters of the business message are considered correct; otherwise, the parameters of the business message are considered incorrect. In this embodiment, the preset conditions refer to the correctness of the content of the device's business message, such as the correctness of business parameters involved in business connection establishment, such as device ID and business ID. When all parameters of the business message are correct, a scheduling instruction is issued to the control center SDK to schedule the components of the control center SDK, thereby realizing information interaction between the control center SDK and the control center APK.

[0168] Example explanation: Based on the scheduling instruction callinnerBusiness, obtain the calling business information, including device ID, device type, business ID, etc. Determine whether the obtained business information includes all the business information involved in the scheduling instruction. If it is missing, such as the device ID is missing, the parameters of the scheduling instruction are incorrect.

[0169] S82: The control center API interface component sends a scheduling instruction to the first called component of the control center SDK, and the service component of the control center SDK is triggered to perform the operation based on the first called component.

[0170] In this embodiment, when the control center API interface component determines that the service message parameters corresponding to the service connection are correct, it sends a CallInnerBusiness instruction to the first scheduled component of the control center SDK to call the first scheduled component of the control center SDK to transmit the content of the service corresponding to the service connection.

[0171] The first scheduled component of the control center SDK sends a start command `StartService` to the service component of the control center SDK, invoking the service component to perform related operations. To avoid multiple shutdowns and restarts of the service, an `OnstartCommand` directive is set in the service component to restart the service after each shutdown. In addition, the service component also includes an `OnCallInnerBusiness` directive to load the device's service information and perform service connection establishment operations.

[0172] The service component also includes a function `dispatch By OptionMessage` to send business messages to a specified window. Specifically, it sends the business message `CallInnerBusiness` containing information such as the first electronic device ID, the first electronic device type, the device's service ID, the second electronic device ID, the second electronic device type, the second electronic device's service ID, the operation type, and the business mode to the calling business message instruction `CallInnerBusinessCmd`. It also includes a function to retrieve the static variable `CallBack`, which obtains the business callback information after the business connection is established, including the connection result, device ID, service ID, and service version. This information is then sent to the business callback information instruction function to generate the business callback instruction.

[0173] In this embodiment, the static variable `callBack` is used to determine the information for the business callback. For example, `callBack` may contain information such as switching modes and business versions. These `callBack` values ​​are used as input parameters to the callback instruction, i.e., the callback instruction is passed in so that the business callback instruction contains business connection information.

[0174] S83: After the service component generates the business callback instruction, it sends the pre-check instruction checkBeforeOperation, which calls the pre-check function checkBeforeOperation() of the business callback component to determine whether the business APK is ready.

[0175] To ensure the success rate of business callback execution, this application provides a pre-check method. Before the control center APK calls the collaborative service (Connect mode, Disconnect mode, Operate mode) to execute, the control center APK first calls checkBeforeOperation() to perform a pre-check on the preparation work of the business APK, determining whether the operating environment for the first electronic device to execute the first service is ready. Specifically, after the service component generates the business callback instruction, it first sends a pre-check instruction to call the pre-check function checkBeforeOperation() of the business callback component to check the preparation work of the business layer for callback. Only when it is determined that the callback work is ready does the business callback continue to execute.

[0176] In one possible implementation, the preparation work for the callback might involve checking whether the ContentProvider invocation mechanism class and the inherited ContentProvider class have been created. If preparation is complete, a "Preparation Complete" instruction (True) is returned to the service component before the callback can proceed. Otherwise, the callback is not executed. If the business APK does not require checking (e.g., upon startup, it is assumed to have completed correctly), a "Preparation Complete" instruction is returned to the service component, and the callback is executed.

[0177] By performing pre-call checks before execution, the business layer can improve the success rate of executing callback instructions and avoid repeatedly writing redundant check code in methods such as connect, disConnect, and operate.

[0178] S84: Call the service component to execute the business callback.

[0179] In this embodiment, when either the control center APK or the business APK is not running (taking the business APK as an example), the control center APK calls the ContentProvider in the following way: a. Create a ContentProvider; b. Create a component ContentResolver to receive the ContentProvider; c. Call the ContentProvider. Since c and b can be executed simultaneously, meaning the earliest business callback component is created during the creation of the component receiving the ContentProvider, the business callback component may not be fully created. When the first called component ControlcenterAARProvider of the business APK is called, information cannot be sent to the business callback component of the business APK, causing the call to fail. In this embodiment, the control center APK calls the establishment of a business connection. This also applies to business disconnection or mode switching, which will not be discussed further here.

[0180] To address the aforementioned issues, this application provides a method for service components to execute business callbacks. See also... Figure 8B The diagram shown is a flowchart of a method for a service component to execute a business callback according to an embodiment of this application. Applied to the business layer, the method includes:

[0181] S801: The control center APK issues an instruction to call the first called component of the business APK.

[0182] S802: Determine if the service APK is running. If running, determine if the service component exists. If it exists, execute S807; otherwise, execute S805. If the service APK is not running, execute S803.

[0183] S803: Create ControlcenterAARProvider.

[0184] S804: Create an application component for the business APK, call ControlcenterAARProvider.call(), and forward the first business scheduling instruction to the service component of the first business APK. Alternatively, create an application component for the business APK, then call ControlcenterAARProvider.call(), and forward the first business scheduling instruction to the service component of the first business APK.

[0185] S805: Create a service component.

[0186] S806: Service component restarted.

[0187] S807: Execute business callback.

[0188] Because the service component's lifecycle is later than the first called component, it ensures that the first called component for the business callback has already been created when the service component executes its instructions. Furthermore, since the execution of connection and other instructions is time-consuming, delegating this to the service component prevents the first called component from being blocked and unable to respond to the next instruction in a timely manner.

[0189] S2: Call the peer device's service to establish a service connection communication mechanism.

[0190] See Figure 9 This is a schematic diagram illustrating a service connection establishment process by invoking a peer device's service, as provided in an embodiment of this application. The specific implementation is as follows:

[0191] For example Figure 8A As shown, when the service component cannot perform business connection establishment, i.e., the business needs to initiate business connection establishment by the peer device, a second business scheduling instruction, `callDistributedBusiness`, is first generated. The peer business instruction can construct a call business message, `CallBusinessMessage`. The following steps need to be performed:

[0192] S91: Call the business API interface component and issue the second business scheduling instruction callDistributedBusiness.

[0193] In this embodiment, the business callback component triggers the second business scheduling instruction callDistributedBusiness to call the business API interface component, so as to send the business call message to the control center APK.

[0194] S92: Call the second invoked component of the control center APK and send the call business message to the second invoked component of the control center APK.

[0195] In this embodiment of the application, the business API interface component is invoked, and callDistributedBusiness is sent to the second invoked component of the control center APK. The second invoked component of the control center APK is then invoked to send the business call message to the second invoked component of the control center APK.

[0196] When the second invoked component of the control center APK receives the invoke business message, it generates an internal request message instruction, sends it to the device data management module, and then sends the invoke business message to the control center APK of the second electronic device through the communication module and the communication module of the first electronic device.

[0197] When the second called component of the control center APK does not receive the call business message, the call business message should be reconstructed and the operation should be repeated.

[0198] S93: Calls the registration information listener component of the second electronic device control center APK to listen for call business information.

[0199] The second electronic device control center APK is equipped with a registration information listener component. When a business call message is sent from the first electronic device control center APK to the communication module of the second electronic device control center APK through the communication module, the registration information listener component will listen for the business call message.

[0200] S94: Call the control center API interface of the second electronic device to send the monitored business information to the business APK.

[0201] In this embodiment, when the second electronic device registration information listener component detects business information, it issues a scheduling instruction to call the second electronic device control center API interface component, and forwards the detected business information to the device scheduling instruction callInnerBusiness.

[0202] S95: Issue the scheduling instruction callInnerBusiness, which calls the first scheduled component of the control center SDK of the second electronic device service APK, triggering the service callInnerBusiness component of the second electronic device service APK to perform related operations.

[0203] In this embodiment, a scheduling instruction `callInnerBusiness` is issued to invoke the first scheduled component of the control center SDK of the second electronic device's service APK. The first scheduled component of the control center SDK of the second electronic device issues a start instruction `Start Service` to the service component of the control center SDK, invoking the service component to perform related operations. To avoid multiple service shutdowns and restarts, an `OnstartCommand` instruction is set in the service component to restart the service after each shutdown. Furthermore, the service component also includes an `OnCallInnerBusiness` instruction to load the device's service information and perform service connection establishment operations.

[0204] The service component also includes a function `dispatch By OptionMessage` to send business messages to a specified window. Specifically, it sends the business message `CallInnerBusiness` containing information such as the first electronic device ID, the first electronic device type, the device's service ID, the second electronic device ID, the second electronic device type, the second electronic device's service ID, the operation type, and the business mode to the calling business message instruction `CallInnerBusinessCmd`. It also includes a function to retrieve the static variable `CallBack`, which obtains the business callback information after the business connection is established, including the connection result, device ID, service ID, and service version. This information is then sent to the business callback information instruction function to generate the business callback instruction.

[0205] In this embodiment, the static variable `callBack` is used to determine the information for the business callback. For example, `callBack` may contain information such as switching modes and business versions. These `callBack` values ​​are used as input parameters to the callback instruction, i.e., the callback instruction is passed in so that the business callback instruction contains business connection information.

[0206] S96: After the service component generates the business callback instruction, it sends the pre-check instruction checkBeforeOperation, which calls the pre-check function checkBeforeOperation() of the business callback component to determine whether the business APK is ready.

[0207] To ensure the success rate of business callback execution, this application provides a pre-check method. Before the control center APK calls the collaborative service (Connect mode, Disconnect mode, Operate mode) to execute, the control center APK first calls checkBeforeOperation() to perform a pre-check on the preparation work of the business APK, determining whether the operating environment for the first electronic device to execute the first service is ready. Specifically, after the service component generates the business callback instruction, it first sends a pre-check instruction to call the pre-check function checkBeforeOperation() of the business callback component to check the preparation work of the business layer for callback. Only when it is determined that the callback work is ready does the business callback continue to execute.

[0208] In one possible implementation, the preparation work for the callback might involve checking whether the ContentProvider invocation mechanism class and the inherited ContentProvider class have been created. If preparation is complete, a "Preparation Complete" instruction (True) is returned to the service component before the callback can proceed. Otherwise, the callback is not executed. If the business APK does not require checking (e.g., upon startup, it is assumed to have completed correctly), a "Preparation Complete" instruction is returned to the service component, and the callback is executed.

[0209] S97: The service component of the second electronic device executes a business callback.

[0210] Specific execution of business callbacks and Figure 8B The same applies, so I won't go into details here.

[0211] S3: Additional communication mechanism.

[0212] Since the additional communication occurs before the business connection is established, a listener for receiving business messages needs to be registered before the business APK creates the first invoked component. This allows the service component of the business APK to receive business callbacks. See also Figure 10A This provides an additional communication mechanism implementation method for embodiments of this application. Specifically, it includes:

[0213] S101: Call the business API interface component of the first electronic device business APK and call the second called component of the control center APK to send the business message to the second electronic device control center APK through the communication module.

[0214] In this embodiment of the application, the business API interface component is invoked to generate a call instruction from the business message and issue the call instruction to invoke the second called component of the first electronic device control center APK to send the business message to the second electronic device control center APK.

[0215] In this embodiment, the service message is used to determine the source and destination of the service, including the sending device ID, sending service ID, receiving device ID, receiving service ID, service message type, and message content. The data receiving component receives the service message and sends it to the second electronic device control center APK through the module.

[0216] S102: The second electronic device control center APK is equipped with a registered message listener component that listens for business messages, processes them, and generates listening business messages.

[0217] Similar to the business messages received by the business API interface in S101, the monitored business messages also include the sending device ID, sending business ID, receiving device ID, receiving business ID, business message type, and message content. The monitored business information corresponds one-to-one with the business messages monitored by the registered message listener component; the monitored business information can be obtained based on the monitored business messages.

[0218] S103: Call the registered message listener component of the second electronic device, and call the control center API interface of the second electronic device to send the listened business messages to the business APK of the second electronic device.

[0219] S104: Call the second electronic device service APK data receiving component to receive listening service messages and trigger the second electronic device service component to perform a restart.

[0220] In this embodiment, the control center SDK of the second electronic device's service APK includes a service message listening component. The mapped service message listening library of this component is stored in the service component of the second electronic device's service APK. When the service APK is not running, the service API interface component and the registration service message listener need to be called sequentially during the creation of the first called component. See below for the specific calling method. Figure 10B This will not be discussed further here. Then, the second electronic device service is triggered to execute a load start command between services, loading service information reception and triggering information reception. Specifically, the service information reception is loaded, and based on the service ID, the corresponding listener is retrieved from the additional communication content, and the information listener is invoked to load information reception.

[0221] See Figure 10B This is a schematic diagram illustrating a method for monitoring registration service messages provided in an embodiment of this application. The method includes:

[0222] The business API interface component of the business APK receives and registers business message listeners, creates business message listeners, calls the business message listener component as a registration instruction, and calls the business API interface to store the business ID and business message listener in the mapped business message listener library. This mapped business message listener library is stored in the service component of the business APK.

[0223] In one possible implementation, if the business needs to understand the received business information when it is scheduled, it needs to be called during the creation of the first called component.

[0224] In one possible implementation, when the business is running and no longer needs to receive business information, the master and slave servers cancel their business message listening. Specifically, the business API interface component of the business APK, which does not need to register information listening, calls the service component of the business APK to remove the business ID and business message listener from the mapped business message listener library. In this way, the sender can continue to send business information to the receiver, but the receiver does not perform any data processing.

[0225] The control center SDK directly provides an additional communication mechanism, allowing business APKs to communicate directly through the control center API. This eliminates the need for complex communication connections during the scheduling process, improving the efficiency of business access to the control center.

[0226] In one possible implementation, a TCP / IP-like message encapsulation format is used for communication messages. A generic message, `DccMessage`, is defined for inheritance and extension (e.g., `CallBusinessMessage` inherits from `DccMessage`). `sourceDeviceId` and `destDeviceId` represent the "source IP address" and "destination IP address," respectively; `sourceBusinessId` and `destBusinessId` represent the "source port address" and "destination port address," respectively. Based on this information, the source and destination of the message can be uniquely determined. Simultaneously, the encapsulated message class is used as a callback parameter for listening to business messages, reducing the number of input parameters and improving the coding efficiency of the business layer. Example illustration:

[0227]

[0228] In one possible implementation, the aforementioned TCP / IP-like message encapsulation format is used for general instructions.

[0229] Example description: CallBusinessCmd is used as the input parameter for an API that initiates a cross-device command.

[0230]

[0231] By standardizing message or command encapsulation, there is no need to manually fill in command-related parameters one by one, which reduces code complexity and improves coding efficiency of the business layer.

[0232] Through the above description of the embodiments, those skilled in the art will clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device, and unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

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

[0234] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

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

[0236] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this embodiment, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments. The aforementioned storage medium includes various media capable of storing program code, such as flash memory, portable hard disk, read-only memory, random access memory, magnetic disk, or optical disk.

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

Claims

1. A method for information exchange, characterized in that, The method is applied to a first electronic device, which has an Android application package APK for collaborative services and a control center APK installed. The control center APK is used to control the first electronic device to establish a connection with a second electronic device through the collaborative services APK and to implement collaborative services, wherein the collaborative services include a first service. The method includes: In response to a user's execution of a service operation on the first electronic device and the second electronic device, a first service scheduling instruction is obtained; the first service scheduling instruction is used to instruct the control center APK to interact with the APK of the first service through the control center SDK; the second electronic device is a device that can connect to the first electronic device; When the APK of the first service is not running, or when the APK of the control center is not running, the scheduling instruction of the first service is sent to the control center SDK so that the control center APK and the APK of the first service can interact.

2. The method according to claim 1, characterized in that, The control center SDK is integrated into the APK of the first service.

3. The method according to claim 1, characterized in that, Sending the first service scheduling instruction to the control center SDK specifically includes: The first service scheduling instruction is sent to the control center SDK of the first electronic device by invoking the control center application programming interface (API) component and the second data call component of the control center APK.

4. The method according to claim 3, characterized in that, The method further includes: Control the first electronic device and the second electronic device to establish a connection to collaboratively process the first service; The service component of the first service's APK is invoked to send the service operation result of the first service back to the control center APK.

5. The method according to claim 4, characterized in that, The service components that invoke the APK of the first service include: When the APK of the first service is not running, a first invoked component of the APK of the first service is created, and an application component of the APK of the first service is created; the application component of the APK of the first service is used to send the scheduling instruction of the first service to the APK of the first service. The first invoked component is invoked, and the first service scheduling instruction is forwarded to the service component of the first service's APK; the service component of the first service's APK is created and started, so as to call back the service operation result of the first service to the control center APK; When the APK of the first service is running and the service component of the APK of the first service exists, the service component of the APK of the first service is invoked to send the business operation result of the first service back to the control center APK.

6. The method according to any one of claims 4 or 5, characterized in that, Before invoking the service component of the APK of the first service, the method further includes: When the APK of the first service determines that the operating environment for the first electronic device to execute the first service is ready, it calls the service component of the APK of the first service.

7. The method according to claim 1, characterized in that, The method further includes: When the first service cannot be executed, a second service scheduling instruction is sent to the control center APK; the second service scheduling instruction is used to instruct the control center APK to establish a connection with the second electronic device, and to enable the control center APK of the second electronic device to interact with the service APK of the second electronic device through the control center SDK of the second electronic device. The second service scheduling instruction is sent to the control center APK of the second electronic device to implement the first service.

8. The method according to claim 1, characterized in that, The method further includes: When the APK of the first service determines that there is missing information in the scheduling instruction of the first service, it controls the control center APK to send an information request instruction to the second electronic device to request the second electronic device to receive the missing information in the scheduling instruction of the first service sent by the first electronic device; The APK of the first service receives additional communication instructions sent by the second electronic device, the additional communication instructions carrying information missing from the scheduling instructions of the first service.

9. The method according to claim 1, characterized in that, The first service scheduling instruction is an instruction encapsulated in a TCP / IP-like format.

10. A method for information exchange, characterized in that, The method is applied to a second electronic device, which has an Android application package APK for collaborative services and a control center APK installed. The control center APK is used to control the second electronic device to establish a connection with a first electronic device and to implement collaborative services through the collaborative services APK. The collaborative services include a first service. The method includes: In response to a user's execution of a first service operation on the first electronic device and the second electronic device, when the first electronic device is unable to execute the first service, a second service scheduling instruction is received from the control center APK of the first electronic device; the second service scheduling instruction is used to instruct the control center APK of the second electronic device and the control center APK of the first electronic device to establish a connection, and to enable the control center APK to interact with the APK of the first service through the control center SDK; When the APK of the first service is not running, and / or the APK of the control center is not running, the second service scheduling instruction is sent to the control center SDK so that the control center APK and the APK of the first service can interact.

11. The method according to claim 10, characterized in that, The control center SDK is integrated into the APK of the first service.

12. The method according to claim 10, characterized in that, Sending the second service scheduling instruction to the control center SDK to enable the control center APK to interact with the first service APK includes: The second service scheduling instruction is sent to the control center SDK by invoking the control center application programming interface (API) component and the second data call component of the control center APK.

13. The method according to claim 12, characterized in that, The method further includes: Control the first electronic device and the second electronic device to establish a connection to collaboratively process the first service; The service component of the first service's APK is invoked to send the service operation result of the first service back to the control center APK.

14. The method according to claim 13, characterized in that, The service components that invoke the APK of the first service include: When the APK of the first service is not running, a first invoked component of the APK of the first service is created, and an application component of the APK of the first service is created; the application component of the APK of the first service is used to send the scheduling instruction of the second service to the APK of the first service. The first invoked component is invoked, and the first service scheduling instruction is forwarded to the service component of the first service's APK; the service component of the first service's APK is created and started, so as to call back the service operation result of the first service to the control center APK; When the APK of the first service is running and the service component of the APK of the first service exists, the service component of the APK of the first service is invoked to send the business operation result of the first service back to the control center APK.

15. The method according to any one of claims 13 or 14, characterized in that, Before invoking the service component of the APK of the first service, the method further includes: When the APK of the first service determines that the operating environment for the first electronic device to execute the first service is ready, it calls the service component of the APK of the first service.

16. The method according to claim 10, characterized in that, The method further includes: The control center APK receives an information request instruction sent by the first electronic device and sends the information request instruction to the service APK of the second electronic device; the information request instruction is used to indicate the missing information in the first service scheduling instruction; The service APK of the second electronic device sends an additional communication instruction to the first electronic device according to the information request instruction. The additional communication instruction carries information that is missing from the first service scheduling instruction.

17. The method according to claim 10, characterized in that, The second service scheduling instruction is an instruction using a TCP / IP-like encapsulation format.

18. An electronic device, characterized in that, The electronic device includes: A memory and a processor, wherein the memory is coupled to the processor; The memory stores program instructions that, when executed by the processor, cause the electronic device to perform the method described in any one of claims 1-9.

19. An electronic device, characterized in that, The electronic device includes: A memory and a processor, wherein the memory is coupled to the processor; The memory stores program instructions that, when executed by the processor, cause the electronic device to perform the method according to any one of claims 10-17.

20. A collaborative work system, characterized in that, The system includes the electronic device of claim 18, and also includes the electronic device of claim 19.

Images