A detection method, related electronic device and system

Abstract

The application discloses a detection method, an electronic device and a system. By listening to the service message transceiving event and transceiving result between devices, the device online state machine is driven to migrate, and the device state change can be quickly perceived. The method increases the active detection mechanism, sets up a new device state - silent state, and a silent detection interface, supports the application to determine the UI presentation and business processing strategy of various states of the device. When the passive detection times out, the online state will change to the silent state. In the silent state, the local device can actively broadcast the detection message as needed to confirm whether the opposite device is online, solve the problem that the device state cannot be updated in time and is prone to error, effectively reduce the device offline delay, resource power consumption, and transmission bandwidth occupation, avoid the defect that the device is frequently online and offline due to temporary disconnection, provide a more intuitive and easy-to-understand application interaction interface for the user, improve the user experience, and further improve the communication efficiency.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a detection method, related electronic equipment and system. Background Technology

[0002] With the upgrading of consumption, users own an increasingly large number of smart terminal devices. For a system composed of multiple terminals, users can use a software platform to manage the various distributed devices in the system in a unified manner, such as viewing the status of each device, adjusting the hardware resources and capabilities of each device, and distributing and synchronizing business data in the system.

[0003] Keepalive between any two or more devices forming a connection in the system can be maintained through a long connection mechanism or a heartbeat mechanism. However, maintaining this long connection mechanism or heartbeat mechanism will continuously occupy resources and waste power, inevitably causing the terminal device to continuously consume traffic and / or power, shortening the standby time of the terminal device, which has obvious drawbacks. Summary of the Invention

[0004] This application provides a detection method, related electronic equipment, and system. The detection method drives the online state machine migration of devices by monitoring the sending and receiving events and results of business messages between devices, allowing for rapid detection of device state changes. This method adds an active detection mechanism and establishes a new device state—the silent state—as well as a silent detection interface, supporting applications in determining the UI presentation and business processing strategies for various device states. When a device is in the online state, it changes to the silent state when passive detection times out. In the silent state, the local device can actively broadcast detection messages as needed to confirm whether the peer device is online.

[0005] The aforementioned and other objectives will be achieved through the features described in the independent claims. Further implementations are illustrated in the dependent claims, the specification, and the drawings.

[0006] In a first aspect, embodiments of this application provide a detection method, comprising: establishing a connection between a first device and a second device, wherein the first device records the status of the second device, including an online state, an offline state, and a silent state. The online state indicates that communication between the first device and the second device is normal; the offline state indicates that communication between the first device and the second device is abnormal; and the silent state indicates that the communication between the first device and the second device is uncertain and needs to be confirmed by re-detection to determine whether the second device is in an online or offline state. When a message is received from the second device, the first device refreshes the status of the second device to the online state and starts a timer. The first device confirms that the time interval for not receiving a message from the second device exceeds a first time limit. The first device then changes the status of the second device from the online state to the silent state.

[0007] Implementing the first approach can solve the problems of untimely device status updates and frequent errors, effectively reduce device offline latency, resource consumption, and transmission bandwidth usage, avoid the defects of frequent online and offline due to brief disconnections, provide users with a more intuitive and easy-to-understand application interface, improve user experience, and further improve communication efficiency.

[0008] In conjunction with the first aspect, in some embodiments, the first device is provided with a device status bit that indicates the number of interrupts of the timer, and the device status bit includes reset and set.

[0009] In conjunction with the first aspect, in some embodiments, when the first device refreshes the status of the second device to online, the first device changes its device status bit to reset. When the first device detects a timer overflow interrupt, the first device reads the device status bit. If the device status bit is read as reset, the first device changes it to set. If the device status bit is read as set, the first device confirms that the triggering condition for changing the silent state is met.

[0010] In conjunction with the first aspect, in some embodiments, when the first device detects a first timer overflow interrupt, the first device reads that the device status bit is reset. The first device changes the device status bit from reset to set and restarts the timer to start counting. When the first device detects a second timer overflow interrupt, the first device reads that the device status bit is set, and the first device confirms that the triggering condition for changing the silent state is met.

[0011] Setting the condition that the online status change to silent status is triggered only after two timer overflow interrupts can avoid the problem of frequent online / offline changes caused by the second device temporarily going offline due to unstable connection when there is no message exchange between the first and second devices.

[0012] In conjunction with the first aspect, in some embodiments, the first time required for the first timer overflow interrupt is different from the second time required for the second timer overflow interrupt. For example, the second time may be longer than the first time.

[0013] Developers can also set the interrupt trigger time according to different peer device types, different time periods, or other factors. For example, during periods when users use the device frequently, the timer's time limit can be set shorter, while during periods when users use the device less frequently, such as at night, the timer's time limit can be set longer.

[0014] In conjunction with the first aspect, in some embodiments, when the second device is in a silent state, the first device sends a first probe message to the second device. If the first device receives a response message from the second device in response to the first probe message, the first device changes the state of the second device from silent to online. If the first device does not receive a response message from the second device in response to the first probe message, the first device changes the state of the second device from silent to offline.

[0015] In conjunction with the first aspect, in some embodiments, the aforementioned first probe message can be a broadcast message. Compared to unicast, the advantage of sending a broadcast probe message is that broadcast sends more messages per unit time, messages are less likely to be lost, and the transmission success rate is higher.

[0016] In conjunction with the first aspect, in some embodiments, the application interface of the first device displays an icon of the second device. If the second device is online, its icon is highlighted in the application interface. If the second device is inactive, its icon is grayed out. If the second device is offline, its icon is not displayed in the application interface. This allows users to quickly perceive the status of the second device through the interface.

[0017] In conjunction with the first aspect, in some embodiments, the first device detects a user action by clicking an icon of a grayed-out second device. In response to this user action, the first device sends a first probe message to the second device.

[0018] In conjunction with the first aspect, in some embodiments, when the first device detects that the aforementioned application is running in the foreground, the first device sends a first probe message to the second device. This allows for faster triggering of proactive probing, enabling early detection of whether the second device is online when user interaction is anticipated.

[0019] In conjunction with the first aspect, in some embodiments, the first device is equipped with a silent detection interface. The first device detects that the aforementioned application is calling this silent detection interface. Events triggering this call include the first device detecting a user action such as clicking a grayed-out icon of the second device, or the first device detecting that the application is running in the foreground. Then, the first device sends a first detection message to the second device through this silent detection interface.

[0020] In conjunction with the first aspect, in some embodiments, if the first device confirms that the second device is in a silent or offline state, the timer is terminated.

[0021] In conjunction with the first aspect, in some embodiments, if the first device successfully sends a message to the second device when the second device is in an offline state, the first device changes the state of the second device from offline to online.

[0022] In conjunction with the first aspect, in some embodiments, if the first device fails to send a message to the second device when the second device is in an online state, the first device changes the state of the second device from online to offline.

[0023] Secondly, embodiments of this application provide an electronic device that may include: a communication device, a display device, a memory, and a processor coupled to the memory, multiple application programs, and one or more programs. The communication device is used for communication, the display device is used for displaying an interface, and the memory stores computer-executable instructions. When the processor executes the instructions, the electronic device can perform any of the functions of the first device described in the first aspect.

[0024] Thirdly, embodiments of this application provide a communication system, which includes a first device and a second device, wherein the first device implements any of the possible implementations described in the first aspect.

[0025] Fourthly, embodiments of this application provide a computer storage medium storing a computer program, the computer program including executable instructions, which, when executed by a processor, cause the processor to perform operations corresponding to the method provided in the first aspect.

[0026] Fifthly, embodiments of this application provide a computer program product that, when run on an electronic device, causes the electronic device to perform any possible implementation as described in the first aspect.

[0027] In a sixth aspect, embodiments of this application provide a chip system that can be applied to an electronic device. The chip includes one or more processors, which are used to invoke computer instructions to cause the electronic device to implement any of the possible implementations described in the first aspect.

[0028] Implementing the aspects provided in this application can solve the problems of untimely device status updates and easy error reporting, effectively reduce device offline latency, resource power consumption, and transmission bandwidth usage, avoid the defects of frequent online and offline due to brief disconnections, provide users with a more intuitive and easy-to-understand application interface, improve user experience, and further improve communication efficiency. Attached Figure Description

[0029] Figure 1 A schematic diagram of a communication system provided in an embodiment of this application;

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

[0031] Figure 2B A schematic diagram of the software architecture of the electronic device provided in the embodiments of this application;

[0032] Figure 3 This is a schematic diagram of state transitions provided for an embodiment of this application;

[0033] Figure 4 This is a schematic diagram of state transitions provided for an embodiment of this application;

[0034] Figure 5 A schematic diagram of the user interface provided for an embodiment of this application;

[0035] Figure 6A This is a schematic diagram of the interactive interface provided in an embodiment of this application;

[0036] Figure 6B This is a schematic diagram of the interactive interface provided in an embodiment of this application;

[0037] Figure 7 This is a schematic diagram of the information flow process provided in the embodiments of this application;

[0038] Figure 8 This is a schematic diagram of the information flow process provided in the embodiments of this application;

[0039] Figure 9 This is a schematic diagram of the information flow process provided in the embodiments of this application;

[0040] Figure 10 This is a schematic diagram of the information flow process provided in the embodiments of this application;

[0041] Figure 11 A flowchart of a detection method provided in an embodiment of this application;

[0042] Figure 12 This is a schematic diagram of the functional modules of an electronic device provided in an embodiment of this application. Detailed Implementation

[0043] The technical solutions in the embodiments of this application will be clearly and thoroughly described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; the word "and / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone.

[0044] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more.

[0045] In the following embodiments of this application, the term "user interface (UI)" refers to the medium interface through which an application (APP) or operating system (OS) interacts and exchanges information with the user. It realizes the conversion between the internal form of information and the form that the user can accept. The user interface is source code written in a specific computer language such as Java or Extensible Markup Language (XML). The interface source code is parsed and rendered on the electronic device, ultimately presenting content that the user can recognize. A common form of user interface is the graphical user interface (GUI), which refers to a user interface related to computer operation displayed graphically. It can be visible interface elements such as text, icons, buttons, menus, tabs, text boxes, dialog boxes, status bars, navigation bars, and widgets displayed on the screen of an electronic device.

[0046] The term "message" or "information" mentioned in the following embodiments of this application may refer to a specific message or information, or it may include multiple different messages or information, forming a collection of messages or information. This embodiment does not impose any limitations. For example, a message or information may be a session message of an application, a set of session messages and instruction information of an application, or a set of session messages of an application, instruction information, and a terminal device identifier. The specific interpretation can be inferred from the context.

[0047] For a system consisting of multiple terminals, users can use a software platform to manage the various distributed devices in the system in a unified manner. For example, they can view the status of each device, adjust the hardware resources and capabilities of each device, and distribute and synchronize business data in the system.

[0048] Between any two or more devices (or servers) forming a connection in a system, a persistent connection mechanism can be used to maintain the connection state. For example, classic Bluetooth uses asynchronous connectionless (ACL) persistent connections to keep the device alive. A persistent connection mechanism means that once the two terminal devices establish a connection, they do not disconnect and then transmit messages through that connection until one party actively terminates the connection. This persistent connection mechanism can ensure that messages are delivered to the other device in a timely manner, but its disadvantages are also obvious. Maintaining the persistent connection will continuously occupy resources and waste power, inevitably causing the terminal device to continuously consume data traffic and / or battery power, shortening the standby time of the terminal device. Here, data traffic can refer to network data traffic, including network traffic generated when the terminal device sends data through a wireless network or mobile network.

[0049] Between any two or more devices (or servers) forming a connection in the system, a heartbeat mechanism can be used for keep-alive. A heartbeat mechanism refers to a device periodically sending a keep-alive message to the peer device (or server) to detect whether the peer device is alive, thus maintaining the connection between the two devices for a long time and ensuring that data sent by one device to the peer device arrives accurately and promptly. Sending heartbeat messages maintains the online status of the terminal device; being online indicates that the terminal device is authenticated and does not require re-authentication to send or receive messages. Once a specified time interval has elapsed since the last heartbeat message was sent, the terminal device will be taken offline, and upon reconnection, it will need to be authenticated again.

[0050] For example, a Wi-Fi connection can unicast a Transmission Control Protocol (TCP) message every ten minutes to keep the connection alive, or Bluetooth Low Energy (BLE) can broadcast a message every five minutes, waiting for a response from the remote device to keep it alive. When the remote device's response times out, the local device changes the remote device's status from online to offline.

[0051] This heartbeat mechanism also has the following drawbacks: First, it cannot promptly confirm the offline status of the peer device between two heartbeat probes. After one device disconnects, other devices can only detect its offline status during the next heartbeat probe. During this period, users cannot perceive the device's offline status on the interface, resulting in errors when issuing operation commands for that device, leading to a poor user experience. Second, if a high-network-load application is running, bandwidth may be consumed by that application, potentially causing false offline reports of peer devices and resulting in abnormal service interruptions, also leading to a poor user experience. Third, the local device continuously sends heartbeat messages to the peer device or passively receives heartbeat information from the peer device. Furthermore, as the number of connected peer devices increases, the number of heartbeat messages the local device needs to send or receive also increases exponentially, consuming significantly more bandwidth. Fourth, when a terminal device sends data, it needs to activate the radio frequency module. Every time the device sends or receives a heartbeat message, it needs to activate the radio frequency module in the terminal, which will wake up the device from the dormant state. This will cause the radio frequency module to be activated frequently, consuming more power, resulting in increased power consumption of the terminal device and shortening the standby time of the terminal device.

[0052] On the other hand, if the peer device temporarily leaves the signal coverage area, causing it to temporarily lose connection, it may need to re-execute the authentication and login process when it communicates with the local device again. This increases the complexity of device communication, reduces communication efficiency, and thus affects the user experience.

[0053] This application provides a detection method for detecting device status, addressing issues such as untimely device status updates, high power consumption, and cumbersome communication. This method eliminates the commonly used heartbeat mechanism in communication, completely resolving issues of high power consumption and bandwidth occupation, and further optimizing communication efficiency. By monitoring the sending and receiving events and results of passive or active detection of service messages between devices, it drives the online state machine migration of the device, allowing for rapid detection of device status changes. This method adds an active detection mechanism and establishes a new device state—the silent state—along with a silent detection interface, supporting applications in determining the UI presentation and business processing strategies for various device states. When a device is online, and passive detection times out, the online state changes to the silent state. In the silent state, the local device can actively broadcast detection messages as needed to confirm whether the peer device is online, resolving issues of frequent device status errors and poor user experience, effectively reducing device offline latency and power consumption, avoiding the defects of frequent online and offline due to brief disconnections, and further improving communication efficiency. The process of describing an object's transition from one state to another through an event is called a state transition. All the state transition processes that an object possesses are called a state machine.

[0054] Implementing the method provided in this application can solve problems such as high power consumption, bandwidth consumption, and frequent online / offline cycles caused by the heartbeat message keep-alive mechanism between devices in the system. By introducing a new device state, namely the silent state, it supports applications in determining the UI presentation and business processing strategies for various states, solving the problem of untimely device state updates, further optimizing communication efficiency, and enhancing human-computer interaction performance. It can provide users with a more intuitive, easier-to-understand, and more convenient application interaction interface. By listening to the sending and receiving events and results of business messages between devices, it drives the online state machine migration of devices, allowing users to perceive changes in device state in real time and improving user experience.

[0055] The following describes the communication system 10 provided in the embodiments of this application.

[0056] Figure 1 The present application illustrates a communication system 10 provided in an embodiment.

[0057] The communication system 10 includes multiple terminal devices, which may include, as shown in the illustration, mobile phones, tablets (portable Android devices, PADs), laptops, smart TVs (also known as smart screens, large screens, etc.), desktop computers, routers, smartwatches, smart bracelets, headphones, smart speakers, etc., in addition to... Figure 1 The communication system 10, as shown above, may also include other types of electronic devices, such as personal computers (PCs), desktop computers, laptop computers, handheld computers, augmented reality (AR) devices, virtual reality (VR) devices, artificial intelligence (AI) devices, in-vehicle systems, game consoles, cloud hosts / servers, and other smart wearable devices. It may also include Internet of Things (IoT) devices or smart home devices such as smart water heaters, smart lights, smart air conditioners, and smart scales. This application does not impose any restrictions on the type of device. In this embodiment, the terminal device may also be simply referred to as a terminal. A terminal device is typically an intelligent electronic device that can provide a user interface, interact with the user, and provide business functions to the user.

[0058] For example, such as Figure 1As shown, the networking logic model of the communication system 10 can be such that each rich device connects to a network with a router as the node, and multiple thin devices join the network by connecting to a mobile phone, with the mobile phone and multiple rich devices forming a point-to-point connection. Rich devices can refer to terminal devices with strong processing power and rich functionality, such as mobile phones, laptops, tablets, smart TVs, and desktop computers. Thin devices can refer to terminal devices with weaker processing power and relatively fewer functions, such as smartwatches, headphones, smart bracelets, and smart speakers. Thin devices can work in conjunction with rich devices to provide users with richer functionality.

[0059] In communication system 10, the mobile phone, as a central / core device, can establish communication connections with other collaborative / related devices to form a "super terminal." A "super terminal" refers to the integration of the capabilities of multiple terminals through distributed technology, storing them in a virtual hardware resource pool. It manages, schedules, and integrates the capabilities of each terminal according to business needs to provide services externally, enabling rapid connection, capability sharing, and resource sharing between different terminals. For example, a mobile phone and a laptop forming a super terminal can project the mobile phone interface onto the laptop screen; a mobile phone and a smart speaker forming a super terminal can remotely control the smart speaker, and so on.

[0060] It should be noted that, in the embodiments of this application, the term "super terminal" can be used to collectively refer to the communication system 10, which consists of a mobile phone as the core device and related devices having the aforementioned relationship with the mobile phone. That is, "super terminal" is used to describe a collection of electronic devices having the aforementioned relationship. It is understood that "super terminal" is only an exemplary descriptive term and can be replaced with other terms, such as "intelligent collaborative system," "multi-device collaborative system," etc., which does not constitute a specific limitation on the communication system 10 in the embodiments of this application.

[0061] The communication connection between the various terminal devices in the communication system 10 can be a wired connection or a wireless connection; this embodiment does not impose any restrictions. The various terminals can transmit data or instructions through the established communication connection.

[0062] The communication connection can be a short-range communication connection, such as a wired connection, like a Universal Serial Bus (USB) connection, a High Definition Multimedia Interface (HDMI) connection, or a DisplayPort (DP) connection. Alternatively, it can be a wireless connection, such as a Bluetooth (BT) connection, a Wi-Fi connection, a hotspot connection, Near Field Communication (NFC), or ZigBee, enabling communication between terminals without accounts or with different accounts. Wireless connections are not bound by wires, allowing for greater freedom of movement for users. This application does not limit the type of communication connection. The terminal device may be configured with a Bluetooth (BT) module and / or a Wireless Local Area Network (WLAN) module. The Bluetooth module can provide solutions for Bluetooth communication, including Bluetooth Classic (Bluetooth 2.1) or Bluetooth Low Energy (BLE). The WLAN module can provide solutions for WLAN communication, including Wi-Fi P2P, Wi-Fi LAN, or Wi-Fi softAP. In some embodiments, Wi-Fi P2P refers to allowing devices in a wireless network to connect to each other in a point-to-point manner without a wireless router. This system is also known as Wireless Fidelity Direct (Wi-Fi Direct). Devices establishing a Wi-Fi P2P connection can exchange data directly via Wi-Fi (must be on the same frequency band) without being connected to a network or hotspot, enabling point-to-point communication such as transferring files, pictures, and videos. Compared to Bluetooth, Wi-Fi P2P has advantages such as faster search and transmission speeds, and longer transmission distances.

[0063] This communication connection can also be a long-distance communication connection. For example, various terminals can log in to the same account to connect and communicate via the Internet. Multiple electronic devices in the communication system 10 can also log in to different accounts, but connect through binding. For example, a mobile phone and a smartwatch can log in to different accounts. The mobile phone binds the smartwatch to itself in a device management application, and then connects through the device management application.

[0064] Furthermore, multiple terminal devices in the communication system 10 can also connect and communicate using any of the above methods, and this application embodiment does not impose any limitations on this. For example, the communication connection between a mobile phone and a laptop can be composed of multiple connections. For instance, the mobile phone or laptop can establish a connection with a router via Wi-Fi to access the network, or establish a connection with a base station via cellular signal to access the network. The mobile phone and laptop can then communicate through the network. For example, the mobile phone can send information to a cloud server via the network, and the cloud server can then send the information to the laptop via the network.

[0065] In some embodiments, when two terminal devices are trusted by each other, such as when they have previously paired or connected, they will automatically establish a communication connection and exchange data upon reconnection, eliminating the need for manual reconnection or pairing by the user, thus saving time and effort. For example, electronic devices that have been paired via Bluetooth, connected to a shared hotspot, or established a Wi-Fi P2P connection can be considered to have established a trusted relationship; this embodiment does not limit this to a specific case.

[0066] Each terminal device in the communication system 10 can be equipped with system, system, The operating systems of the various terminal devices in the communication system 10 may be the same or different, whether it is HarmonyOS or other types of operating systems. This application does not impose any restrictions on this. In some embodiments, each terminal connected in the communication system 10 is equipped with HarmonyOS, then the communication system 10 may be called a HarmonyOS super virtual terminal or a HarmonyOS super terminal.

[0067] In some embodiments, a super terminal application is installed on the mobile phone or other terminal device to facilitate user management of various terminal devices. For example, a smartwatch can detect the user's exercise data, such as steps taken, running duration, swimming duration, etc., and synchronize the user's exercise data to the mobile phone. Similarly, the mobile phone can also synchronize the detected user data to the smartwatch. The use of multiple terminals in combination can achieve more accurate detection of the user's exercise data.

[0068] In this embodiment, the central device in the communication system 10 can record the connection status of the collaborating devices and display it in the user interface, allowing users to quickly check whether the collaborating devices are currently online. If the collaborating device is online, it means that the central device and the collaborating device can currently communicate and send / receive messages normally. If the collaborating device is offline, it means that the current collaborating device and the central device have lost their connection and cannot communicate normally. If the collaborating device is in a silent state, it means that the connection status between the current collaborating device and the central device is uncertain. Users can actively initiate a probe operation, such as clicking the grayed-out collaborating device icon. The central device will send a probe message to the collaborating device. If the probe is successful, i.e., a response is received from the collaborating device, the status of the collaborating device will be changed from silent to online. If the probe fails, i.e., no response is received from the collaborating device, the status of the collaborating device will be changed from silent to offline.

[0069] It should be noted that, Figure 1 The communication system 10 shown is only used to assist in describing the technical solutions provided in the embodiments of this application and does not constitute a limitation on other embodiments of this application. In actual business scenarios, the communication system 10 may include more or fewer terminal devices, and the network logical model may also be other star, ring, point-to-point, or arbitrary combination forms. This application does not impose any limitations on the type of terminal devices, the number of terminal devices, the network logical model, or the connection method between each terminal device in the communication system 10.

[0070] The following describes an exemplary electronic device 100 provided in an embodiment of this application.

[0071] Figure 2AThis is a schematic diagram of the hardware structure of the electronic device 100 provided in the embodiments of this application. The exemplary electronic device 100 provided in the embodiments of this application may be, but is not limited to, mobile phones, laptops, tablets, smart bracelets, smartwatches, headphones, personal computers (PCs), smart TVs, smart speakers, etc. It may also be desktop computers, laptops, handheld computers, AR devices, VR devices, AI devices, in-vehicle systems (vehicle-mounted devices), game consoles, cloud hosts / cloud servers, other smart wearable devices, or Internet of Things (IoT) devices or smart home devices such as smart water heaters, smart lights, smart air conditioners, smart scales, and other types of electronic devices. This application does not impose any restrictions on the type of device.

[0072] It is understood that the structure illustrated in this embodiment does not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than illustrated, and may add or remove parts of the hardware structure, combine or separate certain components, or arrange different components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0073] refer to Figure 1 The electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0074] Processor 110 is typically used to control the overall operation of electronic device 100 and may include one or more processing units. For example, processor 110 may include a central processing unit (CPU), application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), video processing unit (VPU), controller, memory, video codec, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors. The controller can generate operation control signals based on instruction opcodes and timing signals to control instruction fetching and execution.

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

[0076] 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, a serial peripheral interface (SPI) interface, etc.

[0077] The charging management module 140 receives charging input from a charger. The charger can be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 receives charging input from the wired charger via a USB interface 130. In some wireless charging embodiments, the charging management module 140 receives wireless charging input via the wireless charging coil of the electronic device. While charging the battery 142, the charging management module 140 can also supply power to the electronic device via the power management module 141.

[0078] The power management module 141 connects the battery 142, the charging management module 140, and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140, providing power to the processor 110, internal memory 121, display screen 194, camera 193, and wireless communication module 160, etc. The power management module 141 can also be used to monitor parameters such as battery capacity, battery cycle count, and battery health status (leakage current, impedance).

[0079] The wireless communication function of electronic device 100 can be realized through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor, etc.

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

[0081] The mobile communication module 150 can provide solutions for wireless communication applications on the electronic device 100, including second-generation (2G), third-generation (3G), fourth-generation (4G), and fifth-generation (5G) networks. 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 antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a 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 antenna 1. 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.

[0082] A modem processor may include a modulator and a demodulator.

[0083] The wireless communication module 160 can provide solutions for wireless communication applications on the electronic device 100, including wireless local area networks (WLANs) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signals, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

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

[0085] Electronic device 100 can implement display functions through a GPU, display screen 194, and application processor. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. Processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0086] Display screen 194 is used to display images, videos, etc. Display screen 194 includes a display panel. The display panel can be manufactured using liquid crystal display (LCD), organic light-emitting diode (OLED), active-matrix organic light-emitting diode (AMOLED), flexible light-emitting diode (FLED), Miniled, MicroLED, Micro-OLED, quantum dot light-emitting diodes (QLED), etc. In some embodiments, electronic device 100 may include one or N displays 194, where N is a positive integer greater than 1.

[0087] Electronic device 100 can perform shooting functions through ISP, camera 193, video codec, GPU, display 194 and application processor.

[0088] The ISP (Image Signal Processor) is used to process data fed back from the camera 193. For example, when taking a picture, the shutter is opened, and light is transmitted through the lens to the camera's photosensitive element. The light signal is converted into an electrical signal, and the camera's photosensitive element transmits the electrical signal to the ISP for processing, transforming it into an image visible to the naked eye. The ISP can also perform algorithmic optimization of image noise, brightness, and skin tone. The ISP can also optimize parameters such as exposure and color temperature of the shooting scene. In some embodiments, the ISP can be set in the camera 193.

[0089] Camera 193 is used to capture still images or videos. An object is projected onto a photosensitive element by generating an optical image through the lens. 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 transmitted 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 RGB, YUV, or other formats. In some embodiments, electronic device 100 may include one or N cameras 193, where N is a positive integer greater than 1. Camera 193 may include, but is not limited to, conventional color cameras (RGB cameras), depth cameras (RGB depth cameras), dynamic vision sensor (DVS) cameras, etc. In some embodiments, camera 193 can be a depth camera. A depth camera can acquire spatial information of the real environment.

[0090] Internal memory 121 can be used to store computer executable program code, which includes instructions. Processor 110 executes various functional applications and data processing of the electronic device by running the instructions stored in internal memory 121. Internal memory 121 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 (such as audio data, phonebook, etc.). Internal memory 121 may include one or more random access memory (RAM) and one or more non-volatile memory (NVM).

[0091] The external memory interface 120 can be used to connect to external non-volatile memory, thereby expanding the storage capacity of the electronic device. The external non-volatile memory communicates with the processor 110 through the external memory interface 120 to perform data storage functions. For example, music, video, and other files can be stored in the external non-volatile memory.

[0092] Electronic device 100 can implement audio functions, such as music playback and recording, through audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, and application processor.

[0093] Audio module 170 is used to convert digital audio information into analog audio signal output, and also to convert analog audio input into digital audio signal. Audio module 170 can also be used for encoding and decoding audio signals.

[0094] The speaker 170A, also known as a "loudspeaker," is used to convert audio electrical signals into sound signals. Electronic devices can listen to music or make hands-free calls through the speaker 170A.

[0095] The receiver 170B, also known as the "earpiece," is used to convert audio electrical signals into sound signals. When an electronic device answers a phone call or voice message, the receiver 170B can be brought close to the ear to hear the voice.

[0096] Microphone 170C, also known as a "microphone" or "voice transducer," is used to convert sound signals into electrical signals. In some embodiments, the electronic device may have two microphones 170C, which, in addition to collecting sound signals, can also perform noise reduction. In other embodiments, the electronic device may also have three, four, or more microphones 170C, which can collect sound signals, reduce noise, identify the sound source, and perform directional recording, etc.

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

[0098] Electronic device 100 may include one or more buttons 190, which can control electronic device 100 and provide users with access to functions on electronic device 100. The buttons 190 may be mechanical keys such as buttons, switches, or dials, or touch or proximity sensing devices (such as touch sensors). Electronic device 100 can receive button input and generate key signal inputs related to user settings and function control of electronic device 100. Buttons 190 may include power buttons, volume buttons, etc.

[0099] Motor 191 can generate vibration alerts. Motor 191 can be used for incoming call vibration alerts or for touch vibration feedback. For example, different vibration feedback effects can correspond to touch operations applied to different applications (such as taking photos, playing audio, etc.). Motor 191 can also correspond to different vibration feedback effects for touch operations applied to different areas of the electronic device 100. The touch vibration feedback effect can also be customized.

[0100] Indicator 192 can be an indicator light, which can be used to indicate charging status, power changes, or to indicate messages, notifications, etc.

[0101] Electronic device 100 may also include other input / output interfaces, through which other devices can be connected to electronic device 100. Components may include, for example, audio / video jacks, data connectors, etc.

[0102] The electronic device 100 is equipped with one or more sensors, including but not limited to a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0103] Pressure sensor 180A senses pressure signals and converts them into electrical signals. Gyroscope sensor 180B determines the motion posture of electronic device 100. Barometric pressure sensor 180C measures air pressure. Magnetic sensor 180D includes a Hall effect sensor. Accelerometer 180E detects the magnitude of acceleration of electronic device 100 in various directions (typically three axes). When electronic device 100 is stationary, it can detect the magnitude and direction of gravity. It can also be used to identify the posture of electronic device, applied to screen orientation switching, pedometers, etc. Distance sensor 180F measures distance. Proximity sensor 180G may include, for example, a light-emitting diode (LED) and a photodetector, such as a photodiode. Electronic device 100 uses a photodiode to detect infrared reflected light from nearby objects. When sufficient reflected light is detected, an object can be determined to be near electronic device 100. Ambient light sensor 180L senses ambient light intensity. Fingerprint sensor 180H collects fingerprints. Temperature sensor 180J detects temperature. Bone conduction sensor 180M acquires vibration signals.

[0104] Touch sensor 180K, also known as a "touch device," can be located on display screen 194. The touch sensor 180K and display screen 194 together form a touchscreen, also known as a "touchscreen." Touch sensor 180K detects 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 194. In other embodiments, touch sensor 180K may also be located on the surface of electronic device 100, in a different position than display screen 194.

[0105] The SIM card interface 195 is used to connect a SIM card. The SIM card can be inserted into or removed from the SIM card interface 195 to make contact with and separate from the electronic device 100. The electronic device 100 can support one or N SIM card interfaces, where N is a positive integer greater than 1. The SIM card interface 195 can support Nano SIM cards, Micro SIM cards, SIM cards, etc. Multiple cards can be inserted into the same SIM card interface 195 simultaneously. The multiple cards can be of the same or different types. The SIM card interface 195 is also compatible with different types of SIM cards. The SIM card interface 195 is also compatible with external memory cards. The electronic device 100 interacts with the network through the SIM card to realize functions such as calls and data communication. In some embodiments, the electronic device 100 uses an eSIM, i.e., an embedded SIM card. The eSIM card can be embedded in the electronic device 100 and cannot be separated from the electronic device 100.

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

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

[0108] 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, a mobile operating system can be divided into four layers, from top to bottom: the application layer, the application framework / core service layer, the underlying libraries and runtime, and the kernel layer.

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

[0110] like Figure 2B As shown, the application package can include applications such as camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, and settings. Among these, the application service can obtain the device status of the other device and display it on the UI, allowing users to easily understand the connection status of the other device.

[0111] The program framework layer provides an application programming interface (API) and programming framework for applications in the application layer. The program framework layer includes some predefined functions.

[0112] like Figure 2BAs shown, the program framework layer may include a window manager, content provider, view system, session manager, resource manager, notification manager, device status manager, etc.

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

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

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

[0116] The session manager is used to manage session state and session lifecycle, such as creating a session, maintaining a session, closing a session, and removing a session.

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

[0118] 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 download completion 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.

[0119] A device status manager is used to record and change the status of peer devices. In some embodiments, the peer device status includes online, silent, and offline states. When a peer device is online, if the triggering conditions for the silent state are met, such as the time difference between the last time a peer device message was sent and received and the current time exceeds the period set by a timer, the device status manager can change the peer device's status from online to silent. When a peer device is silent, if a message is successfully sent or received, the device status manager can change the peer device's status from silent to online. When a peer device is silent, if a message is sent or received fails, the device status manager can change the peer device's status from silent to offline. When a peer device is online, if a message is sent or received fails, the device status manager can change the peer device's status from online to offline. When a peer device is offline, if a message is successfully sent or received, the device status manager can change the peer device's status from offline to online. For a more detailed explanation, please refer to the embodiments described later.

[0120] The runtime environment, including core libraries and the virtual machine, is responsible for system scheduling and management. It can refer to all the code libraries, frameworks, etc., required for a program to run. For example, for the C language, the runtime includes a series of function libraries required for C programs to run. For the Java language, in addition to the core libraries, the runtime also includes the virtual machine required for Java programs to run. The aforementioned core libraries can include the functionalities that the Java language needs to call. The application layer and program framework layer run in the virtual machine. The virtual machine executes the Java files of the application layer and program 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.

[0121] The underlying library 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.

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

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

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

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

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

[0127] This section uses the scenario of starting a photo-taking activity as an example to illustrate the workflow of the software and hardware working together in electronic device 100.

[0128] When touch sensor 180K receives a touch operation, a corresponding hardware interrupt is sent to the kernel layer. The kernel layer processes the touch operation into a raw input event (including touch coordinates, timestamp of the touch operation, etc.). The raw input event is stored in the kernel layer. The application framework layer retrieves the raw input event from the kernel layer and identifies the control corresponding to the input event. Taking a touch click as an example, where the corresponding control is the camera application icon, the camera application calls the application framework layer's interface to launch the camera application, and then calls the kernel layer to launch the camera driver, capturing still images or videos through camera 193.

[0129] The above description of the software architecture of the electronic device 100 is merely an example. It is understood that the software architecture illustrated in the embodiments of the present invention does not constitute a specific limitation on this application. In other embodiments of this application, the software architecture of the electronic device 100 may include more or fewer modules than illustrated, or combine some modules, or split some modules, or have different architectural arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0130] The technical solution provided in this application is described below with reference to the accompanying drawings.

[0131] The technical solutions provided in this application can be applied to any two or more devices in the communication system 10. For ease of understanding, the following explanation uses the interaction between two devices as an example. The interaction between any two devices among multiple devices can be explained with reference to this example.

[0132] For ease of distinction and understanding, the two interacting devices will be referred to as the local device and the peer device, respectively. The local device can mark the status of the peer device. This application embodiment does not impose any restrictions on the device type of the local device or the peer device. For example, in some examples, the local device can be a mobile phone, a tablet computer, or a PC, etc., and the peer device can be a mobile phone, a tablet computer, a PC, a smartwatch, a smart bracelet, or headphones, etc.

[0133] In the embodiments provided in this application, the states marked by the local device for the peer device include: online state, offline state, silent state, etc.

[0134] "Online status" refers to the state where the local device discovers the peer device, establishes a connection, and can communicate normally; it is also known as "online state." When the local device confirms that the peer device is online, it can know that it can communicate smoothly with the peer device and successfully send or receive messages.

[0135] "Offline status" refers to a state where the local device cannot detect the peer device, the connection between them is broken or abnormal, and the local device and the peer device cannot communicate. It is also known as "offline state". When the local device confirms that the peer device is in an offline state, the local device can know that it cannot communicate with the peer device, and there is an obstacle to sending or receiving messages between them.

[0136] "Silent state" (or "silent state") is an intermediate state between online and offline, indicating an uncertainty about whether the peer device is currently communicable. It can also be called "residual state" or "silent state." When a peer device is in a silent state, there is no communication between the two devices for a certain period of time, requiring further detection to confirm whether the peer device is online or offline. The reasons for the lack of communication between the two devices could include a temporary lack of business interaction, the peer device leaving the network coverage area of ​​the local device, or the peer device temporarily disabling its wireless connection by entering sleep mode to save power.

[0137] In some embodiments, a timer can be set for passive detection. When the passive detection exceeds a set time threshold, it will trigger a change in the peer device's status from online to silent. When the peer device is in silent mode, the local device initiates active detection, which means sending a probe message to the peer device. If the probe message is successfully sent, both parties can communicate normally, triggering a change in the peer device's status from silent to online. If the probe message fails to send, both parties cannot communicate normally, triggering a change in the peer device's status from silent to offline.

[0138] It is understood that the terms "online status", "offline status", and "silent status" in this application are merely illustrative and do not constitute a limitation on other embodiments. In other embodiments, other terms may be used instead of these terms, and the specific meaning of the terms should be taken into account.

[0139] In a system consisting of a local device and a remote device, a status manager can be provided. The status manager can use coded tags to indicate the status of the remote device, such as using 0 to represent the online status, 1 to represent the offline status, and 2 to represent the silent status. This embodiment does not impose any restrictions.

[0140] After the local device discovers the peer device and successfully establishes a connection, the local device can display that the peer device is online. The various embodiments do not limit the specific type of communication connection established between the local and peer devices. For example, it can be a Wi-Fi P2P connection, Bluetooth connection, USB connection, etc., or a network connection, or a communication connection established through an access point (AP). For instance, after the local and peer devices connect to a router and join the same Wi-Fi network, the local and peer devices can establish a communication connection through that Wi-Fi network.

[0141] Before establishing a connection between the local and remote devices, the local device needs to authenticate the remote device upon discovery. Authentication involves verifying the identity of the claimant based on specific information held by the claimant. Common authentication methods include username / password, biometrics (fingerprint, face, iris, voice, etc.), SMS verification code, QR code, and gesture password. After successful authentication, a communication connection can be established between the local and remote devices. The local device will then transition the remote device's status to online, and the two devices can exchange messages and communicate normally. This process can also be referred to as "login."

[0142] After the initial connection is established, the authentication information can be saved on the peer device, or the local device can mark the peer device as a trusted device. This way, the next time the peer device establishes a connection with the local device, it can automatically establish a connection with the local device without requiring the user to input authentication information.

[0143] refer to Figure 3 , Figure 3 This is a state transition diagram, illustrating the transitions between various states of the peer device, including online, offline, and silent states. Figure 3 The conditions for state transitions are also marked and explained.

[0144] ① Online status → Offline status

[0145] When the peer device is online, if the local device fails to send a service message to the peer device, the peer device's status will be transitioned from online to offline.

[0146] ② Offline state → Online state

[0147] When the peer device is offline, when the local device establishes a connection with the peer device and can successfully send or receive service messages from the peer device, the status of the peer device will be transitioned from offline to online.

[0148] ③Online status → Silent status

[0149] The local device internally sets up device status bits and a timer (or counter). The device status bits are used to mark the device status, including reset, set, and other status bits. The timer is used for timing. When the peer device is in the online state, the local device synchronously starts its timer (or counter) at the exact moment it last receives a heartbeat message from the peer device. If a heartbeat message from the peer device is received within a certain time threshold set by the timer, the online state can be maintained. If no heartbeat message is received from the peer device within a certain time threshold set by the timer (e.g., the first time limit), that is, if the time difference between the last sent / received message and the current time exceeds the timer's set period, the peer device's status can be changed from online to silent.

[0150] ④ Silent state → Online state

[0151] When the peer device is in a silent state, the local device's application can trigger a silent probe by calling the silent probe interface, either actively or passively, such as by actively sending a broadcast probe message. If the probe is successful, such as receiving a response from the peer device, the peer device's state will be changed from silent to online.

[0152] Compared to unicast, the advantage of sending broadcast probe messages is that broadcast sends more messages per unit time, messages are less likely to be lost, and the success rate of transmission is higher.

[0153] Regarding the silent detection triggered by the local device, it can be actively triggered by the user. For example, when the user opens the application, or when the application is running in the foreground, or when the user clicks a specific control to trigger the detection, the application will call the silent detection interface, send a broadcast detection message, and detect whether the other device is online. If a response is received from the other device, the status of the other device can be changed from silent to online.

[0154] When the peer device is in a silent state, when the local device passively receives a new message / message from the peer device, it will also change the peer device's state from silent to online.

[0155] ⑤ Silent state → Offline state

[0156] When the peer device is in a silent state, the local device's application can trigger a silent probe by calling the silent probe interface, either actively or passively, such as by actively sending a broadcast probe message. If the probe fails, and no response is received from the peer device, the peer device's state will be changed from silent to offline.

[0157] Combination Figure 3 ,refer to Figure 4 , Figure 4 It is also a state transition diagram between the states of the peer device, especially showing in more detail a specific mechanism for changing from an online state to a silent state.

[0158] Examples of this state transition mechanism include:

[0159] (1) Equipment goes online

[0160] After the local device discovers the peer device, successfully authenticates it, and establishes a connection, the local device can display the peer device as online. The various embodiments do not impose any restrictions on the specific type of communication connection established between the local and peer devices, such as Wi-Fi P2P connection, Bluetooth connection, USB connection, network communication connection, etc.

[0161] (2) Online status → Offline status

[0162] When the peer device is online, if the local device fails to send a service message to the peer device, the peer device's status will be transitioned from online to offline. Simultaneously with the device going offline, (o) the timer will be terminated.

[0163] (3) Offline state → Online state

[0164] When the peer device is offline, when the local device successfully re-establishes a connection with the peer device, it can successfully send service messages to the peer device or receive service messages from the peer device, and will then transition the peer device's status from offline to online.

[0165] (4) Go online → go silent

[0166] The local device internally sets device status bits and timers (or counters). The device status bits are used to mark the device status, including reset, set, and other status bits. The timers are used for timing. In one example, reset is represented by 0 and set is represented by 1.

[0167] When the peer device changes its status to online, the local device (a) initializes its device status bit and (c) synchronously starts a timer (or counter). This embodiment does not impose any restrictions on the timer setting.

[0168] When the timer does not overflow and interrupt, whenever the local device successfully sends a message to the peer device or successfully receives a message from the peer device, it will trigger the local device to (b) reset the device status bit and simultaneously (c) restart the timer.

[0169] When the timer times out for the first time, i.e., timer overflow interrupt (d), the local device (e) reads the device status bit. If the current device status bit is reset, i.e., device status bit is not set (f), then (g) the device status bit is changed to set, and (h) the timer overflow interrupt ends, and the timer restarts, i.e., the timer is restarted (c).

[0170] When the timer expires for the second time, i.e., when the timer overflows again (d), the local device (e) reads the device status bit. If it reads that (i) the current device status bit is set, the trigger condition for the silent state is met. Then, it (j) changes the identifier status of the peer device, that is, changes the status of the peer device from the online state to the silent state, and (k) terminates the timer. That is, when the timer in the reset state expires twice consecutively, the status of the peer device is changed from the online state to the silent state, and the timer is terminated.

[0171] The duration of the first time and the second time can be the same or different, and this application embodiment does not limit this.

[0172] (5) Silence → Go Online

[0173] When the peer device is in a silent state, the local device's application can call the silent probe interface to actively or passively trigger a silent probe, such as by actively broadcasting a probe message. If the probe is successful, such as receiving a response from the peer device, the peer device's state will be changed from silent to online.

[0174] Compared to unicast, the advantage of sending broadcast probe messages is that broadcast sends more messages per unit time, messages are less likely to be lost, and the success rate of transmission is higher.

[0175] Regarding the silent detection triggered by the local device, it can be actively triggered by the user. For example, when the user opens the application, or when the application is running in the foreground, or when the user clicks a specific control to trigger the detection, the application will call the silent detection interface, send a broadcast detection message, and detect whether the other device is online. If a response is received from the other device, the status of the other device can be changed from silent to online.

[0176] When the peer device is in a silent state, when the local device passively receives a new message / packet from the peer device, it will also change the peer device's state from silent to online.

[0177] (6) Silence → Log Off

[0178] When the peer device is in a silent state, if the local device's application calls the silent probe interface, it triggers a silent probe, such as by actively sending a broadcast probe message. If the probe fails, such as not receiving a response from the peer device, the peer device's state is changed from silent to offline, and the timer is terminated.

[0179] In some embodiments, an application is installed on the local device that can display the status of the remote device, allowing the user to perceive the status of the remote device through the user interface.

[0180] refer to Figure 5 The user interface 500 shown can display the identifier and name of the peer device connected to the local device in the file application, such as the device status bar 501 in the user interface 500. The device status bar 501 can display the identifier of the device that has established a connection with the local device, such as the MateBook device icon 502, the MatePad device icon, and the Huawei P50 device icon 503. The device icons for online, silent, and offline states are different, making it easy for users to quickly distinguish the device status. For example, in this embodiment, the MateBook device icon 502 in the device status bar 501 is highlighted, indicating that the MateBook device is in an online state. In contrast to the highlighted display, the Huawei P50 device icon 503 is grayed out, indicating that the Huawei P50 device is in a silent state. Devices in an offline state are not displayed in the device status bar 501. This example does not constitute a limitation on other possible embodiments. In other embodiments, online, silent, and offline states can also be displayed in different colors, as long as it is easy for users to distinguish them.

[0181] In one implementation, such as Figure 6A As shown, to check if a device is still connected in silent mode, the user can click the Huawei P50 device icon 503 under the silent indicator in the user interface 500. This triggers a silent probe, where the local device actively sends a probe message to the remote device. If a probe response is received from the remote device, the Huawei P50 device changes from silent mode to online mode, i.e., Figure 6A As shown in the user interface 510, the Huawei P50 device icon 503 changes from grayed out to highlighted. If no probe response is received from the peer device within the specified time, the Huawei P50 device changes from a silent state to an offline state, i.e. Figure 6BAs shown in the user interface 520, the Huawei P50 device icon 503 disappears and is not displayed in the device status bar 501. This example does not limit other possible implementations. In another embodiment, the silent probe can be initiated automatically by the application when the user opens the application or brings it to the foreground. If the device is still connected, it changes to an online state; if it is disconnected, it changes to an offline state. The electronic device may not need to display a silent state marker. The confirmation of the silent state device's state transition will be completed in a very short time, and only the online and / or offline devices will be presented to the user.

[0182] It is understood that the user interfaces described in the embodiments of this application are merely example interfaces, used to assist readers in understanding the technical solutions described in this application, and do not constitute a limitation on other embodiments of this application. In other embodiments, the user interface may adopt different interface layouts, may include more or fewer controls, may add or remove other functional options, may add or remove more or fewer user interfaces according to actual conditions, or may design different human-computer interaction operations, etc., to make the user interface more in line with the user's experience. The example interfaces can also be adapted to other types of devices, as long as the technical solutions are based on the same inventive concept provided in this application, they are all within the protection scope of this application, and will not be elaborated here.

[0183] Combination Figure 3 , Figure 4 See below for reference. Figure 7 , Figure 8 , Figure 9 , Figure 10 This describes the specific state change process between the local device (Device A) and the remote device (Device B). Device A, also known as the discoverer device, includes services such as application services, proximity communication services, and state management services. Device B, also known as the discoverer device, also includes services such as application services, proximity communication services, and state management services.

[0184] This application does not impose any restrictions on the specific technical means used for device discovery and device connection. The communication connection between device A and device B can be a short-range or long-range communication connection, such as a USB connection, Bluetooth connection, Wi-Fi P2P connection, WLAN connection, radio frequency identification (REID) connection, ZigBee connection, etc., and this embodiment does not impose any restrictions. Alternatively, device A and device B can log in with the same account, or their login accounts belong to the same group (such as a family account), or they can be different accounts connected through a cloud server, and this embodiment does not impose any restrictions on these.

[0185] Figure 7 This diagram illustrates the information flow process between device A and device B, including discovery, connection, and authentication.

[0186] Equipment discovery phase:

[0187] S101, Device B Publishing Service.

[0188] Device B's application service notification publishes discoverable services through the Near Field Communication Service, making it easier for other nearby devices to discover it.

[0189] S102, Device A begins the search (start Discovery).

[0190] Device A's application service notification activates the proximity communication service to locate nearby devices.

[0191] S103, Near-field communication services between Device A and Device B are broadcast scanned.

[0192] It includes two modes: proactive discovery and reactive discovery.

[0193] Active discovery: The discovery-side device sends a search broadcast, and the discovered-side device replies to the broadcast.

[0194] Passive discovery: The discovered device actively sends a device information broadcast, and the discovered device listens to the broadcast.

[0195] In other words, the discovering device discovers nearby devices through broadcasting or listening, and prompts the caller to select a device to connect to. The discovered device then notifies nearby devices of its own device information through feedback listening or broadcasting, enabling its own device to be discovered and perceived by nearby devices.

[0196] S104, Device A discovers Device B (on Device Found).

[0197] After receiving the broadcast message from device A, device B reports its own device information, and device B is discovered by device A. The device discovery result includes basic device information and connectivity information. Lightweight devices generally only need to support the discovery function.

[0198] For example, for Bluetooth Low Energy (BLE), low-power device discovery can be achieved through BLE broadcasting and scanning, with device discovery supporting filtering via the `filter` function. BLE implements real-time background discovery based on the low-power discovery protocol stack. BLE supports two modes: active discovery and passive discovery. Active discovery: The discovering device sends a BLE search broadcast, and the discovered device replies to the broadcast. Passive discovery: The discovered device actively sends a device information broadcast, and the discovering device listens for the broadcast.

[0199] For example, Wi-Fi can only discover devices already on the local area network (LAN). In Wi-Fi's access point-to-stall (AP-STA) connection mode or wired network connection, the protocol layer uses Internet Protocol (IP) layer multicast or broadcast mechanisms for discovery and connection. Wi-Fi can also discover peer devices based on the Constrained Application Protocol (COAP). Specifically, the discovering device sends a broadcast containing discovery information within the LAN using the COAP protocol format. The discovered device, upon receiving the discovery broadcast, unicasts its own device information in response.

[0200] Unencrypted message exchange phase:

[0201] After device A discovers device B, a dedicated physical link channel will be established between device A and device B for communication, either before or after a service is triggered, based on different communication methods such as Wi-Fi, BLE, or USB, to facilitate communication. In resource-constrained communication systems, such as BLE, the channel cannot be exclusively used. Therefore, establishing a connection in BLE can be understood as both parties communicating on a designated physical channel within an agreed-upon time period.

[0202] S105, Device A opens the channel.

[0203] Device A's application service notifies the near-field communication service to open a channel.

[0204] S106, Authentication Message Service.

[0205] A channel is established between device A and device B based on a given connection.

[0206] S107, Device B opens channel (on Channelopened).

[0207] S108, Device A's application service notifies the near-field communication service to send a message (sendMessage).

[0208] S109, Application Service Notification for Device A: Near Field Communication Service Authentication Device (verify Device).

[0209] Connection authentication phase:

[0210] When devices A and B, which have established a trust relationship, communicate, they first complete the trust binding, and then authenticate each other based on the peer's public key stored locally. During each communication, two-way authentication and session key negotiation are performed, after which the devices use this session key to decrypt the transmission channel between them.

[0211] S110, Security Token Service (STS) certification.

[0212] Device A performs STS authentication on device B, negotiating a session key based on the identity keys of both parties. Upon successful authentication, device A returns device B's ID and derived key, and the previously established connection is converted into a secure connection.

[0213] S111, Device Verify Pass approved.

[0214] Device A's near-field communication service notifies the application service that device B has been authenticated.

[0215] S112, connect to a verified device.

[0216] Device A's application service notifies the near-field communication service to initiate a connection to the authenticated device B.

[0217] S113, Connection process.

[0218] Device A establishes a secure connection with Device B.

[0219] S114, Save connection.

[0220] S115, Near Field Communication Service Notifies Status Manager of Initial Device Status Bit, Status Manager Enables Timeout Counting.

[0221] When device B switches to the online state, the device status manager initializes the device status bits and starts a timer. The timer is used to measure whether device B has reached the time limit to switch to the silent state.

[0222] S116, Device A's near-field communication service informs the application service that it has connected to Device B (on Connected).

[0223] Figure 8This diagram illustrates the data transmission and status update process after a connection is established between device A and device B. The transmission service module provides session management and session-based data transmission / reception functions to the business module, and provides encryption and decryption protection for transmitted and received messages through encryption. Specifically, communication data is encrypted using a session key, enabling encrypted communication between device A and device B. This includes:

[0224] Session service creation phase:

[0225] S201, Device A and Device B respectively create Session Server.

[0226] Before establishing a session and executing transmissions, the application services of Device A and Device B respectively notify their respective proximity communication services to create a session server and register a listening callback function. This listening callback function is used to passively listen for messages exchanged between the devices at various stages of data transmission, including control messages and data messages, and reset the device status bits based on message send and receive events.

[0227] During the creation of the session server, device A and device B did not send or receive messages to each other, so the timer continued to count.

[0228] Session setup phase:

[0229] S202, Device A opens a session.

[0230] After device A and device B establish a session server, the receiving end, i.e. device B, waits for the sending end to create a session message. The sending end, i.e. device A, establishes a session based on the session service name and device ID. Device A's application service notifies the near-field communication service to open the session channel.

[0231] S203, Device A notifies Device B to create a transmission channel.

[0232] Once the proximity communication service of device A is obtained, a message is sent to the proximity communication service of device B. The state managers of device A and device B reset the device state bits, that is, the device state bits are reset every time a message is successfully sent or received.

[0233] S204, Device B, i.e. the receiving end, received the callback and opened the session channel (onSession opened).

[0234] After receiving a request from device A to open a session channel, device B's short-range communication service informs the application service, which then opens the session channel and returns the result.

[0235] S205, Device B returns the result that the session channel has been opened to Device A.

[0236] Once the proximity communication service of device B is obtained, a message is sent to the proximity communication service of device A. The state managers of device A and device B reset the device state bits, that is, the device state bits are reset every time a message is successfully sent or received.

[0237] S206, Device A, i.e. the sending end, received a callback indicating that the session channel has been opened (onSession opened).

[0238] S207, Return Session.

[0239] The application service of device A confirms that the session connection is valid. At this point, the transmission channel between device A and device B has been established and opened, and the session connection has been successfully established.

[0240] Data transmission phase:

[0241] After device A and device B successfully establish a session connection, they can send or receive instructions and data to each other through this session connection. The data sent or received can include, but is not limited to, the following three data types: Byte type, used for large-scale data exchange; Message type, used for instant messaging; and File type, used for file transfer.

[0242] S208, the application service of device A sends a session message to the near-field communication service.

[0243] S209, Device A's short-range communication service sends data to Device B's short-range communication service.

[0244] Once the proximity communication service of device A is successfully obtained, a message is sent to the proximity communication service of device B. The state managers of devices A and B reset the device state bits.

[0245] S210, the application service of device B receives the session message (on MessageReceived) received by the near-field communication service.

[0246] S211, Device B returns the result of receiving the message to Device A.

[0247] Upon receiving a message indicating that device B has successfully returned a result to device A, the state managers of both device A and device B reset the device state bits.

[0248] Close session phase:

[0249] Close the transmission channel between devices and release related resources.

[0250] S212, Device A's application service notifies the near-field communication service to close the session.

[0251] S213, the short-range communication service of device A sends a message to the short-range communication service of device B to close the session.

[0252] Once the proximity communication service of device A is successfully obtained, a message is sent to the proximity communication service of device B. The state managers of devices A and B reset the device state bits.

[0253] S214, the application service of device B receives the message "onSession Closed" from the near-field communication service, and the application service of device B closes the session.

[0254] Removal of session service phase:

[0255] S215, Device A and Device B respectively remove the Session Server.

[0256] After the application services of device A and device B close their sessions, the application services of device A and device B respectively notify their proximity communication services to delete the session server and cancel the previously registered listener callback functions.

[0257] During the process of deleting the session server, device A and device B did not exchange or send messages to each other, so the timer continued to count.

[0258] Figure 9 This diagram illustrates the information flow process of device A suddenly going online and then offline, and then going offline and back online, when device A and device B are normally connected. For example, in the online state, if device A fails to send a control message or service message to device B, it will trigger a change from online to offline. In the offline state, if device A successfully receives a control message or service message from device B, it will trigger a change from offline to online. Based on a state manager (or device state transition state machine), when a device state (including "discovery," "online," "offline," "silent," etc.) changes, the application-registered listener callback function is called in real time to notify the application of the change in the peer device's state.

[0259] Sudden offline phase:

[0260] S301, the application service of device A sends a message to the short-range communication service.

[0261] Device A sends a message to Device B. Device A's application service receives the message and passes it to the short-range communication service. Device A's short-range communication service then forwards the message to Device B's short-range communication service.

[0262] S302, the short-range communication service of device A sends a message to the short-range communication service of device B.

[0263] S303, Device A's near-field communication service learns that message sending has failed, stops timeout counting, and the status manager changes Device B from online to offline.

[0264] When the peer device, i.e. device B, is online, and after retrying several times based on a defined retransmission strategy, it still fails to successfully send messages (including control messages and data messages), confirms the message sending failure event, and triggers device B to go offline.

[0265] S304, Device A's near-field communication service notifies the application service that Device B's status has changed from online to offline.

[0266] S305, Device A's application service refreshes the application interface, blocking offline devices, i.e., not displaying Device B's identifier.

[0267] In some embodiments, the identifier of the offline device may not be displayed in the application interface.

[0268] Offline recovery phase:

[0269] S306, Device A's short-range communication service receives a message sent by the short-range communication service of the offline device, namely Device B.

[0270] When the peer device, i.e. device B, is offline, the local device, i.e. device A, receives messages (including control messages and data messages) from the peer device, triggering device B to come back online.

[0271] S307, Device A's short-range communication service sends a probe message to Device B's short-range communication service.

[0272] To confirm that the connection between device A and device B is valid, device A sends a probe message to device B.

[0273] S308, Device A's short-range communication service learns that the probe message was successfully sent, meaning that Device B successfully received the probe message. The status manager changes Device B from offline to online and resets the device status bit.

[0274] S309, Device A's near-field communication service notifies the application service that Device B's status has changed from offline to online.

[0275] S310, the application service of device A refreshes the application interface and displays the online device, that is, the identifier of device B.

[0276] In some embodiments, the icon of the online device can be displayed in the application interface with a highlighted mark, making it easy for users to quickly identify the peer device that is connected to the local device and can communicate normally.

[0277] When device B switches to the online state, the device status manager resets the device status bit, and the timer starts working to restart the timeout count.

[0278] Figure 10 This diagram illustrates the information flow when device A changes the state of device B from online to silent, and when, in the silent state, a probe is actively triggered to check if the peer device is online. Based on a state manager (or device state transition machine), when a device state changes, the application-registered listener callback function is called in real time to notify the application of the change in the peer device's state.

[0279] In some embodiments, when device A sets device B to a silent state, the session between device A and device B can be closed, but the session service is not removed. The session service is then removed when the silent state changes to an offline state. The session state is then restored to "normal service state" when the silent state returns to an online state.

[0280] Alternatively, in some embodiments, when device A sets device B to a silent state, the session between device A and device B is not closed; instead, the session state can be transitioned from "normal service state" to "session hold state." When the silent state returns to the online state, the session state is then restored to "normal service state." When the silent state changes to the offline state, the session service is then closed and removed.

[0281] Change notification (launch → silent phase):

[0282] S401, the state manager continuously counts, and when a timeout is detected, the state manager of device A notifies the near-field communication service of the state change, and device B changes from the online state to the silent state.

[0283] If no heartbeat message is received from the peer device within a certain time threshold set by the timer, that is, if the time difference between the last sent and received message and the current time exceeds the time limit set by the timer, the status of the peer device can be changed from online to silent.

[0284] Referring to the foregoing embodiments, it can be set to trigger the change of device B from online state to silent state when the timer overflows and interrupts twice or more consecutively.

[0285] S402, Device A's near-field communication service notifies the application service that Device B's status has changed from online to silent.

[0286] S403, Device A's application service refreshes the application interface, graying out and silencing the device.

[0287] Setting a device to gray and making it silent means that device A displays the identifier of device B as a gray identifier, which is different from the highlighted identifier of the online device. The different identifier helps users distinguish between the online device and the silent device.

[0288] User-triggered probe phase:

[0289] S404, Device A detected a user action on a silent device.

[0290] This application does not limit the user operation that triggers active detection. In some embodiments, the user can trigger the application to send an active detection message by clicking the grayed-out silent device icon. In other embodiments, the user can trigger the application to send an active detection message by running the application in the foreground.

[0291] S405 triggers silent device detection.

[0292] User actions trigger the application service of device A to send an active probe message to the silent device. The application service of device A then forwards the probe message to the proximity communication service. In other words, after device A detects a user action on the application targeting the silent device, based on the device presentation strategy, the application calls the silent probe interface provided by the system as needed to initiate a silent probe and quickly detect the real-time status of the silent device.

[0293] S406, Device A's short-range communication service sends a probe message to Device B's short-range communication service.

[0294] To confirm a valid connection between device A and device B, device A sends a probe message to device B. In one implementation, the probe message can be sent as a broadcast probe message. Compared to unicast, the advantage of broadcasting probe messages is that broadcasting sends more messages per unit time, reducing the likelihood of message loss and resulting in a higher success rate.

[0295] The detection event response includes two scenarios: detection message sending failure and sending success. Based on the detection result, different state changes are executed, switching from a silent state to an online state or from a silent state to an offline state, and the application interface is refreshed simultaneously.

[0296] Steps S407-S409 are for detecting cases where message sending fails.

[0297] S407, Device A's short-range communication service learns that the probe message transmission failed, stops the timeout count, and the state manager changes Device B from silent state to offline state.

[0298] When the peer device, i.e., device B, is in a silent state, and the probe message fails to be sent, device B is triggered to go offline.

[0299] S408, Device A's near-field communication service notifies the application service that Device B's status has changed from silent to offline.

[0300] S409, Device A's application service refreshes the application interface, blocking offline devices, i.e., not displaying Device B's identifier.

[0301] When the application service on device A detects that device B has gone offline, it will refresh the application interface accordingly.

[0302] Steps S410-S412 are for cases where the probe message was successfully sent.

[0303] S410, the short-range communication service between device A and device B learns that the probe message was successfully sent, the status manager changes device B from silent state to online state, and resets the device status bit.

[0304] When the peer device (device B) is in a silent state, it is triggered to come online when the probe message is successfully sent.

[0305] S411, the near-field communication service notification application service between device A and device B changes the status of device B from silent state to online state.

[0306] S412, the application services of devices A and B refresh the application interface and highlight the online devices.

[0307] In one approach, device B is changed from a gray indicator representing a silent state to a highlighted indicator representing an online state.

[0308] When device B switches to the online state, the timer starts working, restarts the timeout count, and at the same time the device status manager resets the device status bit.

[0309] When device B is online, device A and device B can communicate normally, the session remains in a normal service state, and a timer is running. If no messages are sent or received between device A and device B after the first time threshold T1, and the current device status bit is read as reset, the device status bit will be changed from reset to set, and the timer will restart. If no messages are sent or received between device A and device B after the second time threshold T2, and the current device status bit is read as set, the status of device B will be changed from online to silent. It can be understood that if device A and device B successfully send or receive messages at any time within T1 or T2, it will trigger device B to reset its online state and reset its device status bit.

[0310] It is understandable that a silent state and an offline state are different. In some embodiments, when device B is in a silent state, device B is not offline, and the session between device A and device B can remain in a session-persistent state. When it is determined that device B has changed from a silent state to an online state, the session can be transitioned from a session-persistent state to a normal service state. When it is determined that device B has changed from a silent state to an offline state, the session state can be transitioned from a session-persistent state to a session-exited state.

[0311] It is understandable that when device B goes offline, it is usually due to network failure, disconnection, or power-off of the mobile terminal. Therefore, when device B logs back in, a new session creation and configuration process needs to be started. The session is in the initial state. In this state, the amount of data exchanged during the login request is large, requiring a lot of resource analysis and querying.

[0312] Based on the foregoing embodiments, the following describes a detection method provided by an embodiment of this application. Figure 11 A flowchart of the detection method provided in the embodiments of this application.

[0313] This method provides a detection method for a first device to detect the status of a second device, solving problems such as untimely device status updates, high power consumption, and cumbersome communication. This method eliminates the commonly used heartbeat mechanism in communication, completely resolving issues of high power consumption and bandwidth occupation, and further optimizing communication efficiency. By monitoring the sending and receiving events and results of passive or active detection of service messages between devices, the method drives the online state machine migration of the devices, allowing for rapid detection of device status changes. The method adds an active detection mechanism and establishes a new device state—the silent state—as well as a silent detection interface, supporting applications in determining the UI presentation and business processing strategies for various device states. When the second device is online, if passive detection times out, the online state changes to the silent state. In the silent state, the first device can actively broadcast detection messages as needed to confirm whether the peer device is online, solving problems such as easy device status errors and poor user experience, effectively reducing device offline latency and power consumption, avoiding the defects of frequent online and offline due to brief disconnections, and further improving communication efficiency.

[0314] The method provided in this embodiment can be applied to a communication system consisting of a first device and a second device. The first device and / or the second device can be terminal devices configured with communication devices, capable of receiving or sending data, signaling, and other messages. The first device is the local device or device A in the aforementioned embodiments, and the second device is the peer device or device B in the aforementioned embodiments. The local device can identify the current device status of the peer device and display it in the UI interface, making it convenient for users to quickly distinguish the connection status of each device.

[0315] The type of the first or second device can be, but is not limited to, mobile phones, laptops, tablets, smart bracelets, smartwatches, PCs, smart TVs (also known as smart screens, large screens, etc.), smart speakers, etc. It can also be desktop computers, laptops, handheld computers, AR devices, VR devices, AI devices, in-vehicle systems, game consoles, treadmills, cloud hosts / servers, other smart wearable devices, or IoT devices, or smart home devices such as smart water heaters, smart lights, smart air conditioners, smart scales, and other types of electronic devices. This application does not impose any restrictions on the type of the first or second device. The hardware structure of the first or second device can be referred to the description of electronic device 100 in the foregoing embodiments.

[0316] Figure 11 This is a flowchart of the detection method provided in this embodiment. The flowchart illustrates the process of the second device changing from an online state to a silent state, from a silent state to an online state, from a silent state to an offline state, and from an offline state to an online state. The specific steps are as follows:

[0317] S501, the first device discovers the second device and establishes a connection. The first device and the second device communicate normally, and the second device is in the online state.

[0318] After the first device discovers the second device, successfully authenticates it, and establishes a connection, the first device can display the second device as online. This embodiment does not limit the specific type of communication connection established between the first and second devices. It can be a wired or wireless connection, such as a Wi-Fi P2P connection, Bluetooth connection, USB connection, or other network communication connections. This communication connection can be used to transmit data, signaling, etc.

[0319] The status of the second device recorded by the first device includes online status, offline status, and silent status. Online status indicates that the communication between the first device and the second device is normal. Offline status indicates that the communication between the first device and the second device is abnormal. Silent status indicates that the communication between the first device and the second device is uncertain and needs to be confirmed by re-probing to see if the second device is online or offline.

[0320] S502, the first device resets the device status bit and starts the timer.

[0321] The first device internally sets device status bits and a timer (or counter). The device status bits are used to indicate the number of interrupts of the timer and can include status bits such as reset and set. The timer is used for timing. In one example, reset is represented by 0 and set is represented by 1.

[0322] When the second device changes its status to online, the first device initializes its device status bit and synchronously starts a timer (or counter). This embodiment does not impose any restrictions on the timer setting.

[0323] S503, the first device determines whether it has received a message from the second device.

[0324] If so, that is, a message (or packet) is received from the second device, then step S502 is executed, which resets the device status bit and restarts the timer to start counting again. That is, when the timer has not overflowed and interrupted, whenever the first device successfully sends a packet to the second device or successfully receives a packet from the second device, it will trigger the first device to reset the device status bit and restart the timer at the same time.

[0325] If no message (or message) is received from the second device, then proceed to step S504.

[0326] S504, timer overflow interrupt.

[0327] The first device detects that the timer has timed out and immediately triggers a timer overflow interrupt.

[0328] S505: The first device sets the device status bit and restarts the timer.

[0329] When a timer overflow interrupt is detected, the first device reads the device status bit. If the current device status bit is read as reset, the device status bit is set, and the timer is restarted.

[0330] S506, the first device determines whether it has received a message from the second device.

[0331] If so, that is, if a message (or packet) is received from the second device, then step S502 is executed, which resets the device status bit and restarts the timer to start counting again. That is, when the device status bit is set, before the second timer overflows and interrupts, whenever the first device successfully sends a packet to the second device or successfully receives a packet from the second device, it will trigger the first device to reset the device status bit and restart the timer at the same time.

[0332] If no message (or message) is received from the second device, then proceed to step S507.

[0333] S507, the timer overflows again and interrupts. The first device changes the status of the second device from online to silent and terminates the timer.

[0334] The first device detects that the timer has timed out for the second time, and the timer overflows again, triggering an interrupt. The first device reads the device status bit; if the current device status bit is set, the trigger condition for the silent state is met. The first device then changes the identifier status of the second device from online to silent, and simultaneously terminates the timer. That is, in one implementation, if the timer in the reset state times out twice consecutively, the status of the peer device is changed from online to silent, and the timer is terminated. The durations of the first and second times can be the same or different; this embodiment does not impose such limitations.

[0335] S508, the first device sends a probe message to the second device.

[0336] This probe message is also known as the first probe message.

[0337] In some embodiments, when the application of the first device is in a silent state, it calls the silent detection interface to send a detection message to the second device. This is an active detection triggered by user operation, such as when the user opens the application, or when the application is brought to the foreground, or when the user clicks a specific control to trigger the detection. The application will then call the silent detection interface to send a broadcast detection message to detect whether the other device is online. If a response is received from the other device, the state of the other device can be changed from silent state to online state.

[0338] In other embodiments, in a silent state, the first device first receives a message from the second device, and then the first device sends a probe message to the second device to verify whether normal communication is possible.

[0339] In some embodiments, sending a probe message can refer to the first device broadcasting a probe message. Compared to unicast, the advantage of broadcasting a probe message is that broadcasting sends more messages per unit time, messages are less likely to be lost, and the transmission success rate is higher.

[0340] S509, the first device determines whether the detection was successful.

[0341] If so, that is, the first device receives a probe response from the second device, then step S510 is executed.

[0342] If not, i.e. the first device does not receive a detection response from the second device, then proceed to step S511.

[0343] S510, the first device changes the status of the second device from silent state to online state, and executes step S502.

[0344] If the detection is successful, the status of the second device will be changed from silent to online. At the same time, the device status bit will be reset, and the timer will be restarted to begin counting down again.

[0345] S511, the first device changes the status of the second device from silent to offline and terminates the timer.

[0346] If the detection fails, the status of the second device will be changed from silent to offline, and the timer will be terminated.

[0347] S512, the first device and the second device resumed normal communication.

[0348] S513, the first device changes the status of the second device from offline to online, and executes step S502.

[0349] When the first device and the second device are successfully reconnected and can send messages to each other, the first device will change the status of the second device from offline to online, reset the device status bit, and restart the timer to start counting again when the second device is offline.

[0350] Furthermore, when the second device is online, if the first device fails to send a service message to the second device, the second device's status will be directly transitioned from online to offline. The timer will terminate simultaneously with the device going offline.

[0351] Implementing the method provided in this embodiment can solve problems such as high power consumption, bandwidth consumption, and frequent online / offline cycles caused by the heartbeat message keep-alive mechanism between devices in the system. By introducing a new device state, namely the silent state, the application can determine the UI presentation and business processing strategies of various states, solving the problem of device states not being updated in a timely manner, further optimizing communication efficiency, enhancing human-computer interaction performance, and providing users with a more intuitive, easier-to-understand, and more convenient application interaction interface. By listening to the sending and receiving events and results of business messages between devices, the online state machine of the device is driven to migrate, allowing users to perceive changes in device states in real time, thus improving the user experience.

[0352] In conjunction with the foregoing embodiments, the functional modules of an electronic device provided in this application are described below. As used below, the term "module" can refer to a combination of software and / or hardware that implements a predetermined function.

[0353] refer to Figure 12 , Figure 12 A structural block diagram of the functional modules of an electronic device 100 is shown. The electronic device 100 may include a communication module 1201, a timing module 1202, a judgment module 1203, a status management module 1204, a session management module 1205, a detection module 1206, a display module 1207, etc. Alternatively, these functional modules may be distributed within a communication system consisting of the electronic device 100 and a peer device.

[0354] The communication module 1201 is used to receive or send messages, including data messages and control messages. The communication module 1201 may further include a sending module 1208 and a receiving module 1209. The sending module 1208 is used to send messages obtained from the application to the peer device. When the peer device is in a silent state, and the detection module 1206 detects an active probe command triggered by a user operation, the sending module 1208 sends a probe message to the peer device. This probe message is used to detect whether the peer device is still in a normal connection state. The receiving module 1209 is used to receive messages from the peer device and pass them to the application. The communication module 1201 can notify the status management module 1204, the timing module 1202, etc., of successful or failed message reception or transmission. For detailed descriptions, please refer to the foregoing embodiments; further details will not be repeated here.

[0355] The timing module 1202 is used to set a timer. When the electronic device 100 is online, each time the electronic device 100 successfully sends or receives a message, it resets the device status bit and the timer. The timer starts counting from the moment of the last message transmission and reception, calculating whether the time limit for non-communication between the electronic device 100 and the peer device has exceeded the timer threshold. When the timer overflows and is interrupted, the timing module 1202 notifies the judgment module 1203.

[0356] The judgment module 1203 is used to determine whether the current device state meets the triggering conditions for the silent state. When the judgment module 1203 receives a timer overflow interrupt message from the timing module 1202, the judgment module 1203 reads the current device status bit. If the current device status bit is reset, then the device status bit is set; if the current device status bit is set, then the triggering conditions for the silent state are met, and the status management module 1204 is notified to change the device state.

[0357] The status management module 1204 is used to record and change the status of the peer device, including online, silent, and offline states. When the peer device is online, if the status management module 1204 receives a message from the judgment module 1203 indicating a change to the silent state, it can change the peer device's status from online to silent. When the peer device is silent, if the status management module 1204 receives a message from the communication module 1201 indicating successful message transmission / reception, it can change the peer device's status from silent to online. When the peer device is silent, if the status management module 1204 receives a message from the communication module 1201 indicating a failure to transmit or receive messages, it can change the peer device's status from silent to offline. When the peer device is online, if the status management module 1204 receives a message from the communication module 1201 indicating a failure to send or receive messages, the status management module 1204 can change the status of the peer device from online to offline. Conversely, when the peer device is offline, if the status management module 1204 receives a message from the communication module 1201 indicating a successful message send or receive, the status management module 1204 can change the status of the peer device from offline to online.

[0358] The session management module 1205 is used to manage session state and session lifecycle, such as creating a session, maintaining a session, closing a session, and removing a session.

[0359] The detection module 1206 can be used to detect user operations on the electronic device 100. For example, the detection module 1206 can detect user clicks and swipes on the icon of the peer device on the application interface, and generate detection commands for the peer device. User operations can include touch operations, voice operations, gesture operations, etc.

[0360] The display module 1207 can be used to display the user interface, allowing users to easily perceive the status of the peer device. For example, the online status is displayed by highlighting the device icon, the inactive status by graying out the device icon, and the offline status is not displayed in the user interface. The display module 1207 can display different device icon identifiers according to the status change notifications from the status management module 1204.

[0361] For more detailed descriptions of the functions of the communication module 1201, timing module 1202, judgment module 1203, status management module 1204, session management module 1205, detection module 1206, and display module 1207, please refer to [link / reference]. Figures 1 to 11 The descriptions of the aforementioned embodiments will not be repeated here.

[0362] The implementation methods described in the above embodiments are merely illustrative and do not constitute any limitation on other embodiments of this application. Specific internal implementation methods may vary depending on the type of electronic device, the operating system it runs, the program used, and the interfaces called. This application does not impose any limitations; any implementation that achieves the functional features described in this application is sufficient. The various implementation methods of this application can be arbitrarily combined to achieve different technical effects.

[0363] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as meaning "if...", "after...", "in response to determining...", or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is interpreted as meaning "if determining...", "in response to determining...", "when (the stated condition or event) is detected", or "in response to detecting (the stated condition or event)".

[0364] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0365] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

[0366] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method of detecting, characterized by, The method comprises: The first device establishes a connection with a second device, wherein the state of the second device recorded by the first device comprises an online state, an offline state, and a silent state, the online state indicating that communication between the first device and the second device is normal, the offline state indicating that communication between the first device and the second device is abnormal, and the silent state indicating that whether communication between the first device and the second device is normal is in an uncertain state, and the second device needs to be confirmed to be in the online state or the offline state through re-detection; the first device and the second device are terminal devices of a user; When a packet of the second device is received, the first device refreshes the state of the second device as the online state and starts a timer to begin timing; The first device confirms that a time interval in which no packet of the second device is received exceeds a first time limit; The first device changes the state of the second device from the online state to the silent state; An interface of an application of the first device displays an icon identifier of the second device; if the second device is in the online state, the icon identifier of the second device in the interface presents a first display state; if the second device is in the silent state, the icon identifier of the second device in the interface presents a second display state; and if the second device is in the offline state, the icon identifier of the second device in the interface presents a third display state or is not displayed; In a case where the icon identifier of the second device presents the second display state, the first device sends a first probe packet to the second device in response to a user operation on the icon identifier of the second device; the first probe packet is a broadcast message; If the first device receives a response packet of the second device with respect to the first probe packet, the first device changes the state of the second device from the silent state to the online state, and the icon identifier of the second device is updated to the first display state; If the first device does not receive the response packet of the second device with respect to the first probe packet, the first device changes the state of the second device from the silent state to the offline state, and the icon identifier of the second device is updated to the third display state or is not displayed.

2. The method of claim 1, wherein, The first device is provided with a device state bit, the device state bit indicating the number of interruptions of the timer, the device state bit comprising reset and setting, and the method further comprises: When the first device refreshes the state of the second device as the online state, the first device changes the device state bit to the reset; When the first device detects an overflow interruption of the timer, the first device reads the device state bit; If the device state bit is read as the reset, the first device changes the device state bit from the reset to the setting; and if the device state bit is read as the setting, the first device confirms that a trigger condition for changing the silent state is met.

3. The method of claim 2, wherein, The first device confirms that a time interval in which the second device does not receive the packet exceeds a first time limit, and specifically includes: The first device detects a first overflow interrupt of the timer, and the first device reads that the device status bit is the reset; The first device changes the device status bit from the reset to the set, and restarts the timer to start timing; The first device detects a second overflow interrupt of the timer, and the first device reads that the device status bit is the set, and the first device confirms that a trigger condition for changing the silent state is met.

4. The method of claim 3, wherein, The first time required for the first overflow interrupt of the timer is different from the second time required for the second overflow interrupt of the timer.

5. The method of claim 1, wherein, The interface of the application of the first device displays an icon identifier of the second device; If the second device is in the online state, the icon identifier of the second device is displayed in bright in the interface; If the second device is in the silent state, the icon identifier of the second device is displayed in gray in the interface; If the second device is in the offline state, the icon identifier of the second device is not displayed in the interface.

6. The method of claim 5, wherein, In response to a user operation on the icon identifier of the second device, the first device sends a first probe packet to the second device, and specifically includes: The first device detects a user operation of clicking the icon identifier of the second device displayed in gray; In response to the user operation, the first device sends a first probe packet to the second device.

7. The method of claim 5, wherein, The method further includes: The first device detects that the application is called to run in the foreground; The first device sends a first probe packet to the second device.

8. The method according to any one of claims 1 to 7, characterized in that, The first device is provided with a silent probe interface, and the first device sends a first probe packet to the second device, and specifically includes: The first device detects that the application calls the silent probe interface, and the event triggering the application to call the silent probe interface includes that the first device detects a user operation of clicking the icon identifier of the second device displayed in gray, or the first device detects that the application is called to run in the foreground; The first device sends a first probe packet to the second device through the silent probe interface.

9. The method according to any one of claims 1-7, characterized in that, The method further includes: If the first device confirms that the state of the second device is the silent state or the offline state, the timer is terminated.

10. The method according to any one of claims 1-7, characterized in that, The method further includes: If the state of the second device is the offline state, if the first device successfully sends a message to the second device, the first device changes the state of the second device from the offline state to the online state.

11. The method according to any one of claims 1-7, characterized in that, The method further includes: If the state of the second device is the online state, if the first device fails to send a message to the second device, the first device changes the state of the second device from the online state to the offline state.

12. An electronic device, comprising: The electronic device includes a communication apparatus, a display apparatus, a memory, and a processor coupled to the memory, and one or more programs; the communication apparatus is configured to communicate, the display apparatus is configured to display an interface, the memory stores computer executable instructions, and the processor executes the instructions to cause the electronic device to implement the method in any one of claims 1 to 11.

13. A computer-readable storage medium comprising instructions, wherein: The instructions, when executed on an electronic device, cause the electronic device to perform the method in any one of claims 1 to 11.

14. A communication system including a first device and a second device, wherein The first device implements the method in any one of claims 1 to 11.

Images