Bluetooth backhaul method, apparatus, device, and storage medium

Abstract

The application relates to the technical field of intelligent cockpits, and discloses a Bluetooth reconnection method and device, equipment and a storage medium, which comprises the following steps: in response to a disconnection event of a Bluetooth link, obtaining the disconnection type of the disconnection event; in the case that the disconnection type is an external device triggered disconnection, obtaining a paired device from a connection database based on the disconnection event; generating a reconnection target sequence according to the device characteristic information of the paired device; and performing a reconnection operation according to the reconnection target sequence. In the case that the disconnection type is an external device triggered disconnection, the reconnection target sequence is generated based on the device characteristic information of the paired device, so that the determination of the reconnection target can be prioritized according to the characteristic attributes of the device, the paired device with specific functional attributes can obtain corresponding reconnection priority, the connection opportunity of the paired device in the reconnection stage can be prevented from being preempted by other devices, and the accuracy of Bluetooth reconnection and the user convenience are improved.

Description

Technical Field

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

[0002] In existing in-vehicle Bluetooth backconnection solutions, the determination of backconnection targets usually relies on a single-dimensional sorting criterion, such as sorting by the most recent connection time in reverse order or by the number of connections. The device's protocol type characteristics are not included in the priority decision-making system. As a result, the hand-car interconnection devices that users expect to reconnect to first are easily preempted by classic Bluetooth devices with earlier recent connection times or more connection times, affecting the ease of operation in driving scenarios. Summary of the Invention

[0003] The main purpose of this application is to provide a Bluetooth back-connection method, apparatus, device, and storage medium, aiming to solve the technical problem that existing in-vehicle Bluetooth back-connection solutions cannot incorporate the device's protocol type into the priority decision-making system, resulting in the device with the protocol type that the user expects to connect to first having its back-connection opportunity preempted, affecting the ease of operation in driving scenarios.

[0004] Firstly, this application proposes a Bluetooth reconnection method, the Bluetooth reconnection method comprising: In response to a Bluetooth link disconnection event, obtain the disconnection type of the disconnection event; When the disconnection type is triggered by an external device, the paired device is retrieved from the connection database based on the disconnection event. The external device is a device that has completed Bluetooth pairing with the vehicle terminal. Based on the device characteristic information of the paired devices, a back-connection target sequence is generated; Perform a back-join operation based on the back-join target sequence.

[0005] In the above implementation process, by obtaining the disconnection type of the disconnection event, when the disconnection type is triggered by an external device, a reconnection target sequence is generated based on the device characteristic information of the paired device. This allows the determination of the reconnection target to be prioritized according to the characteristic attributes of the device, so that paired devices with specific functional attributes can obtain the corresponding reconnection priority, avoiding other devices from taking the connection opportunity during the reconnection phase, and improving the accuracy of Bluetooth reconnection and the convenience of user use.

[0006] In some possible implementations of the first aspect, the step of generating the backlink target sequence based on the device feature information of the paired device includes: Based on the device feature information, the protocol type features and user tag features of each paired device are determined; Select a first device from the paired devices whose protocol type characteristic is vehicle-to-vehicle interconnection protocol, and select a second device from the paired devices whose user tag characteristic is a commonly used device; A backlink target sequence is generated based on the first device and the second device, wherein the backlink priority of the first device in the backlink target sequence is greater than that of the second device.

[0007] In the above implementation process, by introducing protocol type features and user tag features as the basis for priority division, the vehicle interconnection device and the classic Bluetooth device are sorted in a hierarchical manner. This solves the problem in the traditional solution where the mixed arrangement of the two types of devices causes the vehicle interconnection device that the user expects to reconnect to first to be preempted by the classic Bluetooth device. It reduces the frequency of users manually switching in the settings page and improves the consistency between the reconnection result and the user's expectations.

[0008] In some possible implementations of the first aspect, after the step of generating the backlink target sequence based on the first device and the second device, the method further includes: If there is no first device with the protocol type characteristic of the vehicle interconnection protocol in the back-connection target sequence, a third device with the protocol type characteristic of the classic Bluetooth protocol is selected from the paired devices; The reconnection target sequence is updated according to the third device, wherein the reconnection priority of the third device in the reconnection target sequence is lower than that of the second device.

[0009] In the above implementation, when the first device is absent, a third device is selected from the paired devices based on the classic Bluetooth protocol, and the reconnection target sequence is updated. The device pool is completed through a step-by-step degradation process during the reconnection target sequence generation phase, eliminating the need for repeated database queries during the execution phase and simplifying the reconnection decision-making process. Simultaneously, the progressive selection of the three-level device pool ensures that a valid reconnection target sequence can be generated in any device combination scenario, avoiding situations where the reconnection decision is interrupted or reverts to indiscriminate scanning due to a specific priority level being empty.

[0010] In some possible implementations of the first aspect, the step of obtaining the disconnection type of the disconnection event in response to a Bluetooth link disconnection event includes: In response to a Bluetooth link disconnection event, obtain the trigger source identifier and disconnection reason of the disconnection event; The disconnection trigger information of the disconnection event is determined based on the trigger source identifier; Based on the disconnection trigger information and the disconnection reason, the disconnection type of the disconnection event is determined.

[0011] In the above implementation process, by obtaining the trigger source identifier and disconnection reason of the disconnection event, and after determining the disconnection triggering end information based on the trigger source identifier, the disconnection type is comprehensively judged. This enables the differentiation of various disconnection scenarios such as mobile phone-initiated disconnection, vehicle-initiated disconnection, signal loss, and protocol error, thus achieving accurate identification of the source of the disconnection event.

[0012] In some possible implementations of the first aspect, the step of performing the back-join operation based on the back-join target sequence includes: Obtain the target devices connected to the current Bluetooth link; If there is a device in the reconnection target sequence that has the protocol type characteristic of the vehicle interconnection protocol, and the protocol type characteristic of the target device is the classic Bluetooth protocol, then disconnect the Bluetooth link of the target device and perform a reconnection operation according to the reconnection target sequence; If there is a device in the reconnection target sequence that has the protocol type characteristic of classic Bluetooth protocol, and the protocol type characteristic of the target device is vehicle interconnection protocol, then the Bluetooth link of the target device is disconnected, and a reconnection operation is performed according to the reconnection target sequence.

[0013] In the above implementation, the protocol type of the currently connected device is detected during the reconnection operation. If a device with a mutually exclusive protocol type exists, the device is actively disconnected before reconnecting. This avoids connection failures or functional abnormalities after connection due to protocol stack resource conflicts or audio route preemption between devices of different protocol types. No manual user intervention is required, improving connection switching efficiency in multi-device scenarios.

[0014] In some possible implementations of the first aspect, the step of performing the back-join operation based on the back-join target sequence includes: Acquire Bluetooth protocol stack resources, which include the first resource state of the main Bluetooth module and the second resource state of the secondary Bluetooth module; If a fourth device with a protocol type characteristic of Bluetooth Low Energy exists in the reconnection target sequence, the target Bluetooth module is determined from the main Bluetooth module and the secondary Bluetooth module based on the first resource state and the second resource state. The target Bluetooth module initiates a reconnection request to the fourth device.

[0015] In the above implementation process, by acquiring the resource status of the primary and secondary Bluetooth modules, a suitable target Bluetooth module is selected for the fourth device using the Bluetooth Low Energy protocol to initiate a reconnection, thus achieving load balancing and resource coordination between the primary and secondary Bluetooth modules. This fully utilizes the hardware resources of the dual Bluetooth modules, improving the device capacity and connection stability of the in-vehicle Bluetooth system.

[0016] In some possible implementations of the first aspect, after the step of obtaining the disconnection type of the Bluetooth link disconnection event in response to the disconnection event, the method further includes: When the disconnection type is active disconnection by the vehicle terminal, the current state is switched to silent anti-interference state, which prohibits the vehicle terminal from initiating automatic reconnection. In response to a triggered state exit event, the current state is switched from the silent do-not-disturb state to the automatic reconnection state.

[0017] In the above implementation process, when the disconnection type is active disconnection by the vehicle end, it switches to a silent anti-interference state and disables automatic reconnection, ensuring that it only exits when the user explicitly expects to resume automatic reconnection, avoiding false reconnections caused by automatic exiting based on time thresholds. This effectively reduces unexpected connection disturbances in driving scenarios.

[0018] Secondly, this application also proposes a Bluetooth reconnection device, the Bluetooth reconnection device comprising: The type acquisition module is used to acquire the disconnection type of the Bluetooth link disconnection event in response to the disconnection event; The device matching module is used to retrieve a paired device from the connection database based on the disconnection event when the disconnection type is "internal device triggered disconnection". The external device is a device that has completed Bluetooth pairing with the vehicle terminal. The sequence output module is used to generate a back-connection target sequence based on the device feature information of the paired device; The reconnection execution module is used to perform a reconnection operation according to the reconnection target sequence.

[0019] Thirdly, this application also proposes a Bluetooth reconnection device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the Bluetooth reconnection method as described above.

[0020] Fourthly, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the Bluetooth reconnection method described above.

[0021] Regarding the beneficial effects of any of the technical solutions in the second, third, and fourth aspects mentioned above, refer to the beneficial effects of the corresponding technical solutions in the first aspect; repeated examples will not be listed here. Attached Figure Description

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

[0023] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is a flowchart illustrating a feasible embodiment of the Bluetooth reconnection method of this application; Figure 2 This is a schematic diagram illustrating the process of generating a reconnection target sequence in one feasible embodiment of the Bluetooth reconnection method of this application; Figure 3 This is a schematic diagram illustrating the process of performing the Bluetooth reconnection operation in one feasible embodiment of the Bluetooth reconnection method of this application; Figure 4 This is a schematic diagram of the module structure of the Bluetooth reconnection device according to an embodiment of this application; Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the Bluetooth reconnection method in this application embodiment.

[0025] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0026] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0027] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0028] It should be noted that the executing entity in this embodiment can be the vehicle itself, or a Bluetooth back-connection device installed in the vehicle to control the vehicle. The Bluetooth back-connection device can be a controller installed in the vehicle, such as a CDC (Central Domain Controller), or other devices that can achieve the same or similar functions. This embodiment does not limit this. In this embodiment and the following embodiments, the Bluetooth back-connection method of this embodiment is described using a CDC as an example.

[0029] Based on this, this application provides a Bluetooth reconnection method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating a feasible embodiment of the Bluetooth reconnection method of this application.

[0030] In this embodiment, the Bluetooth reconnection method includes steps S10 to S40: Step S10: In response to a Bluetooth link disconnection event, obtain the disconnection type of the disconnection event.

[0031] It should be noted that the Bluetooth link can be a wireless communication connection established between the Bluetooth master control module within the CDC and an external device via the Bluetooth protocol stack. The Bluetooth link can include a vehicle-to-everything (V2X) link, a classic Bluetooth BR / EDR link, and a Bluetooth Low Energy (BLE) link. A disconnection event can be an event reported by the Bluetooth protocol stack to the application layer connection management module when it detects a Bluetooth link interruption. For example, the Bluetooth protocol stack generates a disconnection event and reports it to the application layer connection management module when it detects a Bluetooth connection interruption with a device, or an event generated when the user actively disconnects the device's Bluetooth connection at the vehicle end.

[0032] It is understood that a disconnection event can include key parameters such as the device identifier of the disconnected device (e.g., MAC address), the disconnection trigger information, and the disconnection reason code. The disconnection type can be a classification result obtained based on the parameters of the disconnection event, used to distinguish the scenario category to which this disconnection event belongs. The disconnection type can include external device-triggered disconnection and vehicle-mounted device-initiated disconnection.

[0033] Specifically, the CDC's disconnection intent recognition module listens for disconnection events reported by the Bluetooth protocol stack. When the Bluetooth RF front-end detects a connection interruption with a device, the protocol stack encapsulates the disconnection event into structured data containing a trigger source identifier and a reason code, and reports it to the disconnection intent recognition module. The disconnection intent recognition module parses the event and obtains the disconnection type corresponding to the event.

[0034] In the specific implementation process, in order to distinguish between various disconnection scenarios such as mobile phone-initiated disconnection, vehicle-initiated disconnection, signal loss, and protocol error, the disconnection type can be determined by obtaining the trigger source identifier and disconnection reason of the disconnection event, thus achieving accurate identification of the source of the disconnection event. At this time, step S10 may include: In response to a Bluetooth link disconnection event, obtain the trigger source identifier and disconnection reason of the disconnection event; The disconnection trigger information of the disconnection event is determined based on the trigger source identifier; Based on the disconnection trigger information and the disconnection reason, the disconnection type of the disconnection event is determined.

[0035] It should be noted that the trigger source identifier can be used to indicate whether the disconnection was initiated by the vehicle-mounted unit or by an external device. The disconnection reason can be used to indicate the specific reason for the disconnection, such as active disconnection, signal loss, or protocol error.

[0036] Specifically, when the Bluetooth RF front-end detects a connection interruption with a device, the protocol stack encapsulates the disconnection event into structured data containing a trigger source identifier and a disconnection reason code, and reports it to the disconnection intent identification module. The disconnection intent identification module parses the disconnection event, extracts the trigger source identifier and disconnection reason from the event parameters, and determines the disconnection triggering end information of the disconnection event based on the trigger source identifier. Based on the disconnection triggering end information and the disconnection reason, the disconnection type of the disconnection event is determined.

[0037] In a feasible example, assume the vehicle currently has a Bluetooth connection with user A's mobile phone (device identifier MAC_001), and the phone supports both the vehicle-to-vehicle communication protocol and the classic Bluetooth protocol. When user A leaves the vehicle with the phone and the phone goes out of Bluetooth communication range, the Bluetooth RF front-end detects a link layer heartbeat timeout. The protocol stack generates a disconnection event and reports it to the disconnection intent identification module. The trigger source of this disconnection event is identified as an external device, and the disconnection reason is signal loss. After parsing the event, the disconnection intent identification module determines that the disconnection trigger is an external device and the disconnection reason is signal loss. Based on the combined information, the disconnection type is determined to be an external device-triggered disconnection.

[0038] In another feasible example, if user A actively clicks the "Disconnect Device" button through the CDC settings page in the car, the vehicle system sends a disconnect request to the mobile phone, the protocol stack generates a disconnect event and reports it, the trigger source is identified as the vehicle end, the disconnect reason is active disconnection, the disconnect intention recognition module parses and combines it with the user operation log to confirm that the disconnect event responds to the user's active operation on the vehicle end, and determines the disconnection type as active disconnection by the vehicle end.

[0039] It should be understood that when a connected device loses its signal, a signal loss protection state can be triggered. Based on the preset signal loss reconnection window, a reconnection attempt will only be made for the lost device, and other connected devices will not be disconnected in order to find the lost device.

[0040] For example, suppose the vehicle is currently connected to user A's mobile phone (device identifier MAC_001) via Bluetooth, and also connected to user B's mobile phone (MAC_002). When user A gets out of the vehicle with their phone and goes beyond the Bluetooth communication range, the Bluetooth RF front-end detects that the RSSI (Received Signal Strength Indicator) of MAC_001 remains below a preset threshold (e.g., -90dBm), and the link layer fails to receive a heartbeat response multiple times. The protocol stack determines that the signal is lost, generates a disconnection event, and reports it to the disconnection intent recognition module. The disconnection intent recognition module parses the event's trigger source identifier as an external device and the disconnection reason as signal loss, determining the disconnection type as an external device-side disconnection, and then triggers the reconnection decision process. Since the disconnection reason is signal loss, the CDC starts a 15-minute countdown for the timed reconnection window, and simultaneously initiates a reconnection attempt to MAC_001 every 30 seconds via the Bluetooth protocol stack. During this period, User B uses their mobile phone (MAC_002) to make or receive calls via Bluetooth. The CDC, through the audio channel control module, recognizes that MAC_002 is occupying the phone's audio channel. Therefore, it maintains the Bluetooth link and audio channel of MAC_002 unchanged, while the reconnection attempt to MAC_001 is executed independently in the background without interference. Thus, User B's call will not be interrupted by the system searching for User A's mobile phone. If User A returns to the vicinity of the vehicle with their mobile phone at the 5-minute countdown, the Bluetooth RF front-end detects that MAC_001's RSSI has recovered above the threshold. The protocol stack receives the broadcast signal from this device, and the CDC immediately stops the countdown and prioritizes establishing a Bluetooth connection with MAC_001. The PHUD (Panoramic Head-Up Display) simultaneously refreshes and displays "User A's mobile phone has reconnected." At this time, the vehicle is simultaneously connected to both MAC_001 and MAC_002. If MAC_001 fails to reconnect after the 15-minute countdown, CDC will abandon the automatic reconnection to that device, clear the reconnection task queue, and the PHUD will display "User A's phone reconnection timed out, please connect manually," requiring the user to manually initiate the connection later. If the user manually connects a third device (MAC_003) to the vehicle system during the countdown, and only MAC_002 is currently connected (with one Bluetooth slot available), CDC will continue to attempt to reconnect to MAC_001. If two devices (MAC_002 and MAC_003) are already connected, CDC will terminate the reconnection attempt to MAC_001 according to the preset rule that if one device disconnects within a power-on cycle, it will not actively reconnect to other classic Bluetooth devices, ensuring that the normal use of other devices is not interrupted during the reconnection process.

[0041] Step S20: In the case where the disconnection type is triggered by an external device, a paired device is obtained from the connection database based on the disconnection event. The external device is a device that has completed Bluetooth pairing with the vehicle terminal.

[0042] It should be noted that the connection database is a local storage unit within the CDC, used to store record information of all external devices that have completed Bluetooth pairing with the vehicle. These external devices are those that have completed Bluetooth pairing with the vehicle's onboard unit. Each pairing device record includes at least a device identifier, protocol type characteristics, user tag characteristics, and a recent connection timestamp. The protocol type characteristics distinguish whether the device supports the vehicle-to-everything (V2X) protocol or the classic Bluetooth protocol, and the user tag characteristics indicate whether the device has been marked as a frequently used device by the user.

[0043] It is understandable that when the disconnection type is triggered by an external device, it proves that the user did not actively disconnect on the vehicle side. In this case, the paired device can be retrieved from the connection database based on the disconnection event, and the reconnection process can be automatically triggered to provide convenience to the user.

[0044] Retrieving a paired device from the connection database based on a disconnection event can be done by retrieving the device identifier carried in the disconnection event, querying and extracting paired device records related to the disconnected device from the connection database, and constructing a set of candidate devices for subsequent reconnection decisions based on historical connection records in the database.

[0045] For example, after determining that the disconnection type is an external device disconnection, the CDC disconnection intent identification module can pass the device identifier in the disconnection event to the connection database module. The connection database module uses the device identifier (e.g., MAC_001) as the primary key to perform a query and obtain complete records such as the protocol type characteristics, user tag characteristics, and most recent connection timestamp of user A's mobile phone as the first candidate device. At the same time, the connection database module can also traverse historical connection records to find other paired devices with the same user account identifier as MAC_001 (e.g., the same user's tablet MAC_002), and record these devices as the second candidate devices. Finally, the first and second candidate devices are merged into a candidate device set.

[0046] In the specific implementation process, to ensure that the Bluetooth device only reconnects when the user explicitly expects automatic reconnection, avoiding false reconnections caused by automatic exit based on time thresholds, and reducing unexpected connection disturbances in driving scenarios, a silent anti-interference state can be switched and automatic reconnection disabled when the disconnection type is "vehicle-side active disconnection". In this case, after the step of obtaining the disconnection type of the Bluetooth link disconnection event, the method further includes: When the disconnection type is active disconnection by the vehicle terminal, the current state is switched to silent anti-interference state, which prohibits the vehicle terminal from initiating automatic reconnection. In response to a triggered state exit event, the current state is switched from the silent do-not-disturb state to the automatic reconnection state.

[0047] It should be noted that when the disconnection type is active disconnection by the vehicle, it proves that the user does not need to make a Bluetooth connection. In this case, in order to satisfy the user's intention, all automatic reconnection behavior can be terminated and no connection request can be initiated for any pairing device.

[0048] In this embodiment, the CDC can have three states: active reconnection state, which allows automatic reconnection based on a priority tree; silent anti-interference state, which terminates all automatic reconnection behavior and does not initiate connection requests to any historically paired devices; and signal loss protection state, which activates a timed reconnection window for scenarios where the connected device loses its signal. When the disconnection type is active disconnection by the vehicle-mounted device, the current state can be switched to silent anti-interference state to prevent the vehicle-mounted device from initiating automatic reconnection.

[0049] Understandably, the status exit event of the silent do-not-disturb mode is used to trigger the system to return from the silent do-not-disturb state to the active reconnection state. The status exit event can be at least one of the following: user-initiated new connection, system restart, or Bluetooth master switch state toggling, to avoid automatic exit based on time thresholds that could lead to accidental reconnection.

[0050] For example, when a user manually disconnects "Phone A" in the vehicle settings, the silent state machine management module switches the system state from active reconnection to silent do-not-disturb state. Afterward, even if the phone's Bluetooth signal reappears near the vehicle, the CDC will not automatically initiate a reconnection request. If the user subsequently manually clicks "Connect Phone A" in the vehicle Bluetooth settings, the system detects a state exit event, triggers a new connection operation, sends the state exit event to the silent state machine management module, switches back from silent do-not-disturb state to active reconnection state, and initiates a connection request to the designated device.

[0051] Understandably, when switching to the silent do-not-disturb state, the silent state machine management module also performs the following operations simultaneously: clears all pending reconnection requests in the reconnection task queue; sends a silent mode enable command to the PHUD state rendering module so that the PHUD can synchronously refresh the Bluetooth icon status (such as displaying the Bluetooth icon and the "disconnected" status text, without displaying the animation prompt during reconnection); and sends the state switching record to the data tracking module, which encapsulates the record into structured data and asynchronously reports it to the TSP (Telematics Service Provider, cloud data platform) through the vehicle network channel.

[0052] Step S30: Generate a back-connection target sequence based on the device feature information of the paired device.

[0053] It should be noted that the device characteristic information of the paired device can be the characteristic data of the paired device stored in the connection database, including at least the protocol type characteristic and the user tag characteristic. The protocol type characteristic is used to distinguish whether the device supports car-to-vehicle connectivity protocols (such as CarPlay, HiCar, Carlink) or the classic Bluetooth protocol. The user tag characteristic is used to identify whether the device has been marked as a "frequently used device" by the user, which can reflect the user's subjective usage preferences.

[0054] Understandably, based on the device characteristic information of the selected paired devices, a reconnection target sequence can be generated by the priority decision engine to guide the Bluetooth protocol stack to initiate reconnection attempts sequentially. This reconnection target sequence is generated after sorting candidate devices according to a preset multi-level priority rule. The order of the devices in the reconnection target sequence determines the order of the reconnection attempts; devices ranked higher receive a higher priority for reconnection.

[0055] For example, when the candidate device set includes user A's mobile phone (supports CarPlay and is marked as a frequently used device), user B's mobile phone (supports only Classic Bluetooth and is marked as a frequently used device), and user C's mobile phone (supports only Classic Bluetooth and is not marked), the priority decision engine sorts them comprehensively based on protocol type characteristics and user marking characteristics, and the generated back-connection target sequence is user A's mobile phone, user B's mobile phone, and user C's mobile phone in that order.

[0056] It should be understood that after generating the reconnection target sequence, the priority decision engine sends the sequence to the Bluetooth protocol stack, which then attempts to establish Bluetooth connections sequentially according to the sequence order.

[0057] Understandably, if the candidate device set is empty, or if all candidate devices are unavailable for automatic reconnection due to protocol mutual exclusion or silent anti-interference status restrictions, the priority decision engine will generate an empty sequence, the CDC will output a prompt message indicating that there are no devices available for reconnection, and will notify the PHUD to refresh the display status, prompting the user to manually connect the device.

[0058] Step S40: Perform a back-connection operation according to the back-connection target sequence.

[0059] It is understandable that after obtaining the backlink target sequence, backlink operations can be performed sequentially based on the candidate devices in the backlink target sequence.

[0060] It should be understood that, due to the mutual exclusion between the vehicle interconnection device and the classic Bluetooth device, the classic Bluetooth needs to be automatically disconnected after the vehicle interconnection connection is established; if it is necessary to reconnect to the classic Bluetooth, the vehicle interconnection must be disconnected first. Therefore, when performing the reconnection operation, it is necessary to dynamically handle the disconnection of the mutually exclusive device and the release of audio resources according to the current Bluetooth link connection status and the protocol type of the device to be reconnected.

[0061] In one example, when the first phone in the reconnection target sequence is a CarPlay-enabled user A phone, and the vehicle is already connected to a classic Bluetooth phone belonging to user B, the Bluetooth link of user B phone must be disconnected first and the audio channel resources it occupies must be released. Then, a reconnection request is sent to user A phone. After user A phone successfully establishes a connection, the corresponding audio channel is enabled according to the default configuration policy of the audio channel.

[0062] In another example, if one device disconnects during a power-on cycle (whether intentionally or due to signal loss), CDC will no longer actively connect to other classic Bluetooth devices. This limitation prevents the system from automatically preemptively connecting to device B after device A disconnects in a dual-phone scenario. A maximum of two phones can maintain a Bluetooth connection simultaneously. When two phones are connected, call audio follows the rule of priority access to the car's speaker and microphone for the first phone to use; subsequent calls are automatically switched to the phone's local audio playback. Media audio follows the principle of allowing only one phone to play at a time, adhering to a "first-come, first-served" rule. If playback is interrupted by another call, media playback resumes after the call ends.

[0063] In another example, after a successful reconnection or when the user connects via Bluetooth, CDC defaults to enabling only the telephone audio channel. The media audio channel needs to be manually switched in the Bluetooth music interface; clicking the device will automatically enable and play the audio. After changing the audio channel settings, CDC completes the switch within a 30-second time limit, locking other operations during the process. If the timeout or failure occurs, it will display "Switching failed, please try again" and return to the original state.

[0064] In this embodiment, when the disconnection type is triggered by an external device, a reconnection target sequence is generated based on the device feature information of the paired device. This allows the determination of reconnection targets to be prioritized according to the feature attributes of the devices. Paired devices with specific functional attributes can obtain the corresponding reconnection priority, avoiding other devices from taking the connection opportunity during the reconnection phase, thereby improving the accuracy of Bluetooth reconnection and the convenience of user use.

[0065] In one feasible embodiment of this application, content that is the same as or similar to the above embodiments can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 , Figure 2 This is a schematic diagram illustrating the process of generating a reconnection target sequence in one embodiment of the Bluetooth reconnection method of this application.

[0066] In this embodiment, step S30 may include steps S301 to S303: Step S301: Determine the protocol type characteristics and user tag characteristics of each paired device based on the device characteristic information.

[0067] It is understood that, based on the device feature information, determining the protocol type features and user tag features of each paired device can be achieved by the priority decision engine reading the complete device feature information of each device in the candidate device set from the connection database, and extracting the protocol type field value and user tag field value from it as the basis for priority ranking.

[0068] For example, in the database, the device feature information of device A records a protocol type field with the value "CarPlay" (vehicle-to-vehicle interconnection protocol type) and a user tag field with the value "Yes" (common device tag). The device feature information of device B includes a protocol type field with the value "BR / EDR" (classic Bluetooth protocol type) and a user tag field with the value "No" (uncommon device). After reading these two records, the priority decision engine determines that the protocol type feature of device A is the vehicle-to-vehicle interconnection protocol type and the user tag feature is that it has the common device tag, while the protocol type feature of device B is the classic Bluetooth protocol type and the user tag feature is that it does not have the common device tag.

[0069] Step S302: Select a first device from the paired devices whose protocol type characteristic is vehicle-to-vehicle interconnection protocol, and select a second device from the paired devices whose user tag characteristic is commonly used device.

[0070] It should be noted that the first device is a paired device whose protocol type characteristic is a car-to-vehicle interconnection protocol type (such as CarPlay, HiCar, Carlink). The second device is a paired device whose user identification characteristic is a commonly used device identifier.

[0071] Understandably, devices using the vehicle connectivity protocol have the highest priority in reconnection decisions because once connected, they can provide a deep vehicle connectivity experience including navigation, music, and calls. If classic Bluetooth devices take over the connection resources, users will have to switch manually, which affects driving safety and ease of use.

[0072] User tagging features reflect users' subjective usage preferences. When there are no handcart interconnection devices available for reconnection, classic Bluetooth devices that users have tagged as frequently used devices can get a reconnection opportunity before other untagged classic Bluetooth devices.

[0073] For example, if the candidate device set contains four devices: Device A has the protocol type characteristic of CarPlay and the user tag characteristic of having a common device tag; Device B has the protocol type characteristic of HiCar and the user tag characteristic of not having a common device tag; Device C has the protocol type characteristic of BR / EDR Classic Bluetooth and the user tag characteristic of having a common device tag; Device D has the protocol type characteristic of BR / EDR Classic Bluetooth and the user tag characteristic of not having a common device tag. The priority decision engine filters based on the protocol type characteristic, selecting Device A and Device B as the first device, and filters from the remaining devices based on the user tag characteristic, selecting Device C as the second device.

[0074] Step S303: Generate a back-connection target sequence based on the first device and the second device, wherein the back-connection priority of the first device in the back-connection target sequence is greater than that of the second device.

[0075] Specifically, the priority decision engine can be controlled to merge the first device and the second device according to their hierarchical order to generate a back-connection target sequence. The first device is arranged at the beginning of the sequence, the second device is arranged at the end of the sequence, and devices within the same level are further sorted according to time characteristics (such as the reverse order of the most recent connection timestamp).

[0076] In the specific implementation process, when the first device is absent, a third device with the protocol type characteristic of classic Bluetooth can be selected from the paired devices, and the reconnection target sequence can be updated. The device pool is completed through a step-by-step degradation during the reconnection target sequence generation stage, eliminating the need for repeated database queries during the execution stage and simplifying the reconnection decision process. Simultaneously, the progressive selection of the three-level device pool ensures that a valid reconnection target sequence can be generated in any device combination scenario, avoiding situations where the reconnection decision is interrupted or reverts to indiscriminate scanning due to a specific priority level being empty. At this point, after step S303, the process further includes: If there is no first device with the protocol type characteristic of the vehicle interconnection protocol in the back-connection target sequence, a third device with the protocol type characteristic of the classic Bluetooth protocol is selected from the paired devices; The reconnection target sequence is updated according to the third device, wherein the reconnection priority of the third device in the reconnection target sequence is lower than that of the second device.

[0077] It should be noted that if there is no first device in the reconnection target sequence (i.e., there is currently no device of the vehicle-to-vehicle interconnection protocol type available for reconnection), the priority decision engine can select a third device with the classic Bluetooth protocol type from the paired devices.

[0078] The third device has the lowest priority in the three-level priority system, and its reconnection order is second only to the second device. If the first device is not present in the reconnection target sequence, the third device can be selected to update the reconnection target sequence.

[0079] For example, when the first device (vehicle-to-vehicle interconnection device) is not present in the reconnection target sequence, the engine selects device C (BR / EDR, marked as "No" by the user, with the most recent connection time being 9:00 AM on the same day) and device D (BR / EDR, marked as "No" by the user, with the most recent connection time being 8:30 AM on the same day) from the candidate device set based on the classic Bluetooth protocol. After arranging device C and device D in reverse chronological order, they are appended to the second device sequence. The updated reconnection target sequence is then the second device, the third device C, and the third device D.

[0080] In this embodiment, by introducing protocol type features and user tag features as priority classification criteria, the vehicle interconnection device and the classic Bluetooth device are sorted in a hierarchical manner. This solves the problem in the traditional solution where the mixed arrangement of the two types of devices causes the vehicle interconnection device that the user expects to reconnect to first to be preempted by the classic Bluetooth device. This reduces the frequency of users manually switching in the settings page and improves the consistency between the reconnection result and the user's expectations.

[0081] In one feasible embodiment of this application, content that is the same as or similar to the above embodiments can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 , Figure 3 This is a flowchart illustrating the execution of the Bluetooth reconnection operation in one embodiment of the feasible Bluetooth reconnection method of this application.

[0082] In this embodiment, step S40 may include steps S401 to S403: Step S401: Obtain the target device connected to the current Bluetooth link.

[0083] The target device is an external device that has already established a Bluetooth link with the vehicle-mounted terminal, such as a mobile phone, tablet, or smart wearable device. The vehicle-mounted terminal can obtain information such as the target device's device identifier, MAC address, device name, connection status, protocol type characteristics, and user tag characteristics through the Bluetooth protocol stack, connection management module, connection database, or link status query interface.

[0084] Step S402: If there is a device in the reconnection target sequence with the protocol type characteristic of the vehicle interconnection protocol, and the protocol type characteristic of the target device is the classic Bluetooth protocol, then disconnect the Bluetooth link of the target device and perform a reconnection operation according to the reconnection target sequence.

[0085] It should be noted that there is a mutual exclusion relationship between the vehicle-to-everything (V2X) device and the classic Bluetooth device. Once the V2X connection is established, the classic Bluetooth connection needs to be automatically disconnected. If you need to reconnect to the classic Bluetooth connection, you must first disconnect the V2X connection. Therefore, if there is a device with the V2X protocol in the reconnection target sequence, and if there is already a target device with the classic Bluetooth protocol connected to the current Bluetooth link, you must first disconnect the link of the classic Bluetooth device before performing the reconnection operation.

[0086] For example, if the first device in the reconnection target sequence is user A's mobile phone, which supports CarPlay and is a first-priority device, and the vehicle is currently maintaining a Bluetooth connection with user B's mobile phone (which only supports the classic Bluetooth protocol), since vehicle-to-vehicle connectivity and classic Bluetooth cannot coexist, the Bluetooth link of user B's mobile phone must be disconnected first before a reconnection request is sent to user A's mobile phone.

[0087] In an optional implementation, while disconnecting the Bluetooth link of the classic Bluetooth device, the audio channel control module also performs the following operations: obtains information on the audio channel resources currently occupied by the classic Bluetooth device, including the occupancy status of the telephone audio channel and the media audio channel; releases all audio channel resources occupied by the classic Bluetooth device and switches the audio channels to an idle state. After disconnecting the classic Bluetooth device and releasing its occupied audio channel resources, the Bluetooth protocol stack initiates a Bluetooth reconnection request based on the vehicle-to-everything (V2X) devices in the reconnection target sequence. For example, if user B's mobile phone is currently using the telephone audio channel for a call, the telephone audio channel resources are released while disconnecting user B's mobile phone link. Once user A's mobile phone successfully establishes a connection, the telephone audio channel can be used by user A's mobile phone.

[0088] Understandably, if there are no devices with the classic Bluetooth protocol among the currently connected devices, such as no Bluetooth devices currently connected, or the currently connected device is a Bluetooth Low Energy device rather than a classic Bluetooth device, then there is no need to perform a disconnect operation, and a reconnection request will be initiated directly based on the handcart interconnection devices in the reconnection target sequence.

[0089] Step S402: If there is a device with the protocol type characteristic of classic Bluetooth protocol in the reconnection target sequence, and the protocol type characteristic of the target device is vehicle-to-everything (V2X) protocol, then disconnect the Bluetooth link of the target device and perform a reconnection operation according to the reconnection target sequence.

[0090] It should be noted that there is a mutual exclusion relationship between the vehicle-to-everything (V2X) device and the classic Bluetooth device. Once the V2X connection is established, the classic Bluetooth connection automatically disconnects; to reconnect to the classic Bluetooth, the V2X connection must be disconnected first. Therefore, if a device with the classic Bluetooth protocol is present in the reconnection target sequence, and a V2X target device is already connected to the current Bluetooth link, the V2X link must be disconnected before performing the reconnection operation to the classic Bluetooth device.

[0091] For example, if the first device in the reconnection target sequence is user A's mobile phone, which only supports the classic Bluetooth protocol and is a second or third priority device, and the vehicle is currently maintaining a Bluetooth connection with user B's mobile phone (which supports CarPlay and belongs to the vehicle-to-grid protocol type), since vehicle-to-grid and classic Bluetooth cannot coexist, the Bluetooth link of user B's mobile phone must be disconnected first before a reconnection request is sent to user A's mobile phone.

[0092] In the specific implementation process, in order to fully utilize the hardware resources of the dual Bluetooth modules and improve the device capacity and connection stability of the vehicle Bluetooth system, the resource status of the primary and secondary Bluetooth modules is obtained. Furthermore, by obtaining the resource status of the primary and secondary Bluetooth modules, a suitable target Bluetooth module can be selected for the Bluetooth Low Energy protocol to initiate a reconnection. In this case, step S40 may further include: Acquire Bluetooth protocol stack resources, which include the first resource state of the main Bluetooth module and the second resource state of the secondary Bluetooth module; If a fourth device with a protocol type characteristic of Bluetooth Low Energy exists in the reconnection target sequence, the target Bluetooth module is determined from the main Bluetooth module and the secondary Bluetooth module based on the first resource state and the second resource state. The target Bluetooth module initiates a reconnection request to the fourth device.

[0093] It should be noted that the Bluetooth protocol stack resources are the hardware and protocol stack resources within the CDC used to process Bluetooth connection requests. In this embodiment, the Bluetooth protocol stack resources may include the first resource state of the main Bluetooth module and the second resource state of the secondary Bluetooth module.

[0094] The primary Bluetooth module is the main Bluetooth controller within the CDC, responsible for managing connections between Classic Bluetooth (BR / EDR) and Bluetooth Low Energy (BLE) devices. The secondary Bluetooth module is an auxiliary Bluetooth controller activated when the vehicle is equipped with a rear-seat screen, responsible for connecting BLE-overloaded devices and rear-seat Bluetooth headsets. The first resource status indicates the current resource usage of the primary Bluetooth module, including the number of connected Classic Bluetooth devices, the number of connected BLE devices, and remaining connectable capacity. The second resource status indicates the current resource usage of the secondary Bluetooth module, including the number of connected BLE devices and remaining connectable capacity.

[0095] Understandably, the Bluetooth Low Energy (BLE) protocol is used to identify devices that support BLE connectivity (such as fragrance diffusers, smart child seats, magnetic haptic buttons, etc.) and Bluetooth headsets. The fourth device can be a device in the reconnection target sequence whose protocol type characteristic is BLE or Bluetooth headset protocol. The target Bluetooth module is selected from the primary and secondary Bluetooth modules to perform the fourth device reconnection operation.

[0096] For example, when the reconnection target sequence includes a smart child seat (BLE device), the first resource status of the primary Bluetooth module and the second resource status of the secondary Bluetooth module can be obtained. If the primary Bluetooth module is currently connected to 2 mobile phones and 4 BLE devices, with 1 BLE device remaining, and the secondary Bluetooth module is currently connected to 3 BLE devices, with 2 BLE devices remaining, the primary Bluetooth module is selected as the target Bluetooth module to initiate a reconnection request to the smart child seat based on the resource status. If the primary Bluetooth module is currently connected to 2 mobile phones and 5 BLE devices, reaching the BLE limit, and the secondary Bluetooth module is currently connected to 2 BLE devices, with 3 BLE devices remaining, the secondary Bluetooth module is selected as the target Bluetooth module based on the resource status.

[0097] In a feasible example, the maximum number of primary Bluetooth module (BLE) connections is: 2 phones + 5 BLEs, or 0-1 phones + 8 BLEs. Once the primary Bluetooth module has 5 BLEs, new BLE devices automatically connect to the secondary Bluetooth module. When the secondary Bluetooth module reaches its limit, new BLEs reconnect to the primary Bluetooth module. When the primary Bluetooth module has 9 BLEs, new BLE devices are denied access. Meanwhile, Bluetooth headsets can only connect when the vehicle is equipped with a rear-seat screen, supporting 0-2 pairs of simultaneous connections, using an independent data channel, and not occupying the telephone / media audio channel.

[0098] In this embodiment, the protocol type of the currently connected device is detected during the reconnection operation. If a device with a mutually exclusive protocol type exists, the device is actively disconnected before reconnecting. This avoids connection failures or functional abnormalities after connection due to protocol stack resource conflicts or audio route preemption between devices of different protocol types. No manual user intervention is required, improving connection switching efficiency in multi-device scenarios.

[0099] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the Bluetooth reconnection method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0100] This application also provides a Bluetooth reconnection device, please refer to... Figure 4 The Bluetooth reconnection device includes: The type acquisition module 10 is used to acquire the disconnection type of the Bluetooth link disconnection event in response to the disconnection event; Device matching module 20 is used to obtain a paired device from the connection database based on the disconnection event when the disconnection type is external device triggered disconnection, wherein the external device is a device that has completed Bluetooth pairing with the vehicle terminal; The sequence output module 30 is used to generate a back-connection target sequence based on the device feature information of the paired device; The reconnection execution module 40 is used to perform a reconnection operation according to the reconnection target sequence. The Bluetooth backconnection device provided in this application, employing the Bluetooth backconnection method in the above embodiments, can solve the technical problem that existing in-vehicle Bluetooth backconnection solutions cannot incorporate the device's protocol type into the priority decision-making system, resulting in devices with the protocol type that users expect to reconnect to being preempted, thus affecting operational convenience in driving scenarios. Compared with the prior art, the beneficial effects of the Bluetooth backconnection device provided in this application are the same as those of the Bluetooth backconnection method provided in the above embodiments, and other technical features in the Bluetooth backconnection device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0101] This application provides a Bluetooth back-connection device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the Bluetooth back-connection method in Embodiment 1 above.

[0102] The following is for reference. Figure 5The diagram illustrates a structure suitable for implementing a Bluetooth back-connection device according to embodiments of this application. The Bluetooth back-connection device in these embodiments may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The Bluetooth backlink device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0103] like Figure 5 As shown, the Bluetooth back-connect device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in the read-only memory 1002 or a program loaded from the storage device 1003 into the random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the Bluetooth back-connect device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows Bluetooth backlink devices to communicate wirelessly or wiredly with other devices to exchange data. While various Bluetooth backlink devices with different systems are shown in the figures, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0104] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0105] The Bluetooth backconnection device provided in this application, employing the Bluetooth backconnection method described in the above embodiments, solves the technical problem that existing in-vehicle Bluetooth backconnection solutions cannot incorporate device protocol types into the priority decision-making system, resulting in devices with protocol types that users expect to reconnect to being preempted, thus affecting operational convenience in driving scenarios. Compared with the prior art, the beneficial effects of the Bluetooth backconnection device provided in this application are the same as those of the Bluetooth backconnection method provided in the above embodiments, and other technical features of this Bluetooth backconnection device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0106] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0107] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0108] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the Bluetooth reconnection method in the above embodiments.

[0109] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0110] The aforementioned computer-readable storage medium may be included in the Bluetooth backconnect device; or it may exist independently and not assembled into the Bluetooth backconnect device.

[0111] The aforementioned computer-readable storage medium carries one or more programs that, when executed by a Bluetooth back-connection device, cause the Bluetooth back-connection device to perform the Bluetooth back-connection method described above.

[0112] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0113] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0114] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0115] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described Bluetooth reconnection method. This solves the technical problem that existing in-vehicle Bluetooth reconnection solutions cannot incorporate device protocol types into their priority decision-making system, leading to devices with protocol types that users expect to reconnect to being preempted, thus affecting operational convenience in driving scenarios. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the Bluetooth reconnection method provided in the above embodiments, and will not be repeated here.

[0116] The above description is only a part of the embodiments of this application and does not limit the scope of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included within the protection scope of this application.

[0117] It should be noted that the data collection, tag management, rule setting, and push decision-making processes involved in this application are designed to work with other technical features to solve technical problems. They do not involve or support any illegal activities. Any data processing that may violate laws and regulations (such as unauthorized collection of privacy data, generation of discriminatory tags, setting unfair rules, or pushing illegal information) is not within the scope of protection of this application's technical solution. Of course, the user data in this application will be encrypted, anonymized, or de-identified before storage to ensure user data security.

Claims

1. A Bluetooth reconnection method, characterized in that, The Bluetooth reconnection method includes: In response to a Bluetooth link disconnection event, obtain the disconnection type of the disconnection event; When the disconnection type is external device triggered disconnection, the paired device is obtained from the connection database based on the disconnection event. The external device is a device that has completed Bluetooth pairing with the vehicle terminal. Based on the device characteristic information of the paired devices, a back-connection target sequence is generated; Perform a back-join operation based on the back-join target sequence.

2. The Bluetooth reconnection method as described in claim 1, characterized in that, The step of generating the back-connection target sequence based on the device feature information of the paired device includes: Based on the device feature information, the protocol type features and user tag features of each paired device are determined; Select a first device from the paired devices whose protocol type characteristic is vehicle-to-vehicle interconnection protocol, and select a second device from the paired devices whose user tag characteristic is a commonly used device; A backlink target sequence is generated based on the first device and the second device, wherein the backlink priority of the first device in the backlink target sequence is greater than that of the second device.

3. The Bluetooth reconnection method as described in claim 2, characterized in that, After the step of generating the backlink target sequence based on the first device and the second device, the method further includes: If there is no first device with the protocol type characteristic of the vehicle interconnection protocol in the back-connection target sequence, a third device with the protocol type characteristic of the classic Bluetooth protocol is selected from the paired devices; The reconnection target sequence is updated according to the third device, wherein the reconnection priority of the third device in the reconnection target sequence is lower than that of the second device.

4. The Bluetooth reconnection method as described in claim 1, characterized in that, The step of obtaining the disconnection type of the Bluetooth link disconnection event in response to the disconnection event includes: In response to a Bluetooth link disconnection event, obtain the trigger source identifier and disconnection reason of the disconnection event; The disconnection trigger information of the disconnection event is determined based on the trigger source identifier; Based on the disconnection trigger information and the disconnection reason, the disconnection type of the disconnection event is determined.

5. The Bluetooth reconnection method as described in any one of claims 1 to 4, characterized in that, The step of performing a back-join operation based on the back-join target sequence includes: Obtain the target devices connected to the current Bluetooth link; If there is a device in the reconnection target sequence that has the protocol type characteristic of the vehicle interconnection protocol, and the protocol type characteristic of the target device is the classic Bluetooth protocol, then disconnect the Bluetooth link of the target device and perform a reconnection operation according to the reconnection target sequence; If there is a device in the reconnection target sequence that has the protocol type characteristic of classic Bluetooth protocol, and the protocol type characteristic of the target device is vehicle interconnection protocol, then the Bluetooth link of the target device is disconnected, and a reconnection operation is performed according to the reconnection target sequence.

6. The Bluetooth reconnection method as described in any one of claims 1 to 4, characterized in that, The step of performing a back-join operation based on the back-join target sequence includes: Acquire Bluetooth protocol stack resources, which include the first resource state of the main Bluetooth module and the second resource state of the secondary Bluetooth module; If a fourth device with a protocol type characteristic of Bluetooth Low Energy exists in the reconnection target sequence, the target Bluetooth module is determined from the main Bluetooth module and the secondary Bluetooth module based on the first resource state and the second resource state. The target Bluetooth module initiates a reconnection request to the fourth device.

7. The Bluetooth reconnection method as described in any one of claims 1 to 4, characterized in that, After the step of obtaining the disconnection type of the Bluetooth link disconnection event in response to the Bluetooth link disconnection event, the method further includes: When the disconnection type is active disconnection by the vehicle terminal, the current state is switched to silent anti-interference state, which prohibits the vehicle terminal from initiating automatic reconnection. In response to a triggered state exit event, the current state is switched from the silent do-not-disturb state to the automatic reconnection state.

8. A Bluetooth reconnection device, characterized in that, The device includes: The type acquisition module is used to acquire the disconnection type of the Bluetooth link disconnection event in response to the disconnection event; The device matching module is used to retrieve a paired device from the connection database based on the disconnection event when the disconnection type is "internal device triggered disconnection". The external device is a device that has completed Bluetooth pairing with the vehicle terminal. The sequence output module is used to generate a back-connection target sequence based on the device feature information of the paired device; The reconnection execution module is used to perform a reconnection operation according to the reconnection target sequence.

9. A Bluetooth reconnection device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the Bluetooth reconnection method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the Bluetooth reconnection method as described in any one of claims 1 to 7.

Images