Bluetooth connection method, apparatus, device, and storage medium

Abstract

Embodiments of the present application provide a Bluetooth connection method, device and equipment and storage medium, relating to the technical field of communication. The method is applied to a second device, which is a connected device, and a first device, which is a connecting device. The method comprises: in response to establishing a communication connection with the first device, establishing a collaborative session with the first device through the communication connection; exchanging Bluetooth capability information with the first device in the collaborative session; after automatically starting the Bluetooth function of the local device according to the exchanged Bluetooth capability information, sending Bluetooth device information of the local device to the first device; switching the local Bluetooth to a connectable state and starting a controlled connectable window; and if a Bluetooth connection request initiated by the first device according to the Bluetooth device information is received in the controlled connectable window, establishing a Bluetooth link. The method is used to reduce user intervention, reduce dependence on broadcast scanning, improve connection efficiency, target certainty and connection success rate, and the like.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a Bluetooth connection method, apparatus, device and storage medium. Background Technology

[0002] With the popularization of the Internet of Things and smart hardware, smart devices typically have both Wi-Fi and Bluetooth wireless communication capabilities. After establishing a Wi-Fi connection between devices, users often need to further establish a Bluetooth connection for purposes such as audio transmission and data synchronization.

[0003] However, in existing solutions, after a Wi-Fi connection is established, the Bluetooth connection process usually still relies on the user manually turning on, scanning, and selecting the target device, making it difficult to effectively integrate with existing Wi-Fi sessions. Furthermore, in environments with dense devices or multiple devices with the same name, it is susceptible to broadcast interference, leading to insufficient connection determinism, increased risk of false connections, and overall low connection efficiency.

[0004] Therefore, how to automatically trigger the Bluetooth collaboration process through a trusted context on the basis of existing Wi-Fi and other communication connections, and ensure the determinism and security of Bluetooth information exchange, thereby reducing the cumbersome operation for users and improving the Bluetooth connection efficiency and user experience in multiple wireless communication scenarios, has become an urgent technical problem to be solved. Summary of the Invention

[0005] This application provides a Bluetooth connection method, apparatus, device, and storage medium to solve the aforementioned technical problems. This solution utilizes existing communication links to guide subsequent Bluetooth connections, enabling the Bluetooth connection process to seamlessly integrate with existing sessions. It facilitates connection capability negotiation, connection information transmission, and connection establishment control between devices, thereby improving the automation level, connection determinism, and connection reliability of Bluetooth connections in multi-wireless collaborative scenarios.

[0006] In a first aspect, embodiments of this application provide a Bluetooth connection method applied to a second device, wherein the second device is a connected end device and the first device is a connecting end device, the method comprising:

[0007] In response to establishing a communication connection with the first device, a collaborative session is established with the first device through the communication connection;

[0008] In the collaborative session, Bluetooth capability information is exchanged with the first device. After automatically enabling the local Bluetooth function according to the exchanged Bluetooth capability information, the local Bluetooth device information is sent to the first device.

[0009] Switch the local Bluetooth to connectable mode and start the controlled connectable window;

[0010] If a Bluetooth connection request initiated by the first device based on the Bluetooth device information is received within the controlled connectable window, a Bluetooth link is established.

[0011] In one possible implementation, the method further includes:

[0012] In the collaborative session, a first verification credential is generated, and the Bluetooth device information sent to the first device carries the first verification credential.

[0013] After establishing the Bluetooth link, the second verification credential sent by the first device is received through the Bluetooth link;

[0014] The first verification credential is compared with the second verification credential. If they match, the Bluetooth service capability is enabled; if they do not match, the Bluetooth service is rejected and the Bluetooth link is disconnected.

[0015] In one possible implementation, the Bluetooth capability information includes one or more of the following: whether the device supports Bluetooth, the supported Bluetooth types, the current Bluetooth on / off state, whether the user authorizes automatic Bluetooth activation in response to establishing a communication connection with the first device, and whether the device is in a restricted activation mode.

[0016] In one possible implementation, automatically enabling the local Bluetooth function based on the exchanged Bluetooth capability information includes:

[0017] Based on the exchanged Bluetooth capability information, determine whether the local end meets the automatic activation conditions; wherein, the automatic activation conditions include one or more of the following: both devices support Bluetooth, the Bluetooth types supported by both devices are compatible with each other, the user has authorized the automatic activation of Bluetooth in response to establishing a communication connection with the first device, and neither device is currently in an activation restricted mode.

[0018] If the automatic activation conditions are met and the local Bluetooth is currently off, then the local Bluetooth function will be automatically activated.

[0019] If the automatic activation conditions are met and the local Bluetooth is currently enabled, then the enabled state will remain enabled.

[0020] In one possible implementation, the method further includes a corresponding exception handling mechanism when one of the following abnormal conditions occurs:

[0021] If automatically enabling local Bluetooth fails, the process is terminated, and a notification of Bluetooth enabling failure is sent to the first device via the communication connection.

[0022] If a Bluetooth connection request is received within the controlled connectable window but the Bluetooth link establishment fails, a limited number of retries will be performed according to the backoff retry strategy.

[0023] If the Bluetooth connection request is not received within the controlled connectable window, the connectable state will be automatically exited after the controlled connectable window ends, and the temporary context data of this collaborative session will be cleared.

[0024] If the communication connection is interrupted during the collaborative session, the identifier and verification data of this collaborative session will be discarded immediately, and the connection will be exited.

[0025] Secondly, embodiments of this application provide another Bluetooth connection method, applied to a first device, wherein the first device is a connecting device and the second device is a connected device, the method comprising:

[0026] In response to establishing a communication connection with the second device, a collaborative session is established with the second device through the communication connection;

[0027] In the collaborative session, Bluetooth capability information is exchanged with the second device. After automatically enabling the local Bluetooth function based on the exchanged Bluetooth capability information, Bluetooth device information sent by the second device is received.

[0028] Based on the Bluetooth device information, a Bluetooth connection request is initiated to the second device within the controlled connectable window of the second device to establish a Bluetooth link.

[0029] In one possible implementation, the method further includes:

[0030] In the collaborative session, a first verification credential sent by the second device is received; wherein the first verification credential is carried in the Bluetooth device information;

[0031] After establishing the Bluetooth link, a second verification credential is sent to the second device through the Bluetooth link for the second device to compare with the first verification credential.

[0032] In one possible implementation, the communication connection includes a WiFi connection, and the step of establishing a collaborative session with the second device via the communication connection in response to establishing a communication connection with the second device includes:

[0033] After detecting a successful WiFi connection with the second device, the Bluetooth collaboration service entry point of the second device is located through the local area network service discovery method;

[0034] Send a session initialization message to the Bluetooth collaboration service entry point via the WiFi connection; wherein, the session initialization message carries the local device identifier, protocol version, and collaboration request type;

[0035] Receive a session confirmation message returned by the second device through the WiFi connection; wherein the session confirmation message carries a session identifier;

[0036] A temporary context for this collaborative session is established based on the session identifier.

[0037] In one possible implementation, the step of initiating a Bluetooth connection request to the second device within the controlled connectable window of the second device, based on the Bluetooth device information, to establish a Bluetooth link includes:

[0038] If the Bluetooth type in the Bluetooth device information is Classic Bluetooth, then a Page request is initiated to the second device based on the Bluetooth address in the Bluetooth device information to establish an ACL link;

[0039] If the Bluetooth type in the Bluetooth device information is Bluetooth Low Energy (BLE), then a BLE connection request is initiated to the second device based on the Bluetooth address or service prompt information in the Bluetooth device information to establish a GATT session.

[0040] Thirdly, embodiments of this application provide a Bluetooth connection device applied to a second device, wherein the second device is a connected end device and the first device is a connecting end device, and the device includes:

[0041] A first processing unit is configured to, in response to establishing a communication connection with the first device, establish a collaborative session with the first device through the communication connection;

[0042] The second processing unit is used to exchange Bluetooth capability information with the first device in the cooperative session, and after automatically enabling the local Bluetooth function according to the exchanged Bluetooth capability information, send the local Bluetooth device information to the first device.

[0043] The third processing unit is used to switch the local Bluetooth to a connectable state and start the controlled connectable window;

[0044] The fourth processing unit is configured to establish a Bluetooth link if, within the controlled connectable window, it receives a Bluetooth connection request initiated by the first device based on the Bluetooth device information.

[0045] Fourthly, embodiments of this application provide another Bluetooth connection device, applied to a first device, wherein the first device is a connecting device and the second device is a connected device, the device comprising:

[0046] The fifth processing unit is configured to establish a collaborative session with the second device in response to establishing a communication connection with the second device;

[0047] The sixth processing unit is used to exchange Bluetooth capability information with the second device in the cooperative session, and after automatically enabling the local Bluetooth function according to the exchanged Bluetooth capability information, receive Bluetooth device information sent by the second device.

[0048] The seventh processing unit is configured to initiate a Bluetooth connection request to the second device within the controlled connectable window of the second device, based on the Bluetooth device information, in order to establish a Bluetooth link.

[0049] Fifthly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0050] The memory stores computer-executed instructions;

[0051] The processor executes computer execution instructions stored in the memory, causing the processor to perform the various possible implementations described above.

[0052] Sixthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the various possible implementations described above.

[0053] In a seventh aspect, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the various possible implementations described above.

[0054] The Bluetooth connection method, apparatus, device, and storage medium provided in this application embodiment establish a collaborative session after the second device establishes a communication connection with the first device. In the collaborative session, Bluetooth capability information is exchanged, and after automatically enabling the local Bluetooth function, local Bluetooth device information is sent to the first device. At the same time, the local Bluetooth is switched to a connectable state and a controlled connectable window is started. Within the controlled connectable window, a Bluetooth connection request initiated by the first device based on the Bluetooth device information is responded to. This enables the Bluetooth connection establishment process to work in coordination with the existing communication connection, reducing the reliance on users to manually enable, scan, and select devices. As a result, the automation level, connection determinism, reliability, and overall connection efficiency of Bluetooth collaborative connection are improved. Attached Figure Description

[0055] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0056] Figure 1 A flowchart illustrating a Bluetooth connection method provided in an embodiment of this application;

[0057] Figure 2An interactive flowchart for establishing a collaborative session is provided as an embodiment of this application;

[0058] Figure 3 An interactive flowchart for sending Bluetooth device information is provided in an embodiment of this application;

[0059] Figure 4 An interactive flowchart for security verification control provided in an embodiment of this application;

[0060] Figure 5 A flowchart illustrating another Bluetooth connection method provided in an embodiment of this application;

[0061] Figure 6 An interactive flowchart of a Bluetooth connection method provided in an embodiment of this application;

[0062] Figure 7 This is a schematic diagram of the structure of a Bluetooth connection device provided in an embodiment of this application;

[0063] Figure 8 This is a schematic diagram of another Bluetooth connection device provided in an embodiment of this application;

[0064] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0065] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0066] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0067] With the widespread deployment of smartphones, tablets, in-vehicle systems, smart speakers, projection devices, wearable devices, and various IoT gateways, devices often need to exchange data, discover services, or establish sessions via Wi-Fi, and use Bluetooth for audio transmission, peripheral control, identity binding, or low-power interaction. Typical application scenarios include collaborative interconnection between mobile phones and in-vehicle systems, rapid connection between mobile phones and smart speakers or projection devices in home scenarios, automatic pairing between terminals and conference peripherals in office environments, and temporary interaction between terminals and nearby smart devices in public environments. These scenarios typically require devices to continue connecting across wireless links on top of existing network connections. Therefore, they rely on both network-side communication channels and the pairing capabilities of short-range wireless protocols, placing high demands on connection efficiency, connection determinism, and user ease of operation.

[0068] In existing technologies, in various communication scenarios, smart terminals and smart peripherals typically first establish a communication connection via Wi-Fi or share the same local area network environment. Then, the user manually enables Bluetooth on both devices, enters the system's Bluetooth settings interface to scan, select, and pair them before a Bluetooth link can be established and subsequent services can commence. This often relies on a Bluetooth broadcast discovery mechanism, where the target device continuously sends its Bluetooth identifier and service information. The connecting party determines the device based on the device name, signal strength, or historical data in the scan list and initiates a connection. In some scenarios, QR codes, NFC, or accompanying applications may be used to pre-transmit Bluetooth addresses and device names to the connecting party, which then completes the targeted connection. However, while these solutions can shorten the search range to some extent, the overall process still heavily relies on user intervention, and most do not establish a continuous, collaborative process between the Wi-Fi session and the Bluetooth link. Especially in environments with dense device populations, many devices with the same name, or complex signal conditions, the Bluetooth scan list can easily contain numerous irrelevant devices, requiring the user to repeatedly compare names, icons, or signal strength to select the target device. If the target device has limited broadcasting, long broadcasting intervals, or is in a state without a screen or with weak interactive capabilities, the scanning and discovery process may also experience timeouts, omissions, or misselections.

[0069] It is evident that, because current Bluetooth connection requests still primarily rely on broadcast discovery and manual confirmation, they are susceptible to interference from devices with the same name, broadcast collisions, environmental noise, and changes in device status, resulting in unsatisfactory connection success rates and target determinism. In practical use, this has revealed problems such as low connection efficiency, numerous interaction steps, high risk of false connections, and insufficient reliability. Therefore, how to seamlessly integrate Bluetooth connection processes with existing communication connections such as Wi-Fi, while reducing manual intervention and improving the determinism, reliability, and efficiency of target connections, has become a pressing technical challenge.

[0070] To address the aforementioned issues, this application provides a Bluetooth connection method. When a second device responds to establishing a communication connection with a first device, it first establishes a collaborative session with the first device through this communication connection. Then, it exchanges Bluetooth capability information within the collaborative session. After automatically enabling its own Bluetooth function based on the exchanged Bluetooth capability information, it sends its own Bluetooth device information to the first device. Subsequently, it switches its own Bluetooth to a connectable state and initiates a controlled connectable window. Finally, within this controlled connectable window, it receives a Bluetooth connection request initiated by the first device based on the Bluetooth device information and establishes a Bluetooth link. By integrating the communication connection, collaborative session, Bluetooth capability exchange, automatic Bluetooth activation, controlled connectable window, and Bluetooth link establishment into a unified process, Bluetooth connection no longer relies entirely on traditional scanning discovery and manual selection. Instead, it achieves targeted connection based on existing communication connections, thus laying the foundation for subsequent automated pairing and reliable connection.

[0071] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0072] Figure 1 This is a flowchart illustrating a Bluetooth connection method provided in an embodiment of this application. The method in this embodiment is applied to a second device, which, as the connected end device, collaboratively establishes a Bluetooth link with a first device, which is the connecting end device, based on an existing communication link. Figure 1 As shown, the Bluetooth connection method provided in this embodiment may include:

[0073] S101, In response to establishing a communication connection with the first device, a collaborative session is established with the first device through the communication connection.

[0074] For example, the communication connection in this step refers to an existing transmission link capable of carrying data interaction between the two parties and meeting the conditions for session establishment. In this embodiment, it can be a local area network connection based on Wi-Fi (Wireless Fidelity), that is, the first device and the second device establish a Wi-Fi connection by accessing the same Wi-Fi hotspot, or by one party turning on the hotspot and the other party accessing it; or it can be other wireless or wired connections with stable transmission capabilities, such as Ethernet connections, power line communication, USB network sharing, Wi-Fi Direct, Wi-Fi P2P, millimeter wave communication, Zigbee, etc. The cooperative session refers to a logical session established on this communication connection for this cross-wireless link cooperative connection process, used to carry session initialization messages, capability exchange messages, device information messages, and subsequent control messages, etc.

[0075] When the second device detects a successful communication connection with the first device, it uses this successful connection event as a trigger to automatically initiate the Bluetooth collaborative session establishment process. For example, the second device can initiate the collaborative service discovery process after the network interface management module detects successful Wi-Fi association, completed IP (Internet Protocol) address allocation, and network interconnection with the first device. In one possible embodiment, the second device obtains the collaborative service entry address, session listening port, or logical service identifier provided by the first device through mDNS (Multicast DomainName System), SSDP (Simple Service Discovery Protocol), LAN broadcast detection, preset port detection, or service location methods based on application layer session identifiers, and sends a session initialization message to this entry point. This session initialization message may include the second device's device identifier, current network session identifier, timestamp, random number, protocol version number, and the type of collaborative service to be established. After receiving the session initialization message, the first device returns a session confirmation message, which may include the first device identifier, the session identifier used for this collaborative connection process, and a first random number or verification field. After receiving the confirmation message, the second device combines the random number generated on its own end, the random number received from the peer end, and the network connection context to generate a session context corresponding to this collaborative session. This session context is then saved in memory or a session management table for use during subsequent Bluetooth capability exchange and Bluetooth link establishment. Furthermore, the collaborative service discovery process can also be initiated by the first device; this embodiment does not impose any restrictions.

[0076] For example, Figure 2 This is an interactive flowchart illustrating the establishment of a collaborative session, provided as an embodiment of this application. Figure 2As shown, when the communication connection is a WiFi connection, after the connecting party detects the successful WiFi connection event, it can initiate a collaborative session establishment request through the WiFi channel. After both parties complete the handshake interaction, the dual-end collaborative session is established.

[0077] Optionally, to ensure the validity of the collaborative session, the second device can also perform network status verification before establishing the session, such as confirming that the current communication connection is not in an authentication intermediate state, that no link jitter has occurred, that no network switching has been triggered, and that the peer address is within the expected range. If the current network quality is detected to be below a threshold, such as excessive round-trip latency, packet loss rate exceeding a preset value, or no response from the peer service, the second device can delay session establishment or re-initiate the session initialization request.

[0078] By establishing a collaborative session, the communication connection is no longer merely a regular data transmission channel, but becomes a trusted trigger and control mechanism for the Bluetooth connection process. This allows for a seamless transition between subsequent Bluetooth link establishment and the existing network session, reducing the process fragmentation caused by separate scanning, manual identification, and repeated confirmation on the Bluetooth side in traditional technologies. The collaborative process is automatically triggered using the existing communication connection without any user intervention, avoiding the need for users to manually access the Bluetooth settings interface. Furthermore, based on the above analysis, this step, by constructing a Bluetooth-collaborative session context immediately after the communication connection is established, lays the foundation for subsequent Bluetooth capability detection, automatic activation, and information exchange, thereby improving the determinism and timing controllability of the connection process.

[0079] S102. In the collaborative session, exchange Bluetooth capability information with the first device, and after automatically enabling the local Bluetooth function according to the exchanged Bluetooth capability information, send the local Bluetooth device information to the first device.

[0080] For example, the Bluetooth capability information in this step refers to a set of information reflecting the device's Bluetooth hardware capabilities, protocol support capabilities, current Bluetooth operating status, and automatic activation policy conditions. Automatically activating the local Bluetooth function means that the second device, when meeting the capability and policy conditions, actively switches the Bluetooth function from a disabled state to an enabled state through the local system control interface or Bluetooth control module, without relying on manual user intervention in system settings. Bluetooth device information refers to the identification and connection parameters required for the first device to subsequently initiate a targeted Bluetooth connection, which may include Bluetooth address, device name, device type, supported Bluetooth modes, additional identifiers required for broadcasting or connecting, and verification information bound to the current collaborative session.

[0081] After the collaborative session is established, the second device and the first device exchange their respective Bluetooth capability information through this session. After the exchange, the second device, based on the capability information received from the first device and its local policy configuration, determines whether the conditions for automatically enabling Bluetooth are met. These conditions typically include: both devices support Bluetooth; the Bluetooth types supported by both devices overlap (e.g., if one device supports Classic Bluetooth and the other supports BLE, a connection may not be established); the user has authorized automatic enabling; and the device is not currently in restricted mode. If the conditions are met and the local Bluetooth is currently off, the second device automatically calls the operating system's Bluetooth interface to enable Bluetooth; if Bluetooth is already enabled, it remains enabled. It should be noted that the first device also performs a similar automatic enabling operation; each device independently initiates its local Bluetooth startup.

[0082] Optionally, in one possible embodiment, the Bluetooth capability information includes one or more of the following: whether the device supports Bluetooth, the supported Bluetooth types, the current Bluetooth on / off state, whether the user authorizes automatic Bluetooth activation in response to establishing a communication connection with the first device, and whether the device is in a restricted activation mode.

[0083] Understandably, in this embodiment, whether the device supports Bluetooth is used to characterize whether the second device has a Bluetooth radio frequency module, baseband processing unit, and corresponding protocol stack capabilities, so as to determine whether the conditions for establishing a subsequent Bluetooth link are met in the collaborative session. Supported Bluetooth types characterize whether the device supports Classic Bluetooth, Bluetooth Low Energy, or a hybrid type compatible with both, enabling the system to select the corresponding connection method based on service requirements such as audio transmission, control interaction, or low-power bonding. The current Bluetooth switch state characterizes whether the Bluetooth function is currently on or off. After obtaining this state, the system can decide whether to maintain the current state or perform an on / off action. Whether the user authorizes automatic Bluetooth activation in response to establishing a communication connection with the first device characterizes whether the user has granted automatic activation permission through system settings, permission confirmation interface, or device management policy. If not authorized, automatic activation will not be performed even if other conditions are met, in order to meet user control requirements. Whether in restricted activation mode characterizes whether the device is currently restricted by airplane mode, enterprise control, parental control, or other system maintenance states. If in restricted mode, the Bluetooth activation action is blocked or restricted.

[0084] In the specific implementation, after the collaborative session is established, the controller of the second device reads the Bluetooth support identifier, protocol type identifier, switch register status, and permission configuration identifier from the local Bluetooth management module, and encapsulates them into capability information to report to the first device. This Bluetooth management module can be implemented collaboratively by a Bluetooth chip, processor, and storage unit. The storage unit stores user authorization records and restricted mode flags, while the processor updates information in real time based on the system status. Whether a device supports Bluetooth can be obtained through the factory configuration table, hardware detection results, or system capability enumeration. Supported Bluetooth types can be determined by the protocol stack version number, service discovery capability, or hardware configuration bits. The current Bluetooth switch status can be directly returned by the system service interface, and whether it is in restricted mode can be determined by the system policy engine in conjunction with the current flight mode, enterprise policy, or power management status. If the local device receives the capability information corresponding to the first device, it can also match the capabilities of both devices to determine whether to continue automatically enabling Bluetooth and subsequent connectionable state switching, thereby reducing invalid wake-ups.

[0085] In terms of its working principle, capability information provides a preliminary judgment basis for automatically enabling Bluetooth. This allows the second device to determine whether to respond to the communication connection and trigger Bluetooth activation after understanding its own hardware capabilities, current status, and user authorization conditions, and then send Bluetooth device information to the first device accordingly. Because restricted mode and authorization status are included in the judgment scope, the system can avoid accidentally triggering Bluetooth activation in prohibited scenarios, while ensuring that it quickly enters a connectable state when the conditions are met.

[0086] This implementation method accurately reflects the Bluetooth availability and control boundaries of the second device in the collaborative session, providing a clear basis for Bluetooth activation with defined permissions and states. This reduces the risk of invalid activation and erroneous connections, and improves the determinism and reliability of Bluetooth link establishment with the first device. By simultaneously considering Bluetooth support capabilities, type capabilities, on / off status, user authorization, and restricted modes, the system can also automatically select the appropriate Bluetooth connection path based on business needs, thereby enhancing collaborative connection efficiency and terminal interaction experience.

[0087] Optionally, in one possible embodiment, automatically enabling the local Bluetooth function based on the exchanged Bluetooth capability information may include:

[0088] S1. Based on the exchanged Bluetooth capability information, determine whether the local end meets the automatic activation conditions; wherein, the automatic activation conditions include one or more of the following: both devices support Bluetooth, the Bluetooth types supported by both devices are compatible with each other, the user has authorized the automatic activation of Bluetooth in response to establishing a communication connection with the first device, and neither device is currently in an activation restricted mode.

[0089] S2. If the automatic turn-on conditions are met and the local Bluetooth is currently off, then the local Bluetooth function will be automatically turned on.

[0090] S3. If the automatic turn-on conditions are met and the local Bluetooth is currently on, then keep it on.

[0091] For example, in actual implementation, after the second device receives the Bluetooth capability information sent by the first device in the collaborative session, it can first determine whether both devices support Bluetooth, and then further compare whether the Bluetooth types supported by both devices are mutually compatible to determine whether there is a technical basis for automatic Bluetooth activation. If the determination result shows that the protocol forms of both devices are compatible, and the user has authorized automatic Bluetooth activation in response to the communication connection, and the local device is not in a restricted activation mode, the Bluetooth management unit is controlled to read the current Bluetooth switch status of the local device. When the reading result is off, the system Bluetooth switch interface is triggered, enabling the Bluetooth controller to complete initialization, protocol stack loading, and RF enabling, thereby switching the local Bluetooth to the on state; when the reading result is on, the existing state remains unchanged to avoid repeated wake-ups causing connection interruption or state jitter. In addition, if other Bluetooth services already exist on the local device, the local device can continue to maintain the existing service link while maintaining the on state. In practical applications, the Bluetooth management unit can also be selected from other models or implementation forms, which are not limited in this embodiment.

[0092] This optional method verifies the conditions for automatic activation by exchanging Bluetooth capability information. This ensures that the local device only performs Bluetooth wake-up when capabilities are compatible, permissions are permitted, and system status allows, thereby reducing invalid and accidental activations. For devices already activated, the system does not repeat the on / off action, minimizing impact on existing Bluetooth connections and improving state transition stability. For devices already deactivated, the system can automatically activate upon meeting certain conditions, providing prerequisites for subsequent Bluetooth device information transmission, controlled connectable window establishment, and connection request reception.

[0093] By adopting the above specific implementation method, the second device can complete controlled automatic wake-up based on the capability information exchanged with the first device without requiring manual access to the Bluetooth settings interface. This shortens the connection preparation time and improves the continuity of collaborative connections. Since the automatic activation conditions take into account the capabilities of both parties, type compatibility, user authorization, and restricted modes, the risks of mismatched connections, unauthorized wake-ups, and system conflicts can be reduced, improving the reliability, determinism, and user convenience of the Bluetooth connection process.

[0094] For example, after Bluetooth is successfully enabled, the second device obtains the Bluetooth device information of its local Bluetooth device and sends it to the first device in the collaborative session through the existing communication connection. The local Bluetooth device information sent by the second device may include: Bluetooth type (indicating whether to use Classic Bluetooth or BLE connection mode), Bluetooth device address (for directional addressing by the connecting party), Bluetooth device name (for auxiliary logs and interface display), service or profile prompt information (such as A2DP, HFP, SPP, or GATT Service UUID), suggested connection parameters (indicating the effective window duration after the device enters the connectable state), and a one-time verification token generated for this collaborative session. Upon receiving the local Bluetooth device information from the second device, the first device (the connecting party) performs a consistency check on the session identifier and token. If the check passes, it returns an acknowledgment to the second device (the connected party) and prepares to initiate a subsequent Bluetooth connection request.

[0095] For example, Figure 3 This is a flowchart illustrating an interaction for sending Bluetooth device information, provided as an embodiment of this application. Figure 3 As shown, after Bluetooth is enabled, the connected device sends Bluetooth device information (Blinfo) including Bluetooth address, Bluetooth type, service prompt information, window duration, verification token, etc. to the connecting party. After receiving the information, the connecting party returns an acknowledgment, and both parties then complete the preparation for Bluetooth directional connection.

[0096] Compared to existing technologies that rely on Bluetooth broadcasting followed by user-defined target device searches, this step first clarifies the supported conditions for both parties through a collaborative session. Then, the second device automatically enters Bluetooth-available mode and directly informs the first device of its local Bluetooth device information. This ensures the first device has a clear target for subsequent connections, reducing interference from devices with the same name, broadcast collisions, and manual selection errors. On one hand, the first device does not need to open a Bluetooth scanning interface to obtain accurate Bluetooth device information for the target device, enabling it to directly initiate a targeted connection, thus improving connection accuracy and preparation efficiency. On the other hand, the second device does not need to remain in discoverable mode for extended periods, reducing power consumption and privacy risks.

[0097] S103. Switch the local Bluetooth to connectable mode and start the controlled connectable window.

[0098] For example, the connectable state in this step refers to the second device's Bluetooth controller and protocol stack entering a working state that allows receiving Bluetooth connection requests. For Classic Bluetooth, this state typically means the device is in "Page Scan" mode, capable of responding to Page requests from the peer; for Bluetooth Low Energy (BLE), this state means the device is in "Advertising" or "Connectable" mode, capable of accepting connection requests. A controlled connectable window refers to a connection reception time interval actively set by the second device, with clearly defined start conditions and duration limits. Within this time interval, the second device receives Bluetooth connection requests matching the current cooperative session, and after the time interval ends, it closes or shrinks the corresponding connectable capabilities.

[0099] Specifically, after confirming that Bluetooth has been successfully enabled and that Bluetooth device information has been sent to the first device, the second device calls the Bluetooth protocol stack state control interface to switch its local Bluetooth from a normal enabled state to a connection-oriented, connectable state. For the classic Bluetooth implementation, the second device can enable page scanning and set a connectable flag; for the BLE implementation, the second device can configure broadcast set parameters, allowing the device to send targeted connectable broadcasts or enter a state that allows connections to be established to specific addresses within a limited time period. Subsequently, the second device starts a window timer bound to the current collaborative session and writes parameters such as the start time, duration, allowed connection count, and request matching conditions of the window timer into the window control context. In the implementation of the controlled connectable window, the second device can dynamically adjust the window duration to adapt to different scenario requirements. For example, in an in-vehicle scenario, the window duration can be set to 10-30 seconds to ensure timely connection, while in a public environment, the window duration can be shortened to 5-10 seconds to reduce the risk of false connections. Furthermore, the duration of the controlled connectable window can also be dynamically set based on device type, service type, network latency, historical connection success rate, or system policies. For example, in scenarios where vehicle-to-vehicle (V2V) and mobile phone systems collaborate at close range, the window duration can be set to several seconds to over ten seconds to balance connection timeliness and security. In densely populated public environments, the window duration can be further shortened to reduce the chance of other devices attempting to connect. Furthermore, the duration of the controlled connectable window can also be negotiated and determined with the first device during the collaboration session; this application embodiment does not impose any limitations on this.

[0100] In one possible embodiment, before officially opening the controlled connectable window, the second device may perform a pre-connection status check. This pre-check may include confirming that there are no other high-priority Bluetooth pairing processes currently in progress, confirming that the Bluetooth adapter is not undergoing an abnormal reset, confirming that radio frequency resources are available, confirming that the power policy allows for short-term open connectivity, and confirming that the current collaborative session has not timed out. If the pre-check passes, the second device starts the window and records the window start time. If the pre-check fails, the second device can return a connection failure notification to the first device through the collaborative session and end the current connection process.

[0101] To further constrain the scope of connection requests received, the second device can also introduce access control parameters in the window control. For example, the second device can add the Bluetooth address or address digest corresponding to the first device to a whitelist, and only process connection requests from those in the whitelist; it can also set a maximum number of connection attempts to be received within the window, closing the window prematurely if the threshold is exceeded; it can also require connection requests to submit verification data associated with the previously issued one-time token after the link is established, to confirm that the request was indeed initiated by the first device corresponding to the current cooperative session, etc. In the BLE implementation, the second device can also use targeted broadcasting, directing the broadcast target directly to the first device, thereby further reducing the possibility of unrelated devices detecting and initiating connections.

[0102] The controlled connectable window setting in this application prevents the Bluetooth connectable capability of the second device from being permanently exposed. Instead, it allows for on-demand, short-term, and bounded opening after communication connection and capability exchange are completed. This ensures that the first device initiates a connection promptly upon obtaining Bluetooth device information, guaranteeing connection timeliness, while also restricting irrelevant connection requests in terms of timing, improving the controllability of the connection process and reducing the additional power consumption caused by the device being in a connectable state for extended periods. Furthermore, by binding the connectable state to the controlled window, it also achieves a shift from an open connection method of "continuous broadcasting, arbitrary scanning, and manual selection" to a controlled connection method of "short-term openness, targeted access, and session association," thereby improving the determinism and privacy security of the target connection and reducing the risk of false connections and resource consumption.

[0103] S104. If a Bluetooth connection request initiated by the first device based on Bluetooth device information is received within the controlled connectable window, a Bluetooth link is established.

[0104] For example, the Bluetooth connection request in this step refers to a targeted connection request initiated by the first device to the second device directly based on the Bluetooth device information after the first device receives the Bluetooth device information sent by the second device, without or with minimal filtering of a public scan list. The Bluetooth link refers to the logical communication link established between the second device and the first device based on the Bluetooth protocol. In different implementations, it can be a classic Bluetooth ACL (Asynchronous Connection-Less) link, a paired audio or control link, or a BLE connection link and its subsequent GATT (Generic Attribute Profile) interaction channel.

[0105] Specifically, during the controlled connectable window, the second device continuously listens for connection events reported by the Bluetooth controller. When the Bluetooth protocol stack detects a connection request, the second device first extracts the source device identifier, target address, connection type, time information, and possibly the pairing context from the request, and compares it with the Bluetooth device information, the first device's capability information, and the window control context in the current cooperative session. The comparison process may include address matching, device type matching, protocol type matching, window time matching, and token consistency verification. If the source device identifier corresponding to the connection request matches the first device in the cooperative session, and the request arrival time is within the controlled connectable window, the second device accepts the connection request and invokes the Bluetooth protocol stack to complete link establishment, link parameter negotiation, necessary pairing or binding processes, and subsequent service readiness notification.

[0106] In one possible embodiment, for a classic Bluetooth connection, the second device can establish a basic link after receiving a paging request, and, in conjunction with a one-time token or session identifier previously issued to the first device via the communication connection, perform session binding confirmation during the application layer handshake phase after the link is established. For a BLE connection, after establishing the connection, the second device can transmit token verification data through GATT feature read / write or control service interaction to confirm that the BLE connection belongs to the same connection process as the previous cooperative session. Only when the verification passes will the second device mark the Bluetooth link as a valid service link and open subsequent functions such as audio, control, identity binding, or low-power interaction to upper-layer applications. If the verification fails, the second device can actively disconnect the link and record the abnormal event.

[0107] In another possible implementation, if the first device fails its initial connection attempt within the controlled connectable window—for example, due to transient radio frequency interference, parameter mismatch, or link establishment timeout—the second device can remain connectable for the remaining time of the window and allow the first device to re-initiate the connection request. If the number of retries does not exceed a preset threshold, the second device continues to perform request listening and matching verification; if the window expires without successful establishment, the second device closes the connectable state and can return a failure result or suggest re-initiating the collaborative process to the first device through the existing communication connection. If the system policy allows, the second device can also open a new controlled connectable window if the first device requests an extension through the communication connection, but the new window will still be bound to a new timestamp or new verification information to avoid reusing old requests across windows.

[0108] This step completes the final connection from the network-side session to the Bluetooth-side link by receiving and verifying the targeted connection request initiated by the first device based on Bluetooth device information within a controlled window. Since the first device does not blindly scan for unknown devices in the environment but initiates the connection based on the Bluetooth identifier explicitly issued by the second device through the communication connection, target device identification is more accurate. Simultaneously, the second device only accepts requests matching the current session within a controlled time, giving the connection establishment clear time boundaries and identity constraints. Based on this, this step can significantly reduce the probability of false connections in densely populated environments, improve the success rate of Bluetooth link establishment, and provide a foundation for subsequent services to operate in a trusted context.

[0109] The Bluetooth connection method provided in this embodiment integrates communication connection, cooperative session establishment, Bluetooth capability exchange, automatic Bluetooth activation, targeted transmission of Bluetooth device information, controlled connectable window management, and targeted Bluetooth connection establishment within the window into a continuous processing flow. This allows the second device to utilize the trusted context formed by existing Wi-Fi or other communication connections to directly provide the first device with the target information and access timing control required for subsequent Bluetooth connections. This avoids the operational link fragmentation problems caused by relying on public Bluetooth scanning lists, manual device selection, and repeated confirmations in traditional technologies. Furthermore, the controlled connectable window limits Bluetooth connectability to a specific time period and can constrain connection requests by combining address matching, token verification, whitelist control, and retry mechanisms, thereby improving the determinism of target connections, the controllability of connection timing, and the connection success rate in complex environments.

[0110] It should be understood that the above examples are merely illustrative and not limiting. In one possible embodiment, the communication connection type, capability information field, Bluetooth device information content, window duration setting method, and link verification mechanism can all be equivalently replaced, modified, or combined according to the terminal form, service requirements, system policies, and deployment environment. As long as the technical objective of establishing Bluetooth collaboration based on the existing communication connection and establishing a directional Bluetooth link within the controlled window can be achieved, it falls within the scope achievable by the embodiments of this application.

[0111] Optionally, in one possible embodiment, based on any of the above embodiments, the Bluetooth connection method provided in this application may further include a session binding verification and security control process. Specifically, it may include:

[0112] S10. In the collaborative session, generate a first verification credential and make the Bluetooth device information sent to the first device carry the first verification credential;

[0113] S20. After establishing the Bluetooth link, receive the second verification credential sent by the first device through the Bluetooth link;

[0114] S30. Compare the first verification credential with the second verification credential. If they match, enable Bluetooth service capability; if they do not match, reject Bluetooth service and disconnect Bluetooth link.

[0115] For example, the first verification credential is used to identify the uniqueness of this collaborative session. It can be generated by the second device based on random numbers, session identifiers, timestamps, or combinations thereof, and can be implemented in the form of token strings, digest values, ticket values, or encrypted verification values ​​to reduce the risk of replay or impersonation. The generation algorithm, length range, and storage method of the first verification credential can be configured according to the security level and device computing power in practical applications; this application embodiment does not limit these aspects.

[0116] In its implementation, after the collaborative session is established, the second device can first generate a first verification credential in its local secure storage area and write it into the Bluetooth device information message to be sent. Then, it sends this credential to the first device via the communication connection in the collaborative session. The first device initiates a Bluetooth connection request based on the received Bluetooth device information and establishes a Bluetooth link with the second device. It then sends back a second verification credential through this Bluetooth link. The second verification credential can be a direct echo of the first verification credential, or it can be a response value obtained by hashing, symmetric encryption, or signing the first verification credential. Upon receiving the second verification credential, the second device compares it with the locally stored first verification credential. If the two meet a preset consistency condition, it determines that the current Bluetooth link was indeed exported from the collaborative session, thereby enabling Bluetooth service capabilities, such as audio transmission, control command interaction, file transfer, or other Bluetooth services. If the comparison result is inconsistent, it determines that the connection subject and session credential do not match, thus rejecting the Bluetooth service and disconnecting the Bluetooth link. Temporary session data can also be cleared to prevent subsequent misuse.

[0117] For example, Figure 4 This is an interactive flowchart illustrating a security verification control method provided in an embodiment of this application. Figure 4 As shown, after a Bluetooth link is successfully established, the connecting party can send a token or its hash value (HMAC) to the connected party through the established Bluetooth link. The connected party will compare the received credentials with the token previously stored through the Wi-Fi cooperative session. If they match, a trusted Bluetooth service channel will be established. If they do not match, the service will be denied, the Bluetooth link will be actively disconnected, and a security log will be recorded.

[0118] This credential verification mechanism enables Bluetooth links to no longer rely solely on address matching or broadcast discovery, but instead to complete identity consistency confirmation through session-level two-way credentials. In operation, the cooperative session first establishes a trusted context, then the second device embeds the first verification credential into the Bluetooth device information. Subsequently, after the Bluetooth link is established, a verification is performed, and Bluetooth services are only allowed if the verification passes. This separates connection establishment from service access control, forming a constrained trusted connection closed loop.

[0119] By employing the above methods, we can effectively avoid misconnection of devices with the same name, unauthorized connection by third-party devices, and unauthorized access to services on established links. This improves the determinism and security of Bluetooth connections, reduces the confirmation burden on users in multi-device environments, and makes Bluetooth access based on Wi-Fi and other communication methods for collaborative sessions more stable and reliable.

[0120] Optionally, in one possible embodiment, based on any of the above embodiments, the Bluetooth connection method provided in this application may further include an exception handling mechanism. Specifically, when one of the following exceptions occurs, a corresponding exception handling mechanism may also be included:

[0121] S100. If automatically enabling local Bluetooth fails, terminate the process and send a notification of Bluetooth enabling failure to the first device via the communication connection.

[0122] S200. If a Bluetooth connection request is received within the controlled connectable window but the Bluetooth link establishment fails, a limited number of retries will be performed according to the backoff retry strategy.

[0123] S300: If no Bluetooth connection request is received within the controlled connectable window, the connectable state will be automatically exited after the controlled connectable window ends, and the temporary context data of this collaborative session will be cleared.

[0124] S400 If the communication connection is interrupted during the collaborative session, the identifier and verification data of this collaborative session will be discarded immediately, and the connectable state will be exited.

[0125] For example, Bluetooth startup failure could be due to unavailable system Bluetooth service, abnormal initialization of the underlying radio frequency module, restricted permissions, or triggering of restricted mode. The Bluetooth startup failure notification can carry a failure reason code so that the first device can stop subsequent connection requests. The controlled connectable window refers to the time interval within which the first device is allowed to initiate a Bluetooth connection request within a preset duration. Its length can be configured based on the cooperative session identifier, device capabilities, or environmental status. The backoff retry strategy can use an incremental waiting interval to control the timing of re-establishing the link. The number of retries can be limited to a preset limit (such as 3 or 5 times) to avoid repeatedly occupying wireless resources. Temporary context data includes session identifier, verification data, cooperative parameters, device address, and connection state cache. When the window ends or the communication connection is interrupted, the system will perform invalidation marking and clearing processing on the above data to avoid subsequent misuse. If the communication connection is interrupted after the cooperative session is established and the Bluetooth link has not yet been formed, the system will immediately cancel the current session association state and close the connectable state to prevent the Bluetooth connection entry from being exposed when the upper layer control is lost.

[0126] In this implementation, by assigning abnormal situations to four types of processing logic—termination, retry, cleanup, and abandonment—Bluetooth auto-start, targeted connection, and session maintenance can operate under controlled conditions. Its working principle is as follows: when an unrecoverable anomaly occurs in the collaborative connection link, subsequent actions are immediately cut off and the state is reclaimed; when only a short-term link establishment failure occurs, a limited number of retries are performed under window constraints to improve the connection success rate without causing long-term resource occupation; when a connection request is missing or upper-layer communication is interrupted, the connectable state is promptly exited and temporary data is cleared to prevent suspended sessions from affecting subsequent collaboration.

[0127] By adopting the above-mentioned anomaly handling mechanism, the stability of the collaborative connection process can be maintained under complex scenarios such as wireless interference, changes in device status, and communication link jitter. This reduces the risk of connection residue caused by Bluetooth failure to start, link establishment failure, or communication interruption, and improves the recoverability of the connection process, resource utilization efficiency, and overall service reliability.

[0128] Figure 5 This is a flowchart illustrating another Bluetooth connection method provided in an embodiment of this application. The method in this embodiment is applied to a first device, which is the connecting device, and a second device, which is the connected end device. The two devices collaboratively establish a Bluetooth link based on existing communication links such as Wi-Fi. This embodiment differs from the aforementioned... Figure 1 The illustrated embodiments correspond to each other, and the technical solution of this application is fully described from the perspectives of both the connecting party and the connected end. For example... Figure 5 As shown, the Bluetooth connection method provided in this embodiment may include:

[0129] S501, In response to establishing a communication connection with the second device, a collaborative session is established with the second device through the communication connection.

[0130] For example, once a communication connection is successfully established between the first device and the second device, the first device can use this successful connection event as a trigger to actively initiate the Bluetooth collaboration session establishment process. Similarly, the communication connection can be a Wi-Fi connection, an Ethernet connection, or other wired or wireless LAN connection. In a preferred example of this application, the communication connection is a Wi-Fi connection. Utilizing the established Wi-Fi connection to automatically trigger the establishment of the collaboration session requires no user intervention, thus establishing a reliable control channel for subsequent Bluetooth capability negotiation and information exchange.

[0131] Optionally, in one possible embodiment, when the communication connection is a WiFi connection, in response to establishing a communication connection with the second device, establishing a collaborative session with the second device through the communication connection may include:

[0132] S51. After detecting a successful WiFi connection with the second device, locate the Bluetooth collaboration service entry point of the second device through the local area network service discovery method.

[0133] S52. Send a session initialization message to the Bluetooth collaboration service entry point via WiFi connection; wherein, the session initialization message carries the local device identifier, protocol version and collaboration request type;

[0134] S53. Receive a session confirmation message returned by the second device via WiFi connection; wherein the session confirmation message carries a session identifier;

[0135] S54. Establish a temporary context for this collaborative session based on the session identifier.

[0136] For example, a WiFi connection is used to carry local area network (LAN) communication between the first and second devices. A successful WiFi connection event can manifest as a system notification after completing access authentication, obtaining a network address, or establishing a valid link. LAN service discovery methods can include mDNS, DNS-SD (Domain Name System Service Discovery), or SSDP, to resolve the Bluetooth collaboration service entry exposed by the second device within the same wireless LAN. This entry can correspond to a network address, port number, and service name, etc. Combined with... Figure 2 As shown, after a successful WiFi connection is established between the first and second devices, the first device uses this connection success event as a trigger to locate the Bluetooth collaboration service entry point of the second device via LAN service discovery and sends a session initialization message to the second device's Bluetooth collaboration service entry point through the WiFi link. This session initialization message may include the first device identifier, session request type, timestamp, random number, service scenario identifier, and authentication digest. When the second device receives the message, it verifies its validity (e.g., checking protocol version, device identifier, etc.). If valid, it returns a session confirmation message, carrying the session identifier to establish a unique identifier (Session ID) for this collaboration. Subsequently, the first device uses this session identifier as an index to create a temporary context locally to store the session state, peer device information, and subsequently exchanged Bluetooth capability data.

[0137] In this embodiment, the temporary context established based on the session identifier may include session state, peer identifier, negotiation parameters, timeout information, and cached data required for subsequent Bluetooth interactions. The session identifier is stored as a message association key in the local session management module. The temporary context can be generated by the processor in conjunction with the session table in memory. After reading the session confirmation message, the processor writes the session identifier into the temporary context and triggers subsequent collaborative processing to ensure that subsequent messages are bound to the current session. If the WiFi link is interrupted or the session times out, the temporary context can be released to prevent residual sessions from affecting subsequent connections.

[0138] This optional solution uses WiFi to carry out the cooperative session establishment process, enabling the Bluetooth cooperative entry point to be discovered and confirmed in a targeted manner. This improves the determinism and consistency of session establishment, reduces reliance on broadcast scanning and manual selection, and enhances the reliability and efficiency of cross-wireless link cooperative connections.

[0139] In another possible implementation, the first device does not need to rely on dynamic service discovery. Instead, it directly initiates session negotiation with the second device based on a pre-set second device address, the LAN address obtained from QR code parsing, session routing information shared by the application side, or the result of a direct connection establishment. A collaborative session is formed by exchanging session identifiers, random numbers, and checksums. For example, the collaborative session can be maintained using a long connection or a short connection plus a session token, as long as subsequent Bluetooth capability exchanges and Bluetooth device information transmissions are kept within the same trusted context.

[0140] In this step, to ensure the feasibility of establishing a collaborative session, the first device can also perform network status verification, target device identity pre-verification, and local service permission verification before sending the session initialization message. Network status verification may include confirming that the local IP address is valid, the second device address is routable, and network latency is within an acceptable range. Target device identity pre-verification may include comparing the second device's device number, device certificate digest, session alias, or service signature in the upper-layer services. Local service permission verification may include confirming that the current application or system service has the permission to call the Bluetooth control interface and network collaboration interface. If any verification fails, the first device suspends subsequent Bluetooth collaboration establishment and returns the failure reason to the upper layer. If the verification passes, the collaborative session enters an active state and generates a session context cache structure. The cache structure records at least the session identifier, the second device's network address, the session establishment time, a random number, an identity digest, and subsequent Bluetooth collaboration status fields.

[0141] This step establishes a collaborative session on the existing communication connection, allowing the first device to constrain capability negotiation, parameter distribution, and timing control before subsequent Bluetooth connections to the same business context. This connects the originally scattered network connections and Bluetooth connections into a continuous process, reducing the need for users to manually enter the Bluetooth settings interface to search and select, and providing a reliable front-end channel for subsequent targeted Bluetooth connections.

[0142] S502. In the collaborative session, exchange Bluetooth capability information with the second device, and after automatically enabling the local Bluetooth function according to the exchanged Bluetooth capability information, receive Bluetooth device information sent by the second device.

[0143] For example, corresponding to step S102, after the first device and the second device successfully establish a collaborative session, the first device and the second device exchange their respective Bluetooth capability information through the collaborative session. The Bluetooth capability information includes one or more of the following: whether the device supports Bluetooth, the supported Bluetooth type (Classic Bluetooth, Bluetooth Low Energy (BLE), or dual-mode), the current Bluetooth on / off status, whether the user has authorized "automatically turning on Bluetooth after a successful Wi-Fi connection," and whether the device is in airplane mode or a restricted mode such as enterprise control. For example, the first device can first send a capability query message to the second device. The capability query message contains the Bluetooth capability field template supported by the device and the target Bluetooth mode to be established. After receiving the capability query message, the second device returns a capability response message, which provides the Bluetooth modes supported by the device, the current Bluetooth status, whether automatic connection is accepted, the supported authentication methods, and whether Bluetooth device information will be sent subsequently. Simultaneously, the first device can also proactively report its own Bluetooth capability information to the second device, enabling two-way exchange.

[0144] After completing the Bluetooth capability information exchange, the first device determines whether the conditions for automatically enabling Bluetooth are met based on the capability information received from the second device and its local policy configuration. These conditions include, but are not limited to: both devices supporting Bluetooth; compatibility between the Bluetooth types supported by both devices (e.g., one supporting BLE and the other supporting dual-mode, allowing for a BLE connection); user authorization for automatic enabling; and the device not being in restricted mode. If the conditions are met and the device's Bluetooth is currently off, the first device automatically invokes the operating system's Bluetooth interface to enable Bluetooth; if Bluetooth is already enabled, it remains enabled. Simultaneously, the second device also executes its own Bluetooth enabling steps. It is important to emphasize that in this embodiment, the automatic enabling of Bluetooth by the first and second devices is performed independently, without requiring manual user intervention.

[0145] After Bluetooth is enabled on the local end, the first device receives Bluetooth device information sent by the second device through an existing cooperative session. This reception process can be initiated by the second device after it learns that Bluetooth is enabled on the first device, or it can be initiated by the first device sending a device information request to the second device, which then responds. The Bluetooth device information is used to characterize the identifiers and parameters required for the second device to be targeted for connection on the Bluetooth side, such as Bluetooth address, device type, connection mode, broadcast identifier, address type, pairing parameters, security token, service prompt information, window association identifier, and session binding digest. Among these, the Bluetooth address can be a public address, a random static address, or an identifier address mapped by the session; connection parameters can include suggested scan duration, connection interval, initial timeout parameter, target service UUID (Universally Unique Identifier), or connection priority; the security token can be a one-time random token, a session-generated digest token, or a short-term authorization code issued by the second device; the session binding digest value can be calculated jointly by the cooperative session identifier, random numbers from both parties, and the device identifier, and is used for subsequent legality verification during the Bluetooth link establishment phase.

[0146] This step, by completing capability exchange, automatically enabling Bluetooth, and receiving Bluetooth device information from the second device in the collaborative session, allows the first device to directly obtain the target parameters required for subsequent connection when it is aware of the capabilities and status of the second device. This avoids problems such as interference from devices with the same name in the traditional Bluetooth scanning list, broadcast omissions, and manual misselection. It also significantly shortens the processing link from network connection to Bluetooth connection, greatly reduces device discovery time, and improves user experience.

[0147] S503. Based on the Bluetooth device information, initiate a Bluetooth connection request to the second device within the controlled connectable window of the second device to establish a Bluetooth link.

[0148] For example, after receiving the Bluetooth device information from the second device, the first device parses out information such as the Bluetooth type, Bluetooth address, and service prompts. Simultaneously, the first device can determine that the second device has entered a controlled connectable window period (the window duration can be preset by the second device or included in the received Bluetooth device information). Optionally, the second device can synchronously send window control information to the first device during the collaborative session. This window control information includes at least the window start time, window duration, allowed connection modes, and window association identifier. In another possible implementation, the second device does not directly send an absolute time, but instead sends a window trigger message. For example, after the second device completes its local Bluetooth switch to a connectable state, it sends a "window start" notification. The first device initiates a connection request within a preset duration from the moment it receives this notification. After receiving the window control information, the first device writes it into a target connection description object and performs window calculations based on the system clock or session clock. To ensure the accuracy of the connection process, the first device can perform a secondary verification before initiating a connection request, including verifying whether the current session is still valid, whether the Bluetooth device information has not expired, whether the security token is still usable, whether the local Bluetooth status remains on, and whether the remaining window duration is sufficient to complete the connection establishment.

[0149] When initiating a connection request, the first device can directly establish a targeted connection based on the address and connection parameters in the Bluetooth device information, without first performing a global scan list display. In BLE scenarios, the first device can call the BLE host protocol stack interface and initiate a connection using the address, address type, connection parameters, and target service identifier of the second device. In classic Bluetooth scenarios, the first device can initiate a pairing request or establish a corresponding service link such as RFCOMM (Radio Frequency Communication), A2DP (Advanced Audio Distribution Profile), or HFP (Hands-Free Profile) based on the Bluetooth address and device category of the second device.

[0150] In this step, the controlled connectable window setting solves the problem of mixed connection requests and increased probability of mispairing caused by the second device being in a broadcast connectable state for a long time in traditional solutions. The first device performs targeted connection based on the Bluetooth device information sent by the second device, avoiding reliance on a large number of Bluetooth broadcasts in the environment for filtering, thereby reducing the identification uncertainty caused by devices with the same name, signal collisions, and differences in broadcast intervals in dense device scenarios. At the same time, strictly limiting connection requests to the window period allowed by the second device allows the second device to receive connection requests from the target first device in a concentrated manner after switching to a connectable state, which improves the connection success rate and shortens the connectable exposure time. Based on the above analysis, by initiating targeted connection based on Bluetooth device information within the controlled connectable window of the second device, the embodiments of this application transform the Bluetooth link establishment process into a closed-loop process of "network session establishment first, capability parameter exchange first, device information distribution first, window timing control second, and Bluetooth targeted connection later," thereby effectively solving the technical problems of relying on manual search and selection, low connection efficiency, high risk of mispairing, and insufficient connection stability in the prior art.

[0151] Optionally, in one possible embodiment, initiating a Bluetooth connection request to the second device within the controlled connectable window of the second device, based on Bluetooth device information, to establish a Bluetooth link, may include:

[0152] S510. If the Bluetooth type in the Bluetooth device information is Classic Bluetooth, then initiate a Page request to the second device based on the Bluetooth address in the Bluetooth device information to establish an ACL link.

[0153] S520. If the Bluetooth type in the Bluetooth device information is Bluetooth Low Energy (BLE), then initiate a BLE connection request to the second device based on the Bluetooth address or service prompt information in the Bluetooth device information to establish a GATT session.

[0154] For example, in a specific implementation, after receiving Bluetooth device information sent by the second device, the first device can first determine the target link standard based on the Bluetooth type, and then determine the directional connection target based on the Bluetooth address. When the Bluetooth type is Classic Bluetooth, the first device performs Page paging based on the Bluetooth address, uses the paging process of the Classic Bluetooth link layer to complete synchronization with the second device, and forms an ACL link, thereby carrying subsequent data exchange, authentication message transmission, or service control messages. When the Bluetooth type is Bluetooth Low Energy (BLE), the first device directly initiates a BLE connection request based on the Bluetooth address, or generates connection parameters matching the target service based on service prompt information, and establishes a GATT session after successful connection to complete service discovery, feature value reading and writing, and control interaction.

[0155] In this optional scheme, the controlled connectable window of the second device can be generated by a combination of its internal timer, session authorization information, or external cooperative signaling. The first device only initiates a Bluetooth connection request while the window is open, thus ensuring that the connection process is timed in accordance with the cooperative session. In the classic Bluetooth scenario, the Page request can directly page the target device address, reducing reliance on broadcast scan results. In the BLE scenario, the combined use of the Bluetooth address and service notification information can improve connection directionality and enable the first device to enter the target GATT session more quickly.

[0156] By adopting this optional implementation method, the first device can complete a targeted connection within a controlled connectable window based on Bluetooth device information, avoiding misselection and waiting time caused by traditional scanning discovery. For Classic Bluetooth, ACL link establishment is more direct; for BLE, GATT session establishment is more targeted. This can improve the success rate of Bluetooth link establishment, enhance connection compatibility under different Bluetooth types, and reduce connection interference and the need for manual intervention in complex environments.

[0157] The Bluetooth connection method provided in this embodiment connects communication connection, cooperative session, Bluetooth capability exchange, automatic Bluetooth activation, Bluetooth device information transmission, and directional Bluetooth connection within a controlled window. The first device can directly obtain the Bluetooth connection parameters of the target second device by utilizing the trusted context formed by existing Wi-Fi or other network connections and complete the link establishment under controlled timing. This reduces the dependence on Bluetooth broadcast scanning and manual selection, enabling the connecting device to complete automatic Bluetooth connection without user manual scanning and confirmation. It also improves the certainty of target device identification, the efficiency of Bluetooth connection establishment, and the connection reliability in complex environments with multiple devices.

[0158] Alternatively, in one possible embodiment, in the above... Figure 5 Based on its optional embodiments, the Bluetooth connection method provided in this application may further include:

[0159] In the collaborative session, a first verification credential sent by the second device is received; wherein, the first verification credential is carried in the Bluetooth device information;

[0160] After establishing a Bluetooth link, a second verification credential is sent to the second device via the Bluetooth link so that the second device can compare it with the first verification credential.

[0161] For example, in this embodiment, the first verification credential is used to characterize the identity association information or session binding information of the second device in the collaborative session. It can be generated in the form of a one-time random token, a session digest value, an encrypted verification string, or a link identifier value. After the second device establishes a collaborative session with the first device through a communication connection, when sending Bluetooth device information to the first device, it can also encapsulate the first verification credential in the extended fields, additional fields, or encrypted payload of the Bluetooth device information, so that the first device can synchronously receive and cache the credential when parsing the Bluetooth device information.

[0162] After the first device initiates a Bluetooth connection request based on Bluetooth device information and establishes a Bluetooth link with the second device, the first device sends a second verification credential to the second device through the established Bluetooth link. The second verification credential may consist of the original value of the first verification credential, a comparison value obtained by performing a digest operation on the first verification credential, a response value generated based on the cooperative session key, or verification data calculated based on a random challenge. Upon receiving the second verification credential, the second device compares it with the first verification credential it sent and saved in the cooperative session. If the two match, it confirms that the current Bluetooth link has the same binding relationship with the previous cooperative session and allows subsequent business communication to continue. If the comparison results are inconsistent, it determines that the link association is abnormal and terminates the current connection or triggers re-authentication.

[0163] By carrying and receiving the first verification credential during the collaborative session phase, and then sending the second verification credential for consistency verification after the Bluetooth link is established, a continuous and reliable connection can be established between the collaborative session and the Bluetooth link, reducing the risk of false and malicious connections, and improving the determinism and security of cross-link connections. The specific encoding methods, length ranges, and encryption algorithms of the first and second verification credentials can be flexibly set according to device capabilities, communication bandwidth, and security levels. In practical applications, other equivalent forms of the credentials can also be used, and this application does not limit this.

[0164] It should be noted that, Figure 5 The illustrated embodiment is the same as the one described above. Figure 1 The illustrated embodiments work together to fully describe the collaborative workflow between the connecting party and the connected end. They have advantages such as fewer operation steps, fast connection speed, strong target certainty, and high security. They are particularly suitable for application scenarios that require rapid establishment of Bluetooth connections, such as mobile phones and smart speakers, tablets and wireless headphones, and in-vehicle hosts and mobile phone screen projection.

[0165] For example, Figure 6 This is an interactive flowchart illustrating a Bluetooth connection method provided in an embodiment of this application. Figure 6 As shown, this illustrates the complete five-stage interaction process of automatically establishing a connection between the connecting party (first device) and the connected party (second device) based on Wi-Fi-triggered Bluetooth.

[0166] Phase 1 Execution: Wi-Fi Triggering and Session Establishment. Specifically, after detecting a successful Wi-Fi connection with the connected device, the connecting party proactively initiates a collaborative session: sending a Session Hello message (carrying its own device identifier, protocol version, etc.), and the connected device replies with a Session Ack (assigning a session identifier (session_id) and a random number (nonce, etc.). This phase establishes a lightweight session context for subsequent control information exchange.

[0167] The second phase involves Bluetooth capability detection and automatic activation. Specifically, both parties exchange their respective Bluetooth capability information (such as Bluetooth support, Bluetooth type, current on / off status, and user authorization policies) through an established Wi-Fi cooperative session. Subsequently, each party independently determines whether the automatic activation conditions are met based on the received Bluetooth capabilities from the other party and its local policies (e.g., both parties support Bluetooth, the user has authorized the service, and the device is not in airplane mode). If the conditions are met and the local Bluetooth is off, the system interface is automatically invoked to activate Bluetooth; otherwise, it remains on. This phase enables Bluetooth activation without manual user intervention.

[0168] The third phase involves Bluetooth device information exchange. Specifically, after Bluetooth is ready, the connected device sends a BtInfo message (Bluetooth device information) to the connecting party via the Wi-Fi channel. This message includes key parameters such as Bluetooth type (Classic Bluetooth / BLE), one-time verification token, controlled connection window duration, Bluetooth address, and service notification information. The connecting party responds with a BtInfoAck confirmation upon receiving the message. This approach utilizes the existing Wi-Fi connection to directly transmit Bluetooth information, completely replacing the traditional Bluetooth scanning and discovery process.

[0169] Phase Four: Bluetooth Connection Establishment. Specifically, after sending its own Bluetooth device information, the receiving end immediately switches its Bluetooth to a connectable state and starts a window timer (controlled window). Upon receiving the Bluetooth device information, the connecting end initiates a targeted connection within the controlled connectable window, depending on the Bluetooth type: a Page request based on the address for Classic Bluetooth, and a connection request for BLE, completing the necessary pairing and profile establishment. After the window times out, the receiving end automatically exits the connectable state, ensuring power consumption and privacy.

[0170] Phase 5: Session Binding and Verification. Specifically, after a successful Bluetooth link establishment, the connecting party sends the token (or its hash value) received in Phase 3 to the connected party via the Bluetooth link. The connected party compares this token with the token stored in the Wi-Fi session. If they match, the Bluetooth peer is confirmed as a legitimate Wi-Fi session partner, and subsequent Bluetooth services (such as audio transmission and data synchronization) are enabled; if they do not match, service is denied and the link is actively disconnected. This mechanism effectively prevents unauthorized and accidental connections from third-party devices.

[0171] based on Figure 6 The Bluetooth connection method shown in the diagram starts with a successful Wi-Fi connection and ends with the establishment of a secure and reliable Bluetooth link. The entire process does not require the user to manually turn on Bluetooth, scan for devices, or select pairing, which significantly improves the convenience, determinism, and security of multi-wireless collaboration.

[0172] Figure 7 This is a schematic diagram of a Bluetooth connection device provided in an embodiment of this application. The Bluetooth connection device provided in this embodiment is applied to a second device, which is the device being connected to, and the first device is the device connecting to it. Figure 7 As shown, the Bluetooth connection device 70 provided in this embodiment includes: a first processing unit 701, a second processing unit 702, a third processing unit 703, and a fourth processing unit 704.

[0173] The first processing unit 701 is configured to establish a collaborative session with the first device in response to establishing a communication connection with the first device.

[0174] The second processing unit 702 is used to exchange Bluetooth capability information with the first device in a collaborative session, and after automatically enabling the local Bluetooth function according to the exchanged Bluetooth capability information, send the local Bluetooth device information to the first device.

[0175] The third processing unit 703 is used to switch the local Bluetooth to a connectable state and start the controlled connectable window;

[0176] The fourth processing unit 704 is configured to establish a Bluetooth link if it receives a Bluetooth connection request initiated by the first device based on Bluetooth device information within the controlled connectable window.

[0177] In one possible implementation, the second processing unit 702 is configured to: generate a first verification credential in a collaborative session and make the Bluetooth device information sent to the first device carry the first verification credential;

[0178] The fourth processing unit 704 is also used for:

[0179] After establishing a Bluetooth link, the second verification credential sent by the first device is received via the Bluetooth link;

[0180] The first verification credential is compared with the second verification credential. If they match, the Bluetooth service capability is enabled; if they do not match, the Bluetooth service is rejected and the Bluetooth link is disconnected.

[0181] In one possible implementation, the Bluetooth capability information includes one or more of the following: whether the device supports Bluetooth, the supported Bluetooth types, the current Bluetooth on / off state, whether the user has authorized the automatic activation of Bluetooth in response to establishing a communication connection with the first device, and whether the device is in a restricted activation mode.

[0182] In one possible implementation, the second processing unit 702 is specifically used for:

[0183] Based on the exchanged Bluetooth capability information, determine whether the local end meets the automatic activation conditions; wherein, the automatic activation conditions include one or more of the following: both devices support Bluetooth, the Bluetooth types supported by both devices are compatible with each other, the user has authorized the automatic activation of Bluetooth in response to the establishment of a communication connection with the first device, and neither device is currently in an activation restricted mode.

[0184] If the automatic turn-on conditions are met and the local Bluetooth is currently off, then the local Bluetooth function will be turned on automatically.

[0185] If the automatic turn-on conditions are met and the local Bluetooth is currently on, then it will remain on.

[0186] In one possible implementation, the fourth processing unit 704 is further configured to:

[0187] The method also includes a corresponding exception handling mechanism when one of the following abnormal conditions occurs:

[0188] If automatically enabling Bluetooth on this device fails, the process will terminate, and a notification of Bluetooth enabling failure will be sent to the first device via the communication connection.

[0189] If a Bluetooth connection request is received within the controlled connectable window but the Bluetooth link establishment fails, a limited number of retries will be performed according to the backoff retry policy.

[0190] If no Bluetooth connection request is received within the controlled connectable window, the connectable state will be automatically exited after the controlled connectable window ends, and the temporary context data of this collaborative session will be cleared.

[0191] If the communication connection is interrupted during a collaborative session, the identifier and verification data of this collaborative session will be discarded immediately, and the connection will be exited.

[0192] The device provided in this embodiment can perform... Figure 1The methods provided in the method embodiments and their optional embodiments are similar in implementation principle and technical effect, and will not be described in detail here.

[0193] Figure 8 This is a schematic diagram of another Bluetooth connection device provided in an embodiment of this application. The Bluetooth connection device provided in this embodiment is applied to a first device, which is the connecting device, and the second device is the connected device, such as... Figure 8 As shown, the Bluetooth connection device 80 provided in this embodiment includes: a fifth processing unit 801, a sixth processing unit 802, and a seventh processing unit 803.

[0194] The fifth processing unit 801 is configured to establish a collaborative session with the second device in response to establishing a communication connection with the second device.

[0195] The sixth processing unit 802 is used to exchange Bluetooth capability information with the second device in a cooperative session, and after automatically enabling the local Bluetooth function according to the exchanged Bluetooth capability information, receive Bluetooth device information sent by the second device.

[0196] The seventh processing unit 803 is used to initiate a Bluetooth connection request to the second device within the controlled connectable window of the second device according to the Bluetooth device information, so as to establish a Bluetooth link.

[0197] In one possible implementation, the sixth processing unit 802 is further configured to: receive a first verification credential sent by the second device in a collaborative session; wherein the first verification credential is carried in Bluetooth device information;

[0198] The seventh processing unit 803 is further configured to: after establishing a Bluetooth link, send a second verification credential to the second device via the Bluetooth link for the second device to compare with the first verification credential.

[0199] In one possible implementation, when the communication connection includes a WiFi connection, the fifth processing unit 801 is specifically used for:

[0200] After detecting a successful WiFi connection with the second device, locate the Bluetooth collaboration service entry point of the second device through LAN service discovery.

[0201] Send a session initialization message to the Bluetooth collaboration service entry point via WiFi connection; the session initialization message carries the local device identifier, protocol version, and collaboration request type;

[0202] Receive a session confirmation message returned by the second device via WiFi connection; wherein the session confirmation message carries a session identifier;

[0203] A temporary context for this collaborative session is established based on the session identifier.

[0204] In one possible implementation, the seventh processing unit 803 is specifically used for:

[0205] If the Bluetooth type in the Bluetooth device information is Classic Bluetooth, then a Page request is sent to the second device based on the Bluetooth address in the Bluetooth device information to establish an ACL link;

[0206] If the Bluetooth type in the Bluetooth device information is Bluetooth Low Energy (BLE), then a BLE connection request is initiated to the second device based on the Bluetooth address or service prompt information in the Bluetooth device information to establish a GATT session.

[0207] The device provided in this embodiment can perform... Figure 5 The methods provided in the method embodiments and their optional embodiments are similar in implementation principle and technical effect, and will not be described in detail here.

[0208] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 9 As shown, the electronic device 90 provided in this embodiment includes at least one processor 901 and a memory 902. Optionally, the device 90 further includes a communication component 903. The processor 901, memory 902, and communication component 903 are connected via a bus 904.

[0209] In a specific implementation, at least one processor 901 executes computer execution instructions stored in memory 902, causing at least one processor 901 to perform the above-described method.

[0210] The specific implementation process of processor 901 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0211] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0212] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0213] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0214] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0215] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0216] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0217] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0218] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

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

[0220] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

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

[0222] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0223] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A Bluetooth connection method, characterized in that, Applied to a second device, which is the connected end device, and the first device is the connecting end device, the method includes: In response to establishing a communication connection with the first device, a collaborative session is established with the first device through the communication connection; In the collaborative session, Bluetooth capability information is exchanged with the first device. After automatically enabling the local Bluetooth function according to the exchanged Bluetooth capability information, the local Bluetooth device information is sent to the first device. Switch the local Bluetooth to connectable mode and start the controlled connectable window; If a Bluetooth connection request initiated by the first device based on the Bluetooth device information is received within the controlled connectable window, a Bluetooth link is established.

2. The method according to claim 1, characterized in that, The method further includes: In the collaborative session, a first verification credential is generated, and the Bluetooth device information sent to the first device carries the first verification credential. After establishing the Bluetooth link, the second verification credential sent by the first device is received through the Bluetooth link; The first verification credential is compared with the second verification credential. If they match, the Bluetooth service capability is enabled; if they do not match, the Bluetooth service is rejected and the Bluetooth link is disconnected.

3. The method according to claim 1, characterized in that, The Bluetooth capability information includes one or more of the following: whether the device supports Bluetooth, the supported Bluetooth types, the current Bluetooth on / off status, whether the user has authorized the automatic activation of Bluetooth in response to establishing a communication connection with the first device, and whether the device is in a restricted activation mode.

4. The method according to claim 3, characterized in that, The step of automatically enabling the local Bluetooth function based on the exchanged Bluetooth capability information includes: Based on the exchanged Bluetooth capability information, determine whether the local end meets the automatic activation conditions; wherein, the automatic activation conditions include one or more of the following: both devices support Bluetooth, the Bluetooth types supported by both devices are compatible with each other, the user has authorized the automatic activation of Bluetooth in response to establishing a communication connection with the first device, and neither device is currently in an activation restricted mode. If the automatic activation conditions are met and the local Bluetooth is currently off, then the local Bluetooth function will be automatically activated. If the automatic activation conditions are met and the local Bluetooth is currently enabled, then the enabled state will remain enabled.

5. The method according to any one of claims 1-4, characterized in that, The method further includes a corresponding exception handling mechanism when one of the following abnormal situations occurs: If automatically enabling local Bluetooth fails, the process is terminated, and a notification of Bluetooth enabling failure is sent to the first device via the communication connection. If a Bluetooth connection request is received within the controlled connectable window but the Bluetooth link establishment fails, a limited number of retries will be performed according to the backoff retry strategy. If the Bluetooth connection request is not received within the controlled connectable window, the connectable state will be automatically exited after the controlled connectable window ends, and the temporary context data of this collaborative session will be cleared. If the communication connection is interrupted during the collaborative session, the identifier and verification data of this collaborative session will be discarded immediately, and the connection will be exited.

6. A Bluetooth connection method, characterized in that, Applied to a first device, which is a connecting device, and a second device, which is a connected device, the method includes: In response to establishing a communication connection with the second device, a collaborative session is established with the second device through the communication connection; In the collaborative session, Bluetooth capability information is exchanged with the second device. After automatically enabling the local Bluetooth function based on the exchanged Bluetooth capability information, Bluetooth device information sent by the second device is received. Based on the Bluetooth device information, a Bluetooth connection request is initiated to the second device within the controlled connectable window of the second device to establish a Bluetooth link.

7. The method according to claim 6, characterized in that, The method further includes: In the collaborative session, a first verification credential sent by the second device is received; wherein the first verification credential is carried in the Bluetooth device information; After establishing the Bluetooth link, a second verification credential is sent to the second device through the Bluetooth link for the second device to compare with the first verification credential.

8. The method according to claim 6, characterized in that, The communication connection includes a WiFi connection, and the step of responding to establish a communication connection with the second device and establishing a collaborative session with the second device through the communication connection includes: After detecting a successful WiFi connection with the second device, the Bluetooth collaboration service entry point of the second device is located through the local area network service discovery method; Send a session initialization message to the Bluetooth collaboration service entry point via the WiFi connection; wherein, the session initialization message carries the local device identifier, protocol version, and collaboration request type; Receive a session confirmation message returned by the second device through the WiFi connection; wherein the session confirmation message carries a session identifier; A temporary context for this collaborative session is established based on the session identifier.

9. The method according to any one of claims 6-8, characterized in that, The step of initiating a Bluetooth connection request to the second device within the controlled connectable window of the second device, based on the Bluetooth device information, to establish a Bluetooth link includes: If the Bluetooth type in the Bluetooth device information is Classic Bluetooth, then a Page request is initiated to the second device based on the Bluetooth address in the Bluetooth device information to establish an ACL link; If the Bluetooth type in the Bluetooth device information is Bluetooth Low Energy (BLE), then a BLE connection request is initiated to the second device based on the Bluetooth address or service prompt information in the Bluetooth device information to establish a GATT session.

10. A Bluetooth connection device, characterized in that, Applied to a second device, which is the connected end device, and the first device is the connecting end device, the device includes: A first processing unit is configured to, in response to establishing a communication connection with the first device, establish a collaborative session with the first device through the communication connection; The second processing unit is used to exchange Bluetooth capability information with the first device in the cooperative session, and after automatically enabling the local Bluetooth function according to the exchanged Bluetooth capability information, send the local Bluetooth device information to the first device. The third processing unit is used to switch the local Bluetooth to a connectable state and start the controlled connectable window; The fourth processing unit is configured to establish a Bluetooth link if, within the controlled connectable window, it receives a Bluetooth connection request initiated by the first device based on the Bluetooth device information.

11. A Bluetooth connection device, characterized in that, Applied to a first device, which is a connecting device, and a second device, which is a connected end device, the apparatus includes: The fifth processing unit is configured to establish a collaborative session with the second device in response to establishing a communication connection with the second device; The sixth processing unit is used to exchange Bluetooth capability information with the second device in the cooperative session, and after automatically enabling the local Bluetooth function according to the exchanged Bluetooth capability information, receive Bluetooth device information sent by the second device. The seventh processing unit is configured to initiate a Bluetooth connection request to the second device within the controlled connectable window of the second device, based on the Bluetooth device information, in order to establish a Bluetooth link.

12. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-9.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-9.

Images