A communication method, electronic device and storage medium

By implementing a communication method in electronic devices, the problem that the user cannot send out voice calls when making voice calls through Bluetooth headphones is solved, the success rate of SCO link creation is improved, the smooth progress of voice calls is ensured and the user experience is improved.

CN118118876BActive Publication Date: 2025-03-14HONOR DEVICE CO LTD
View PDF 12 Cites 0 Cited by

Patent Information

Application Number
CN202410238644.8
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2024-02-29
Publication Date
2025-03-14
Estimated Expiration
2044-02-29

AI Technical Summary

Technical Problem

When a user makes a voice call through a Bluetooth headset, the sound cannot be transmitted through the Bluetooth headset, but is played through the mobile phone, resulting in a reduced user experience.

Method used

By implementing a communication method in the electronic device, a service-level connection with the Bluetooth calling device is established, and when there is a voice call requirement, if the preset conditions are not met, a first command is sent to the Bluetooth calling device to request the use of a specific encoding method, thereby increasing the success rate of SCO link creation.

Benefits of technology

Ensure that electronic devices can successfully make voice calls through Bluetooth calling devices, improve user experience, and avoid voice calls failures caused by Bluetooth calling devices being on the Codec negotiation blacklist.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN118118876B_ABST
    Figure CN118118876B_ABST
Patent Text Reader

Abstract

The present application provides a communication method, an electronic device and a storage medium, which relate to the field of terminal technology, and can improve the success rate of SCO link creation, so that the electronic device can smoothly make a voice call through a Bluetooth call device, thereby ensuring the user experience. The method includes: the electronic device establishes a service-level connection SLC with the Bluetooth call device; when there is a voice call demand, if the preset conditions are not met, the electronic device sends a first command to the Bluetooth call device; the preset conditions include: the electronic device does not receive the AT+BAC command, and the Bluetooth headset supports the SWB feature, and the Bluetooth headset is not in the encoder Codec negotiation blacklist; the first command is used to request the use of an encoding method with an encoder identifier of a first preset value as the encoding method used when the electronic device and the Bluetooth call device perform real-time audio data transmission.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The application relates to the field of terminal technology, and in particular to a communication method, electronic device and storage medium. Background Art

[0002] With the progress of society and the development of communication technology, earphones have become an indispensable daily necessity in people's lives. Among them, Bluetooth earphones are hands-free earphones that apply Bluetooth technology, allowing users to avoid the entanglement of earphone cables and use Bluetooth earphones freely and easily in various ways. For example, listening to music and making calls through Bluetooth earphones.

[0003] However, currently when a user makes a voice call via a Bluetooth headset, there is a situation where the sound or audio data cannot be transmitted through the Bluetooth headset but is played through the mobile phone, which reduces the user experience. Summary of the invention

[0004] The embodiments of the present application provide a communication method, an electronic device, and a storage medium, which can improve the success rate of establishing a SCO link, thereby enabling the electronic device to smoothly make a voice call through a Bluetooth calling device, thereby ensuring the user experience.

[0005] In order to achieve the above purpose, the embodiment of the present application adopts the following technical solution:

[0006] In the first aspect, the embodiment of the present application provides a communication method. The method includes: an electronic device establishes a service level connection SLC with a Bluetooth call device; when there is a voice call demand, if the preset conditions are not met, the electronic device sends a first command to the Bluetooth call device; the preset conditions include: the electronic device does not receive the AT+BAC command, and the Bluetooth call device supports the SWB feature, and the Bluetooth call device is not in the encoder Codec negotiation blacklist; the first command is used to request to use the encoding method with the encoder identifier as the first preset value as the encoding method used when the electronic device and the Bluetooth call device perform real-time audio data transmission.

[0007] Based on the technical solution provided by the present application, when the electronic device informs the Bluetooth calling device that it does not support Codec negotiation during the HFP connection establishment process because the Bluetooth calling device is in the Codec negotiation blacklist, the electronic device can also normally send the correct AT command (i.e., the first command: +BCS2) to the Bluetooth calling device. Then, the Bluetooth calling device can reply with a high probability to the AT command (specifically, the AT+BAC command) that complies with the HFP regulations, so that the coding negotiation between the electronic device and the Bluetooth calling device before establishing the SCO link is more likely to be successfully completed (i.e., the success rate of SCO link creation is improved), and the SCO link can be further established. After that, the electronic device can also smoothly make voice calls through the Bluetooth calling device, avoiding the problem in the prior art that the electronic device cannot make voice calls through the Bluetooth calling device because the Bluetooth calling device is in the Codec negotiation blacklist, thereby ensuring the user experience.

[0008] In a possible design of the first aspect, after the electronic device sends a first command to the Bluetooth call device, the method also includes: when the electronic device receives a second command from the Bluetooth call device, the electronic device sends a success indication to the Bluetooth call device, and establishes a synchronous connection (SCO) link with the Bluetooth call device; wherein the second command is used to indicate the use of an encoding method with an encoder identifier as a first preset value as the encoding method used when the electronic device and the Bluetooth call device perform real-time audio data transmission; and the success indication is used to indicate that the encoder negotiation is successful.

[0009] Based on the above design, since the electronic device sends a suitable first command to the Bluetooth call device, the electronic device can receive the second command from the Bluetooth call device, and the electronic device and the Bluetooth call device can successfully complete the encoder negotiation. Further, the electronic device and the Bluetooth call device can establish a SCO link. After that, the electronic device can also successfully make a voice call through the Bluetooth call device, ensuring the user experience.

[0010] In a possible design manner of the first aspect, the first preset value is 2, and the encoder is identified as a coding method of the first preset value as Minimum Shift Keying Coding (MSBC).

[0011] Based on the above implementation method, since the encoding method with the encoder identifier as the first preset value is the encoding method supported by most Bluetooth calling devices, after receiving the first command indicating this encoding method, the Bluetooth calling device will most likely return a second command agreeing to use the encoding method, thereby enabling the electronic device and the Bluetooth calling device to establish a SCO link, and the electronic device can also use the Bluetooth calling device for voice calls.

[0012] In a possible design of the first aspect, the method also includes: when there is a voice call demand, if the preset conditions are met, the electronic device sends a third command to the Bluetooth call device; the third command is used to request the use of an encoding method in which the encoder identifier is a second preset value as the encoding method used when the electronic device and the Bluetooth call device perform real-time audio data transmission.

[0013] Based on the above design, if the preset conditions are met, the electronic device can assume that the failure to receive the AT+BAC command during the establishment of the SLC connection is not because the Bluetooth headset is in the Codec negotiation blacklist. At this time, according to the code logic of the operating system of the electronic device, the electronic device should send the +BCS3 AT command to the Bluetooth headset to negotiate the use of LC3 encoding. In this way, the correct operation of the operating system in existing electronic devices can also be guaranteed.

[0014] In a possible design of the first aspect, after the electronic device sends a third command to the Bluetooth call device, the method also includes: when the electronic device receives a fourth command from the Bluetooth call device, the electronic device sends an error indication to the Bluetooth call device; wherein the fourth command is an attention AT command that does not comply with the Bluetooth hands-free protocol HFP; the error indication is used to indicate that the encoder negotiation failed.

[0015] Based on the above design, when the preset conditions are met, the electronic device will send a third command to the Bluetooth calling device, and after receiving the third command, the Bluetooth calling device will return an AT command that does not comply with the HFP regulations. Meeting the preset conditions means that the current electronic device and the Bluetooth calling device do not both support encoder negotiation, and it is unreasonable to force the establishment of a SCO link. Therefore, the SCO link should not be established at this time, and the fourth command sent by the Bluetooth headset has the purpose of making it impossible for the electronic device and the Bluetooth calling device to establish a SCO link, ensuring the smooth completion of the code logic of the existing electronic device operating system.

[0016] In a possible design manner of the first aspect, the second preset value is 3, and the encoder is identified as a coding method of the second preset value as low complexity communication codec LC3.

[0017] Based on the above design method, the code logic of the existing electronic device operating system is guaranteed to be completed smoothly.

[0018] In a possible design of the first aspect, when the electronic device sends an error indication to the Bluetooth calling device, the method further includes: the electronic device outputs a prompt message; the prompt message is used to indicate that the Bluetooth calling device cannot be used for a voice call.

[0019] Based on the above design, the defect that the user has to wait for the Bluetooth headset to play the real-time audio data of the voice call without being aware of the failure to establish a SCO link between the electronic device and the Bluetooth call device is avoided, resulting in the user being unable to make a voice call through the mobile phone in time. This allows the user to make a voice call using the mobile phone in time, ensuring the user's call experience.

[0020] In a possible design of the first aspect, the Bluetooth calling device includes a Bluetooth headset.

[0021] In a second aspect, the present application provides an electronic device, comprising a display screen, a memory and one or more processors; the display screen, the memory and the processor are coupled; wherein the memory stores computer program code, the computer program code comprises computer commands, and when the computer commands are executed by the processor, the electronic device executes the communication method provided in the first aspect and any possible design thereof.

[0022] In a third aspect, the present application provides a computer-readable storage medium, which includes computer commands. When the computer commands are executed on an electronic device, the electronic device executes the communication method provided in the first aspect and any possible design thereof.

[0023] In a fourth aspect, the present application provides a computer program product. When the computer program product is run on an electronic device, the electronic device executes the communication method provided in the first aspect and any possible design thereof.

[0024] It can be understood that the beneficial effects that can be achieved by the technical solutions provided in the second to fourth aspects mentioned above can refer to the beneficial effects in the first aspect and any possible design method thereof, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Figure 1 A schematic diagram of a Bluetooth driver log provided in an embodiment of the present application;

[0026] Figure 2 A detailed diagram of commands in a Bluetooth driver schedule provided for related technologies;

[0027] Figure 3 A schematic diagram of another Bluetooth driver log provided in an embodiment of the present application;

[0028] Figure 4 A schematic diagram of detailed contents of another command in a Bluetooth driver schedule provided in an embodiment of the present application;

[0029] Figure 5 A schematic diagram of a communication method provided in an embodiment of the present application;

[0030] Figure 6 A schematic diagram of the structure of a voice call system provided in an embodiment of the present application;

[0031] Figure 7 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present application;

[0032] Figure 8 A schematic diagram of the hardware structure of a Bluetooth headset provided in an embodiment of the present application;

[0033] Fig. 9 A schematic diagram of a software architecture of an electronic device provided in an embodiment of the present application;

[0034] Fig.10 A flow chart of a communication method provided in an embodiment of the present application;

[0035] Fig.11 A schematic diagram of the structure of a chip system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0036] The terms used in the following embodiments of the present application are only for the purpose of describing specific embodiments and are not intended to be limiting of the present application. As used in the specification and appended claims of the present application, the singular expressions "a", "an", "said", "above", "the" and "this" are intended to also include plural expressions, unless the context clearly indicates otherwise. It should also be understood that " / " means or, for example, A / B can mean A or B; "and / or" in the text is merely a description of an association relationship of associated objects, indicating that three relationships can exist, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone.

[0037] Reference to "embodiments" in this application means that a particular feature, structure, or characteristic described in conjunction with the embodiments may be included in at least one embodiment of the present application. The appearance of the phrase in various locations in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It is explicitly and implicitly understood by those skilled in the art that the embodiments described in this application may be combined with other embodiments.

[0038] The terms "first" and "second" in the following embodiments of the present application are used for descriptive purposes only and should not be understood as suggesting or implying relative importance or implicitly indicating the number of technical features indicated. Therefore, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features. In the description of the embodiments of the present application, unless otherwise specified, "multiple" means two or more.

[0039] First, the nouns involved in the embodiments of the present application are explained as follows:

[0040] (1) Bluetooth hands-free profile (HFP): The Bluetooth Special Interest Group (SIG) specifies different protocols or profiles for communication between Bluetooth devices. Common protocols include the advanced audio distribution profile (A2DP) and HFP. The hands-free profile (HFP) is mainly used for voice transmission between Bluetooth devices. For example, a Bluetooth device can control a mobile phone's calls, such as answering, hanging up, rejecting, and voice dialing.

[0041] The HFP protocol defines two roles: audio gateway (AG) and hands-free component (HF). Among them, AG serves as the audio input / output gateway, that is, the origin of the call, responsible for monitoring network calls, notifying the call status to the other end HF, and responsible for establishing a standard synchronous connection oriented (SCO) link or an enhanced synchronous connection oriented (ESCO) link to transmit voice. In an embodiment of the present application, the device serving as AG can also be referred to as a master device or a gateway device. HF serves as the remote audio input / output device of the audio gateway, that is, the receiving end of the call, responsible for answering the call instructions sent by AG, accepting the establishment of the SCO link, and providing a number of remote control functions (such as answering, hanging up, rejecting, voice dialing, etc.). In an embodiment of the present application, the device serving as HF can also be referred to as a slave device or a hands-free device.

[0042] The roles of devices supporting the HFP protocol are generally fixed. For example, a mobile phone is fixed as a master device or a gateway device, and a Bluetooth device (such as a smart watch, smart glasses, Bluetooth headset, etc.) is fixed as a slave device or a hands-free device.

[0043] Before the master device (such as a mobile phone) needs to communicate with the slave device (such as a Bluetooth headset) via Bluetooth, it is first necessary to establish a Bluetooth connection between the master device and the slave device through corresponding operations (such as the operation of turning on the Bluetooth function and the operation of Bluetooth pairing). Among them, the master device and the slave device with Bluetooth communication function can be called Bluetooth devices. Generally, Bluetooth connection can include asynchronous connectionless (Asynchronous Connection Less, ACL) link, logical link control and adaptation protocol (logical link control and adaptation protocol, L2CAP) connection, service discovery protocol (service discovery protocol, SDP) query, wireless communication / radiofrequency communication (Radiofrequency Communications, RFCOMM) connection, SCO link (or ESCO link) and other connections or links. In some embodiments, when the master device makes a voice call through the slave device, the HFP connection may include SDP query, RFCOMM connection and SCO link. Among them, before the SCO link in the HFP connection is established, after the SDP query and the RFCOMM connection is established, it can be considered that the SLC (service level connection) in the HFP connection has been established, or it can be called HFPSLC connection. Of course, in practice, the SLC connection may also include other contents. The description here in this application is only an example and is not intended to limit the actual situation.

[0044] When the master device only needs to perform general data transmission with the slave device, which does not require high real-time performance (for example, the master device transmits audio data or video data to the slave device for storage by the slave device, or the master device uses the slave device to play audio, etc.), only an ACL link and an L2CAP connection can be established between the master device and the slave device. When the master device needs to understand the service type or function provided by the slave device, an SDP query needs to be established.

[0045] When a reliable, connection-oriented data transmission channel needs to be established between the master device and the slave device, an RFCOMM connection is established. When the master device needs to transmit real-time audio data to the slave device (for example, to make a voice call through the slave device), a SCO link is also required between the master device and the slave device. Before establishing the SCO link, encoding negotiation is required between the master device and the slave device.

[0046] (2) The various links or connections included in Bluetooth connections are introduced as follows:

[0047] ACL link: The ACL link is an asynchronous connectionless data transmission link used to transmit data packets between Bluetooth devices. During the Bluetooth connection establishment process, the master device (such as a mobile phone) will initiate a page to the slave device (such as a Bluetooth headset) and search for the slave device through frequency hopping. The slave device will periodically scan for external paging, and when it scans the page of the master device, it will respond and establish an ACL link connection. The ACL link connection is the most basic type of connection between Bluetooth devices and provides the basis for communication between Bluetooth devices. It supports asynchronous data transmission, which means that data can be transmitted without establishing a stable connection. This connection method is suitable for application scenarios that do not require continuous and stable connections, such as file transfers, web browsing, etc. The ACL link also supports one-way transmission of audio data. For example, when the master device sends audio data to the slave device through the ACL link, the slave device cannot send audio data to the master device at the same time.

[0048] L2CAP connection: When the ACL link connection is established, the master device can initiate an L2CAP connection request. L2CAP is a layer in the Bluetooth protocol stack that is responsible for the connection and control of the data link layer. It provides functions such as data encapsulation, segmentation, and reassembly to ensure reliable data transmission between Bluetooth devices.

[0049] SDP query: SDP query is used to discover the services provided by Bluetooth devices, so that devices can understand each other's functions and characteristics, and thus perform corresponding communication and service interaction. After establishing an L2CAP connection, the master device can use SDP to query the services provided by the slave device when necessary. For example, the master device can use SDP to query the hands-free service of the slave device when necessary to obtain the channel number of the wireless communication RFCOMM channel (or RFCOMM channel).

[0050] RFCOMM connection: After obtaining the channel number of the RFCOMM channel, the master device can initiate an RFCOMM connection request. RFCOMM is a layer in the Bluetooth protocol stack that provides channel-based reliable data transmission services. It is similar to serial port communication and allows data communication between devices. RFCOMM connection is a channel-based reliable data transmission service established on the application layer. The master device and the slave device establish an application layer connection through the RFCOMM connection, so that data transmission and communication can be carried out. RFCOMM connection can be established after the SDP query is completed to transmit data between Bluetooth devices.

[0051] In some embodiments, in an HFP connection, the master device and the slave device may transmit non-real-time data such as control signals and status information through an RFCOMM connection.

[0052] SCO link: The SCO link is a connection technology supported by the Bluetooth baseband, which uses reserved time slots to transmit data. The SOC link is a link specifically used for synchronous transmission (such as the transmission of real-time voice data), or the SCO link can be considered to be mainly used for real-time voice communication. It provides a connection-oriented communication method based on the ACL link to ensure the real-time and continuity of voice data. The SCO link supports symmetric connections, ensuring that both the master device and the slave device can send voice data, thereby achieving two-way communication. Exemplarily, when the master device sends audio data to the slave device via the SCO link, the slave device can also send audio data to the master device via the SCO link. In some embodiments, in an HFP connection, the master device and the slave device can transmit real-time voice data via the SCO link.

[0053] When the master device needs to make a voice call through the slave device, real-time and continuous data transmission is required between the master and slave devices, and the delay and bandwidth requirements are high, so a SCO link needs to be established to meet these requirements. When the voice call ends or is no longer needed, the SCO link can be disconnected to reduce resource and power consumption.

[0054] In the process of establishing a Bluetooth connection, the ACL link and L2CAP connection must be established first to ensure the communication basis between devices. Then, after the SDP query understands the other party's services and the RFCOMM connection establishes the application layer data transmission channel, the SCO link can be established to meet the real-time and continuity requirements of voice calls.

[0055] (3) Ultra-wideband (SWB): SWB is a wireless communication technology that features high data rates (generally hundreds of megabits per second (Mbps) or even higher), short-range communication (generally a few meters to tens of meters), low power consumption, high security, and multipath tolerance (strong tolerance to multipath interference). Generally, for scenarios where Bluetooth headsets are used for voice calls, Bluetooth headsets normally cannot support SWB. Therefore, in some embodiments, in order to implement SWB, Bluetooth devices need to support low complexity communication codec (LC3) encoding.

[0056] (4) LC3 coding: LC3 coding is the audio codec specified by the Bluetooth special interest group (SIG) for the low energy audio (LE Audio) protocol introduced in Bluetooth 5.2. It was developed by Fraunhofer IIS and Ericsson as the successor to the SBC codec. Compared with traditional audio codecs, LC3 coding, as the audio specification used by LE Audio, has lower latency and higher energy efficiency (low computational complexity and low memory usage), which gives it significant advantages in real-time audio transmission and communication applications. Therefore, SWB can be implemented through LC3 coding.

[0057] With the development of communication technology, Bluetooth headsets have become a common daily necessity in people's daily lives. In order to be able to use the call function of the mobile phone more freely, people often use Bluetooth headsets for voice calls. However, currently when users use Bluetooth headsets for voice calls (including voice calls after successfully making a call and voice calls after successfully answering a call), the sound cannot be transmitted through the Bluetooth headset, but is played directly through the mobile phone, and manual switching of Bluetooth playback cannot switch to it. This greatly reduces the user experience of Bluetooth headsets. In addition, it should be noted that the above problems often occur when using Bluetooth headsets. 14 or newer Android devices.

[0058] In order to clarify the cause of the technical problem, relevant technical personnel can retrieve the host controller interface log (host controllerinterface log, Hci log) 1 related to the Bluetooth driver in the electronic device that can make voice calls normally through the Bluetooth headset, and the Hci log 2 related to the Bluetooth driver in the electronic device that cannot make voice calls normally through the Bluetooth headset (the Bluetooth headset cannot play the implemented voice), to locate the cause of the above problem.

[0059] For example, take the electronic device as AG, the Bluetooth headset as HF, and the user answering the voice call of the electronic device through the Bluetooth headset as an example, part of the content of Hci log1 is as follows Figure 1 As shown in the figure, the specific content of "AT String: +BRSF" in ① of Hci log1 can be as follows Figure 2 As shown in . Part of the content of Hci log2 is as follows Figure 3 As shown in the figure, the specific content of "AT String: +BRSF (bluetooth core specification)" in Hci log1 can be as follows Figure 4 shown. Figure 1 and Figure 2 Among all the AT commands (attention commands) in the log shown in , "+..." is the AT command sent by the electronic device to the Bluetooth headset, and "AT+..." is the AT command sent by the Bluetooth headset to the electronic device. It should be noted that the description of AT commands and related contents in this application is explained with reference to the provisions of the HFP protocol.

[0060] First, combine Figure 2 From the specific content of ① in Hci log1 shown in the figure, the specific value of "Codec Negotiation" is "Yes", which means that when the Bluetooth headset can normally play the real-time audio data during the voice call, the electronic device and the Bluetooth headset establish an HFP connection (specifically, it can be an SLC connection to establish an HFP connection), the electronic device will use the "+BRSF" AT command to inform the headset that it supports the encoder Codec negotiation. Figure 1 As shown in ② of Hci log1 shown in , if a call comes in to the electronic device (or the electronic device receives a call request), the electronic device can start coding negotiation with the Bluetooth headset to establish a SCO link. Figure 1 As shown in ③ of Hci log1, the electronic device will send the AT command "+BCS (bluetooth codec selection): 2" to the Bluetooth headset, indicating that the electronic device expects to use the audio encoding method or voice encoder with the encoder Codec identification (identity document, ID) of 2. Figure 1 As shown in ④ of Hci log1 shown in , the Bluetooth headset can send the AT command "AT+BCS=2" to the electronic device, indicating that the Bluetooth headset also supports the audio coding method or voice coder with Codec ID 2. In some embodiments, the audio coding method with Codec ID 2 can be minimum shift keying coding (MSBC).

[0061] Afterwards, refer to Figure 1 As shown in ⑤ of Hci log1, the electronic device can reply the AT command "Ok" to the Bluetooth headset, indicating that the encoding negotiation between the electronic device and the Bluetooth headset is successful and the SCO link can be established. After that, the SCO link will be successfully established between the electronic device and the Bluetooth headset, so that the electronic device can complete the voice call through the Bluetooth headset.

[0062] Secondly, combined Figure 4From the specific content of ① in Hci log2 shown in the figure, the specific value of "Codec Negotiation" is "No", it can be known that when the Bluetooth headset cannot play the real-time audio data during the voice call, when the electronic device and the Bluetooth headset establish an HFP connection (specifically, it can be an SLC connection to establish an HFP connection), the electronic device will use the AT command "+BRSF" to inform the headset that it does not support codec negotiation. Figure 3 As shown in ② of Hci log1 shown in , if a call comes in to the electronic device (or the electronic device receives a call request), the electronic device can start coding negotiation with the Bluetooth headset to establish a SCO link. Figure 3 As shown in ③ of Hcilog1 shown in , the electronic device will send the AT command "+BCS: 3" to the Bluetooth headset, indicating that the electronic device expects to use the audio encoding method or voice encoder with the encoder Codec ID of 3.

[0063] In some embodiments, the audio coding method with Codec ID 3 may be LC3 coding. Exemplarily, in practice, the definition code for the audio coding method with Codec ID 3 being LC3 coding is as follows:

[0064] / honor_u_release_magicos8.0-system_all / packages / modules / Bluetooth / system / stack / include / sdpdefs.h

[0065] 221#define UUID_CODEC_LC3 0x0003 / *LC3* / in global0 macro

[0066] Afterwards, refer to Figure 3 As shown in ④ of Hci log1, the Bluetooth headset will send the AT command "AT+BCS=1,2," to the electronic device. However, referring to the following provisions of the HFP protocol, it is stipulated that the Bluetooth headset is HF, and the value of AT+BCS sent is not allowed to have the last comma in "1,2,".

[0067] AT+Bcs(Bluetooth Codec Selection)

[0068] Syntax:AT+BCS= (u is a Codec ID)

[0069] Description.

[0070] This command confirms the codec to the remote device (AG), and implicitly also which synchronization protocol, will be used on the synchronousconnection. If no value is included, the command is invalid.

[0071] Afterwards, since the AT command "AT+BCS=1,2" sent by the Bluetooth headset does not comply with the HFP protocol, refer to Figure 3 As shown in ⑤ of Hci log1, the electronic device will reply the AT command "EEROR" to the Bluetooth headset. This indicates that the encoding negotiation between the electronic device and the Bluetooth headset has failed and the SCO link cannot be established. After that, the SCO link will not be established between the electronic device and the Bluetooth headset, and the electronic device will not be able to complete the voice call through the Bluetooth headset.

[0072] In summary, it can be seen that considering the electronic device as the party where the problem occurs, the reason why the Bluetooth headset cannot complete the voice call is that in the process of establishing an HFP connection between the electronic device and the Bluetooth headset, the electronic device sends the AT command "+BCS:3 (or can be called +BCS3)" to the Bluetooth headset, causing the Bluetooth headset to reply with an AT command that does not comply with the HFP protocol, thereby making it impossible for the electronic device and the Bluetooth headset to establish a SCO link, and the electronic device cannot complete the voice call through the Bluetooth headset.

[0073] Furthermore, we need to consider why the electronic device sends the AT command +BCS3 to the Bluetooth headset. Through query, it is found that when the electronic device needs to make a call, the relevant code running in the operating system of the electronic device contains the following content:

[0074] 543 bool_sdp_swb_support=p_scb->peer_sdp_features&BTA_AG_FEAT_SWB_SUPPORT;

[0075] 544 if(!p_seb->received_at_bac&&sdb_swb_support){

[0076] 545 p_scb->codec updated=true;

[0077] 546 p_scb->peer codecs=BTH_SCO_CODEC_LC3;

[0078] 547 p_scb->sco codec=BTH_SCO_CODEC_LC3;

[0079] 548}

[0080] It can be seen that in line 544, it will be determined that when the electronic device is establishing an HFP connection with the Bluetooth headset (specifically, the SLC connection in the HFP connection), if no AT+BAC command is received and the Bluetooth headset supports the SWB feature, the code in lines 545-547 will be executed. The code in line 547 indicates that the audio data in the SCO link uses the LC3 code. In this way, the electronic device will also send the AT command +BCS3 to the Bluetooth headset to request that the audio data be encoded using the LC3 encoding method in the SCO link.

[0081] Further, refer to the following provisions of the HFP Agreement:

[0082] 4.2.1.2Codec Negotiation

[0083] Secondly,in the initialization procedure.if the HF supports the CodecNegotiation feature,it shall check ifthe AT+BRSF command response from the AGhas indicated that it supports the Codec Negotiationfeature.lf both the HFand AG do support the Codec Negotiation feature then the HF shall send the AT+BAC=<HF avallable codecs> command to the AG to notify the AG of the available codecs in the HF.

[0084] It can be seen that the HFP protocol stipulates that "if both the HF and AG do support the CodecNegotiation feature then the HF shall send the AT+BAC=<HF avallable codecs> command to the AG to notify the AG of the avallable codecs in the HF". That is to say, only when both AG and HF support Codec negotiation, will HF send the AT command AT+BAC to AG. From the above analysis, we can see that, as well as Figure 1 and Figure 3 From the content, it can be seen that the HF Bluetooth headset currently does not send the AT+BAC AT command to the AG electronic device because when the HFP connection is established, the electronic device informs the Bluetooth headset that it does not support Codec negotiation. This leads to the problem that the above electronic device cannot make voice calls through the Bluetooth headset.

[0085] Generally, electronic devices support Codec negotiation by default. If the electronic device informs the Bluetooth headset that it does not support HFP connection when establishing an HFP connection, it means that the Bluetooth headset may have been added to the Codec negotiation blacklist. When the electronic device establishes an HFP connection with a device in the Codec negotiation blacklist, it will inform the device that it does not support Codec negotiation. The reason why the Bluetooth headset was added to the blacklist may be that there was a Codec negotiation failure between the Bluetooth headset and the electronic device, so it was added to the Codec negotiation blacklist. There are many reasons for the failure of Codec negotiation between the Bluetooth headset and the electronic device, such as the Codec negotiation time is too long, and there is strong signal interference when the Bluetooth headset establishes an HFP connection with the electronic device.

[0086] Based on the above statement, in order to solve the problem of the failure of the above-mentioned Bluetooth headset to make a voice call, the 544th line of code in the native code of the operating system of the electronic device can be changed so that the Bluetooth headset that establishes an HFP connection with the mobile phone can successfully complete the voice call even if it is in the Codec negotiation blacklist. Specifically, the role of the 544th line of code and the 547th line of code can be changed to, if the electronic device does not receive the AT+BAC command during the process of establishing an HFP connection with the Bluetooth headset, and the Bluetooth headset supports the SWB feature, and the Bluetooth headset is a device in the Codec negotiation blacklist, then the electronic device sends the +BCS3 AT command to the Bluetooth headset. In other words, only when the electronic device does not receive the AT+BAC command during the process of establishing an HFP connection with the Bluetooth headset, and the Bluetooth headset supports the SWB feature, and the Bluetooth headset is not a device in the Codec negotiation blacklist, the electronic device will send the +BCS3 AT command to the Bluetooth headset, and then the above-mentioned problem of the failure of the Bluetooth headset to make a voice call occurs.

[0087] Based on this, an embodiment of the present application provides a communication method, which can be applied to a voice call system including an electronic device and a Bluetooth call device (such as a Bluetooth headset). Figure 5 It is shown that the premise for the implementation of this technical solution is that the electronic device has completed the pairing connection with the Bluetooth call device. Among them, the pairing connection completed by the electronic device and the Bluetooth call device here can specifically include the ACL link in the Bluetooth connection, the L2CAP connection and the SLC connection in the HFP connection. Under this premise, if the electronic device has a voice call demand (for example, a call request is received or a call request is issued), the electronic device can start coding negotiation with the Bluetooth call device. Specifically, the electronic device can first determine whether the electronic device has not received the AT+BAC command, and the Bluetooth call device supports the SWB feature, and the Bluetooth call device is not in the Codec negotiation blacklist.

[0088] When the electronic device does not receive the AT+BAC command, the Bluetooth call device supports the SWB feature, and the Bluetooth call device is not in the Codec negotiation blacklist, it can be considered that the electronic device did not receive the AT+BAC command not because the Bluetooth call device is in the Codec negotiation blacklist. At this time, according to the code logic of the operating system of the electronic device, the electronic device should send the +BCS3 command to the Bluetooth call device to negotiate the use of LC3 encoding.

[0089] When the electronic device receives the AT+BAC command, or the Bluetooth device does not support the SWB feature, or the Bluetooth device is in the Codec negotiation blacklist, it can be considered that both the electronic device and the Bluetooth device support Codec negotiation, or the Bluetooth device does not support LC3 encoding, or the Bluetooth device is in the Codec negotiation blacklist, resulting in the electronic device not receiving the AT+BAC command. At this time, according to the code logic of the operating system in the existing electronic device, the electronic device can send the +BCS2 command to the Bluetooth device to negotiate the use of MSBC encoding.

[0090] In this way, when the Bluetooth calling device is in the Codec negotiation blacklist and the electronic device informs the Bluetooth calling device that it does not support Codec negotiation during the HFP connection establishment process, the electronic device can also send the +BCS2 AT command to the Bluetooth calling device normally. Then the Bluetooth calling device can reply with a high probability to the AT+BCS command that complies with the HFP regulations, so that the coding negotiation between the electronic device and the Bluetooth calling device before establishing the SCO link is more likely to be successfully completed (that is, the success rate of SCO link creation is increased), and the SCO link can be further established. After that, the electronic device can also make voice calls smoothly through the Bluetooth calling device, ensuring the user experience.

[0091] The technical solution provided by the embodiments of the present application is described in detail below with reference to the accompanying drawings.

[0092] The specific architecture of the voice call system that may be involved in the technical solution provided in the application embodiment can be referred to Figure 6 As shown. Taking the Bluetooth calling device as a Bluetooth headset as an example, the voice calling system may include an electronic device 01 and a Bluetooth headset 02. The distance between the electronic device 01 and the Bluetooth headset 02 may be relatively close (for example, the electronic device 01 is in the user's hand or in the pocket of clothes, and the Bluetooth headset 02 is worn on the user's ear).

[0093] In an embodiment of the present application, a service-level connection - SLC connection in a Bluetooth connection can be established between the electronic device 01 and the Bluetooth headset 02. The specific connection process can be determined by the user. For example, in a case where the electronic device 01 and the Bluetooth headset 02 have not established a Bluetooth connection, the electronic device 01 and the Bluetooth headset 02 can respectively respond to the user's Bluetooth activation operation and turn on the Bluetooth function respectively. Then, the electronic device 01 can establish an SLC connection in a Bluetooth connection with the Bluetooth headset 02 in response to the user's Bluetooth pairing operation. Or the Bluetooth headset 02 establishes an SLC connection in a Bluetooth connection with the electronic device 01 in response to the user's Bluetooth pairing operation. After the electronic device 01 and the Bluetooth headset 02 establish a Bluetooth connection for the first time (specifically, it can be an SLC connection in a Bluetooth connection), as long as the electronic device 01 and the Bluetooth headset 02 both turn on the Bluetooth function and the distance is less than a certain threshold, a Bluetooth connection will be automatically established.

[0094] In some embodiments, the electronic device may be a mobile phone, a tablet computer, a handheld computer, a personal computer (PC), an ultra-mobile personal computer (UMPC), a netbook, a cellular phone, a personal digital assistant (PDA), an augmented reality (AR) device, a virtual reality (VR) device, an artificial intelligence (AI) device, a wearable device, a vehicle-mounted device, a smart home device and / or a smart city device, etc., which can establish a Bluetooth connection with other devices and interact with them. The embodiments of the present application do not impose any special restrictions on the specific type of the electronic device.

[0095] For example, taking the electronic device as a mobile phone, Figure 7 A schematic structural diagram of an electronic device provided in an embodiment of the present application is shown.

[0096] Reference Figure 7 As shown, the electronic device may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a display screen 193, a subscriber identification module (SIM) card interface 194, and a camera 195, etc. Among them, the sensor module 180 may include a pressure sensor, a gyroscope sensor, an air pressure sensor, a magnetic sensor, an acceleration sensor, a distance sensor, a proximity light sensor, a fingerprint sensor, a temperature sensor, a touch sensor, an ambient light sensor, a bone conduction sensor, etc.

[0097] The processor 110 may include one or more processing units, for example, the processor 110 may include an application processor (AP), a modem processor, a graphics processor (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0098] The controller can be the nerve center and command center of the electronic device. The controller can generate operation control signals according to the command operation code and timing signal to complete the control of command acquisition and execution.

[0099] The processor 110 may also be provided with a memory for storing commands and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may store commands or data that the processor 110 has just used or cyclically used. If the processor 110 needs to use the command or data again, it may be directly called from the memory. This avoids repeated access, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

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

[0101] The charging management module 140 is used to receive charging input from a power supply device (e.g., a charger, a laptop power supply, etc.). The charger may be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 may receive charging input from a wired charger through the USB interface 130. In some wireless charging embodiments, the charging management module 140 may receive wireless charging input through a wireless charging coil of the electronic device.

[0102] While charging the battery 142, the charging management module 140 can also power the electronic device through the power management module 141. The battery 142 can be composed of multiple batteries connected in series. The power management module 141 is used to connect the battery 142, the charging management module 140 and the processor 110.

[0103] The power management module 141 is used to connect the battery 142, the charging management module 140 and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140, and supplies power to the processor 110, the internal memory 121, the display screen 193, the camera 195, and the wireless communication module 160. The power management module 141 can also be used to monitor parameters such as the battery voltage, current, battery cycle number, and battery health status (leakage, impedance). In some other embodiments, the power management module 141 can also be set in the processor 110.

[0104] The external memory interface 120 can be used to connect to an external non-volatile memory to expand the storage capacity of the electronic device. The external non-volatile memory communicates with the processor 110 through the external memory interface 120 to implement a data storage function. For example, files such as music and videos are stored in the external non-volatile memory.

[0105] The internal memory 121 may include one or more random access memories (RAM) and one or more non-volatile memories (NVM). The random access memory can be directly read and written by the processor 110, and can be used to store executable programs (such as machine commands) of the operating system or other running programs, and can also be used to store user and application data. The non-volatile memory can also store executable programs and store user and application data, etc., and can be loaded into the random access memory in advance for direct reading and writing by the processor 110.

[0106] A touch sensor is also called a "touch control device". The touch sensor can be arranged on the display screen 193. The touch sensor and the display screen 193 form a touch screen, also called a "touch control screen". The touch sensor is used to monitor touch operations acting on or near it. The touch sensor can pass the monitored touch operations to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through the display screen 193. In other embodiments, the touch sensor can also be arranged on the surface of the electronic device, which is different from the position of the display screen 193.

[0107] The ambient light sensor is used to sense the brightness of ambient light. For example, the ambient light sensor can measure the light intensity of four channels of ambient light. The ambient light sensor outputs the measured light intensity of the four channels of ambient light to the processor 110. The processor 110 can process the light intensity of the four channels of ambient light output by the ambient light sensor to obtain the light intensity of the ambient light. In the bright screen state, the electronic device can adaptively adjust the brightness of the display screen according to the obtained light intensity of the ambient light.

[0108] The pressure sensor is used to sense the pressure signal and can convert the pressure signal into an electrical signal. In some embodiments, the pressure sensor can be set on the display screen 193. There are many types of pressure sensors, such as resistive pressure sensors, inductive pressure sensors, capacitive pressure sensors, etc. When a touch operation is applied to the display screen 193, the electronic device monitors the touch operation intensity according to the pressure sensor. The electronic device can also calculate the touch position based on the monitoring signal of the pressure sensor. In some embodiments, touch operations acting on the same touch position but with different touch operation intensities can correspond to different operation commands. For example: when a touch operation with a touch operation intensity less than the first pressure threshold acts on the short message application icon, a command to view the short message is executed. When a touch operation with a touch operation intensity greater than or equal to the first pressure threshold acts on the short message application icon, a command to create a new short message is executed.

[0109] In some embodiments, the electronic device may include 1 or N cameras 195, where N is a positive integer greater than 1. In the embodiment of the present application, the type of camera 195 can be distinguished according to the hardware configuration and the physical location. For example, the camera arranged on the side of the display screen 193 of the electronic device can be called a front camera, and the camera arranged on the side of the back cover of the electronic device can be called a rear camera; for another example, a camera with a short focal length and a larger viewing angle can be called a wide-angle camera, and a camera with a long focal length and a small viewing angle can be called a normal camera. Among them, the length of the focal length and the size of the viewing angle are relative concepts, and there is no specific parameter limitation. Therefore, wide-angle cameras and ordinary cameras are also a relative concept, and can be specifically distinguished according to physical parameters such as focal length and viewing angle.

[0110] The electronic device implements the display function through a GPU, a display screen 193, and an application processor. The GPU is a microprocessor for image editing, connecting the display screen 193 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 110 may include one or more GPUs that execute program commands to generate or change display information.

[0111] The electronic device can realize the shooting function through ISP, camera 195, video codec, GPU, display screen 193 and application processor. GPU is used to perform mathematical and geometric calculations for graphics rendering. Processor 110 may include one or more GPUs, which execute program commands to generate or change display information. In the embodiment of the present application, the function of the GPU is used in the frame drawing process of each image frame so that the final displayed picture obtains better display effect and performance.

[0112] The ISP is used to process the data fed back by the camera 195. For example, when taking a photo, the shutter is opened, and the light is transmitted to the camera photosensitive element through the lens. The light signal is converted into an electrical signal, and the camera photosensitive element transmits the electrical signal to the ISP for processing and converts it into an image visible to the naked eye. The ISP can also perform algorithm optimization on the noise and brightness of the image. The ISP can also optimize the exposure, color temperature and other parameters of the shooting scene. In some embodiments, the ISP can be set in the camera 195. The camera 195 is used to capture static images or videos.

[0113] Digital signal processors are used to process digital signals. In addition to processing digital image signals, they can also process other digital signals. For example, when an electronic device selects a frequency point, a digital signal processor is used to perform Fourier transform on the frequency point energy.

[0114] Video codecs are used to compress or decompress digital videos. Electronic devices can support one or more video codecs. In this way, electronic devices can play or record videos in multiple coding formats, such as Moving Picture Experts Group (MPEG) 1, MPEG2, MPEG3, MPEG4, etc.

[0115] NPU is a neural network (NN) computing processor. By drawing on the structure of biological neural networks, such as the transmission mode between neurons in the human brain, it can quickly process input information and can also continuously self-learn. Through NPU, applications such as intelligent cognition of electronic device 100 can be realized, such as image recognition, face recognition, voice recognition, text understanding, etc.

[0116] The display screen 193 is used to display images, videos, etc. The display screen 193 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light emitting diode or an active-matrix organic light emitting diode (AMOLED), a flexible light-emitting diode (FLED), Miniled, MicroLed, Micro-oLed, a quantum dot light-emitting diode (QLED), etc. In some embodiments, the electronic device may include 1 or N display screens 193, where N is a positive integer greater than 1.

[0117] In an embodiment of the present application, the display screen 193 can be used to display pages required by the electronic device (for example, wizard pages (including highlight recommendation pages and external module access pages), etc.), and display images captured by any one or more cameras 195 in the interface.

[0118] The wireless communication function of the electronic device can be implemented through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem and baseband processor.

[0119] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in the electronic device can be used to cover a single or multiple communication frequency bands. Different antennas can also be reused to improve the utilization of the antennas.

[0120] The mobile communication module 150 can provide solutions for wireless communications including 2G / 3G / 4G / 5G, etc., applied to electronic devices. The mobile communication module 150 can receive electromagnetic waves through the antenna 1, and filter, amplify, and process the received electromagnetic waves, and transmit them to the modulation and demodulation processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modulation and demodulation processor, and convert it into electromagnetic waves for radiation through the antenna 1. In some embodiments, at least some of the functional modules of the mobile communication module 150 can be set in the processor 110. In some embodiments, at least some of the functional modules of the mobile communication module 150 can be set in the same device as at least some of the modules of the processor 110.

[0121] The modem processor may include a modulator and a demodulator. Among them, the modulator is used to modulate the low-frequency baseband signal to be sent into a medium-high frequency signal. The demodulator is used to demodulate the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After the low-frequency baseband signal is processed by the baseband processor, it is passed to the application processor. The application processor outputs a sound signal through an audio device (not limited to a speaker 170A, a receiver 170B, etc.), or displays an image or video through a display screen 193. In some embodiments, the modem processor may be an independent device. In other embodiments, the modem processor may be independent of the processor 110 and be set in the same device as the mobile communication module 150 or other functional modules.

[0122] The wireless communication module 160 can provide wireless communication solutions including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR), etc., which are applied to electronic devices. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via the antenna 2, modulates the frequency of the electromagnetic wave signal and performs filtering, and sends the processed signal to the processor 110. The wireless communication module 160 can also receive the signal to be sent from the processor 110, modulate the frequency of it, amplify it, and convert it into electromagnetic waves for radiation through the antenna 2.

[0123] In some embodiments, the antenna 1 of the electronic device is coupled to the mobile communication module 150, and the antenna 2 is coupled to the wireless communication module 160, so that the electronic device can communicate with the network and other devices through wireless communication technology. The wireless communication technology may include global system for mobile communications (GSM), general packet radio service (GPRS), code division multiple access (CDMA), wideband code division multiple access (WCDMA), time-division code division multiple access (TDSCDMA), long term evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technology. The GNSS may include a global positioning system (GPS), a global navigation satellite system (GLONASS), a Beidou navigation satellite system (BDS), a quasi-zenith satellite system (QZSS) and / or a satellite based augmentation system (SBAS).

[0124] The SIM card interface 194 is used to connect a SIM card. The SIM card can be connected to or disconnected from the electronic device by inserting it into or removing it from the SIM card interface 194. The electronic device can support one or more SIM card interfaces. The SIM card interface 194 can support Nano SIM cards, Micro SIM cards, SIM cards, etc. Multiple cards can be inserted into the same SIM card interface 194 at the same time. The SIM card interface 194 can also be compatible with external memory cards. The electronic device interacts with the network through the SIM card to implement functions such as calls and data communications. One SIM card corresponds to one user number.

[0125] It is understandable that the interface connection relationship between the modules illustrated in the embodiment of the present invention is only a schematic illustration and does not constitute a structural limitation of the electronic device. In other embodiments of the present application, the electronic device may also adopt different interface connection methods in the above embodiments, or a combination of multiple interface connection methods.

[0126] Of course, it is understandable that the above Figure 7 The figure is only an exemplary description when the electronic device is in the form of a mobile phone. If the electronic device is in the form of a tablet computer, a handheld computer, a PC, a PDA, a wearable device (such as a smart watch, a smart bracelet), etc., the structure of the electronic device may include Figure 7 The structure shown in the figure is less than Figure 7 More structures are shown in the figure, which are not limited here.

[0127] In the embodiment of the present application, the Bluetooth headset 02 may be a TWS headset. The Bluetooth headset may include one earplug or two earplugs. Figure 6 As shown, in the case where the Bluetooth headset 02 includes two earplugs, one earplug is the left earplug 02-1, and the other earplug is the right earplug 02-2.

[0128] For example, Figure 8 The present invention is a schematic diagram of the structure of an earplug (left earplug or right earplug) of a Bluetooth headset.

[0129] Specifically, refer to Figure 8 As shown, the earplug of the Bluetooth headset 02 (such as the left earplug 02 - 1 ) may include: a processor 021 , a memory 022 , a sensor 023 , a wireless communication module 024 , a speaker 025 , a microphone 026 , a power supply 027 , and an input / output interface 028 .

[0130] The memory 022 may be used to store application code, such as application code for establishing a wireless connection with another earplug (such as the right earplug 02-2) of the Bluetooth headset 02, and for pairing the earplug with the first electronic device 01 (such as the smart wearable device 100). The processor 021 may control the execution of the above application code to implement the functions of the earplug of the Bluetooth headset in the embodiment of the present application.

[0131] The memory 022 may also store a Bluetooth address for uniquely identifying the earplug, and a Bluetooth address of another earplug of the Bluetooth headset. In addition, the memory 022 may also store connection data of an electronic device that has been successfully paired with the earplug before. For example, the connection data may be a Bluetooth address of an electronic device that has been successfully paired with the earplug. Based on the connection data, the earplug can be automatically paired with the electronic device without configuring a connection therewith, such as performing a legitimacy verification. The Bluetooth address may be a media access control (MAC) address.

[0132] Sensor 023 may be a distance sensor or a proximity light sensor. The earplug may determine whether it is worn by the user through the sensor 023. For example, the earplug may use a proximity light sensor to detect whether there is an object near the earplug, thereby determining whether the earplug is worn by the user. When it is determined that the earplug is worn, the earplug may turn on the speaker 025. In some embodiments, the earplug may also include a bone conduction sensor, combined into a bone conduction headset. Using the bone conduction sensor, the earplug may obtain the vibration signal of the vocal bone, parse the voice signal, and realize the voice function. In other embodiments, the earplug may also include a touch sensor for detecting the user's touch operation. In other embodiments, the earplug may also include a fingerprint sensor for detecting the user's fingerprint, identifying the user's identity, etc. In other embodiments, the earplug may also include an ambient light sensor, which may adaptively adjust some parameters, such as the volume, according to the brightness of the perceived ambient light.

[0133] The wireless communication module 024 is used to support short-distance data exchange between the earplug of the Bluetooth headset and various electronic devices, such as the above-mentioned electronic device 01. In some embodiments, the wireless communication module 024 can be a Bluetooth transceiver. The earplug of the Bluetooth headset can establish a wireless connection with the above-mentioned first electronic device 01 through the Bluetooth transceiver to achieve short-distance data exchange between the two.

[0134] At least one speaker 025, also called a "receiver", can be used to convert the audio electrical signal into a sound signal and play it. For example, when the earplug of a Bluetooth headset is used as the audio output device of the electronic device 01, the speaker 025 can convert the received audio electrical signal into a sound signal and play it.

[0135] At least one microphone 026, which may also be called a "microphone" or "microphone", is used to convert sound signals into audio electrical signals. For example, when the earplug of the Bluetooth headset 02 is used as the audio input device of the electronic device 01, when the user is speaking (such as talking or sending a voice message), the microphone 026 can collect the user's voice signal and convert it into an audio electrical signal.

[0136] The power source 027 can be used to supply power to various components included in the earplug of the Bluetooth headset 02. In some embodiments, the power source 027 can be a battery, such as a rechargeable battery.

[0137] Typically, the Bluetooth headset 02 is equipped with an earplug box. The earplug box can be used to store the left and right earplugs of the Bluetooth headset. The earplug box can be used to store the left earplug 02-1 and the right earplug 02-2 of the Bluetooth headset. In addition, the earplug box can also charge the left and right earplugs of the Bluetooth headset 02. Accordingly, in some embodiments, the earplugs may also include: an input / output interface 028. The input / output interface 028 may be used to provide any wired connection between the earplugs of the Bluetooth headset and the earplug box (such as the earplug box 02-3).

[0138] In some embodiments, the input / output interface 028 may be an electrical connector. When the earplugs of the Bluetooth headset 02 are placed in an earplug box, the earplugs of the Bluetooth headset 02 may be electrically connected to the earplug box (such as the input / output interface of the earplug box) through the electrical connector. After the electrical connection is established, the earplug box may charge the power supply 027 of the earplugs of the Bluetooth headset. After the electrical connection is established, the earplugs of the Bluetooth headset 02 may also perform data communication with the earplug box. For example, the earplugs of the Bluetooth headset 02 may receive a pairing command from the earplug box through the electrical connection. The pairing command is used to instruct the earplugs of the Bluetooth headset 02 to turn on the wireless communication module 024, so that the earplugs of the Bluetooth headset 02 may be paired and connected with the first electronic device 01 using a corresponding wireless communication protocol (such as Bluetooth).

[0139] Of course, the earplug of the Bluetooth headset 02 may not include the input / output interface 028. In this case, the earplug can realize the charging or data communication function based on the wireless connection established with the earplug box through the wireless communication module 024.

[0140] In addition, in some embodiments, the earplug box may further include a processor, a memory and other components. The memory may be used to store application code, and the processor of the earplug box controls the execution to realize the functions of the earplug box. For example, when the user opens the lid of the earplug box, the processor of the earplug box executes the application code stored in the memory, and can send a pairing command to the earplug of the Bluetooth headset in response to the user's operation of opening the lid.

[0141] It is understandable that the structure shown in the embodiment of the present application does not constitute a specific limitation on the earplug of the Bluetooth headset 02. Figure 8 More or fewer components shown in the figure may be combined with two or more components, or may have different component configurations. For example, the earplug may also include an indicator light (which may indicate the status of the earplug such as the battery level), a dust screen (which may be used in conjunction with a handset), and other components. Figure 8 The various components shown in the drawings may be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing or application specific integrated circuits.

[0142] It should be noted that the structures of the left and right earplugs of the Bluetooth headset 02 can be the same. For example, the left and right earplugs of the Bluetooth headset 02 can both include Figure 8 Alternatively, the structures of the left and right earplugs of the Bluetooth headset 02 may also be different. For example, one earplug of the Bluetooth headset 02 (such as the left earplug 02-1) may include Figure 8 , and another earplug (such as the right earplug 02-2) may include Figure 8 Other components except microphone 026.

[0143] It is understandable that, in general, the realization of electronic device functions requires not only hardware support but also software cooperation. The software system of the electronic device can adopt a layered architecture, an event-driven architecture, a micro-core architecture, a micro-service architecture, or a cloud architecture. Taking the system as an example, the software structure of the electronic device is illustrated.

[0144] Fig. 9 A schematic diagram of a layered architecture of a software system of an electronic device provided in an embodiment of the present application. The layered architecture divides the software into several layers, each with clear roles and division of labor. The layers communicate with each other through software interfaces (such as APIs).

[0145] In some examples, reference Fig. 9 As shown, in the embodiment of the present application, the software of the electronic device is divided into five layers, from top to bottom, namely, the application layer, the framework layer (or called the application framework layer), the system library and the Android runtime (android runtime), the HAL layer (hardware abstraction layer, hardware abstraction layer) and the driver layer (or called the kernel layer). Among them, the system library and the Android runtime can also be called the local framework layer or the native layer.

[0146] The application layer can include a series of applications. Fig. 9 As shown, the application layer may include applications (APP) such as the main interface, camera, gallery, calendar, map, WLAN, Bluetooth, music, video, short message, call, navigation, and instant messaging.

[0147] The framework layer provides an application programming interface (API) and a programming framework for the applications in the application layer. The application framework layer includes some predefined functions or services. For example, the application framework layer may include an activity manager, a window manager, a content provider, a camera service, an audio service (or an audio framework), a view system, a phone manager (or a phone framework), a Bluetooth service (or a Bluetooth framework), a resource manager, a notification manager, a package manager, etc., and the embodiments of the present application do not impose any restrictions on this.

[0148] The activity management service is the ActivityManagerService in the electronic device. The activity management service can be used to obtain the foreground activity, that is, the activity of the foreground application. The foreground application information may be included, including but not limited to: process, application name and other information.

[0149] The window manager is used to manage window programs. The window manager can obtain the display screen size, determine whether there is a status bar, lock the screen, capture the screen, etc.

[0150] Content providers are used to store and retrieve data and make it accessible to applications. This data can include videos, images, audio, calls made and received, browsing history and bookmarks, phone books, etc.

[0151] The main function of the camera service is to provide a unified interface and functions for applications to access and operate camera devices (i.e., cameras). The main function of the audio service is to provide a unified interface and functions for applications to access and operate audio modules in electronic devices.

[0152] The view system includes visual controls, such as controls for displaying text, controls for displaying pictures, etc. The view system can be used to build applications. The display interface can be composed of one or more views. For example, a display interface including a text notification icon can include a view for displaying text and a view for displaying pictures. In some embodiments, the view system can also include or start a rendering thread to complete operations such as drawing a frame buffer.

[0153] The phone manager is used to provide communication functions of the electronic device. For example, the phone manager can manage the call status of the call application (including initiation, connection, hang up, etc.).

[0154] The Bluetooth service is responsible for managing and controlling the interaction between Bluetooth hardware and software. It is responsible for discovering other Bluetooth devices, establishing and managing Bluetooth connections, handling Bluetooth data transmission, managing Bluetooth profiles (such as HFP, A2DP (advanced audio distribution profile, Bluetooth audio transmission model protocol), AVRCP (audio video remote control profile, audio / video remote control specification), etc.) and Bluetooth-related settings and configurations.

[0155] The resource manager provides various resources for applications, such as localized strings, icons, images, layout files, video files, and so on.

[0156] The notification manager enables applications to display notification information in the status bar. It can be used to convey notification-type messages and can disappear automatically after a short stay without user interaction. For example, the notification manager is used to notify download completion, message reminders, etc. The notification manager can also be a notification that appears in the system top status bar in the form of a chart or scroll bar text, such as notifications of applications running in the background, or a notification that appears on the screen in the form of a dialog window. For example, a text message is displayed in the status bar, a prompt sound is emitted, an electronic device vibrates, an indicator light flashes, etc.

[0157] The package manager is The system is used to manage application packages. It allows applications to obtain detailed information about installed applications and their services, permissions, etc. The package manager is also used to manage events such as application installation, uninstallation, and upgrades.

[0158] The system library can include multiple functional modules. For example: surface manager, media library, OpenGL ES, SGL, etc. The surface manager is used to manage the display subsystem and provide fusion of 2D and 3D layers for multiple applications. The media library supports playback and recording of a variety of commonly used audio and video formats, as well as static image files, etc. The media library can support a variety of audio and video encoding formats, such as: MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc. OpenGL ES is used to implement 3D graphics drawing, image rendering, synthesis, and layer processing, etc. SGL is a drawing engine for 2D drawing.

[0159] The Android runtime includes the core library and the ART virtual machine. The Android runtime is responsible for the scheduling and management of the Android system. The core library consists of two parts: one is the function that the Java language needs to call, and the other is the Android core library. The application layer and the application framework layer run in the ART virtual machine. The ART virtual machine executes the Java files of the application layer and the application framework layer as binary files. The ART virtual machine is used to perform object life cycle management, stack management, thread management, security and exception management, and garbage collection.

[0160] The HAL layer is an interface layer between the operating system kernel and the hardware circuit, and its purpose is to abstract the hardware. It hides the hardware interface details of a specific platform and provides a virtual hardware platform for the operating system, making it hardware-independent and portable on multiple platforms. The HAL layer provides a standard interface to display device hardware functions to the higher-level Java API framework (i.e., the framework layer). The HAL layer contains multiple library modules, each of which implements an interface for a specific type of hardware component, such as: audio HAL audio module (also called audio manager), bluetooth HAL Bluetooth module (also called Bluetooth manager), camera HAL camera module (also called camera HAL or camera hardware abstraction module), sensors HAL sensor module (or called Isensor service, sensor service).

[0161] The driver layer is the layer between hardware and software. The driver layer includes at least a display driver, a camera driver, an audio driver, a sensor driver, a battery driver, a Bluetooth driver, etc., which are not limited in this application. Among them, the sensor driver can specifically include the driver of each sensor contained in the electronic device, such as an ambient light sensor driver, etc. Exemplarily, the ambient light sensor driver can respond to the indication or command of the sensor module to obtain the detection data, and send the detection data of the ambient light sensor to the sensor module in a timely manner. When the electronic device establishes a Bluetooth connection with the Bluetooth headset (including SLC connection and SOC connection, etc.), the information interaction between the electronic device and the Bluetooth headset is completed by the Bluetooth driver controlling the Bluetooth chip.

[0162] In addition, in the embodiment of the present application, when there is a call demand in the electronic device, whether to send +BCS2 or +BCS3 to the Bluetooth headset can be determined by the Bluetooth driver.

[0163] Although the software architecture of the electronic device in the present application embodiment is described using the Android system as an example, its basic principles are also applicable to the software architecture based on Electronic devices running iOS, Windows and other operating systems.

[0164] The technical solutions provided in the embodiments of the present application can be implemented in electronic devices having the above-mentioned hardware architecture or software architecture.

[0165] Based on the above Figure 6-Figure 9 The voice call system shown in the figure, as well as the hardware architecture and software architecture of the components of the voice call system, are combined with Fig.10 As shown, the communication method provided in the embodiment of the present application is introduced. Fig.10 A flow chart of a communication method provided in an embodiment of the present application. Fig.10 As shown, taking the electronic device as a mobile phone and the Bluetooth calling device as a Bluetooth headset as an example, the communication method may include S1001-S1008:

[0166] S1001. The mobile phone establishes a service-level connection with the Bluetooth headset.

[0167] The server connection may refer to an SLC connection in an HFP connection, that is, a service level connection is established between the mobile phone and the Bluetooth headset. In the SLC connection, the mobile phone acts as an AG and the Bluetooth headset acts as a HF.

[0168] Before the mobile phone and the Bluetooth headset establish a service-level connection, the mobile phone and the Bluetooth headset should also establish an ACL link and an L2CAP connection.

[0169] Specifically, after the mobile phone establishes an ACL link and an L2CAP connection with the Bluetooth headset, after completing the SDP query and establishing the RFCOMM connection, the SLC connection can be established after the interaction of related commands of the SLC connection.

[0170] In practice, after the user turns on the Bluetooth function of the mobile phone and performs the pairing operation, the mobile phone begins to establish an ACL link, an L2CAP connection, and an RFCOMM connection with the Bluetooth headset in sequence, and then establishes an SLC connection. Among them, after the mobile phone and the Bluetooth headset have established an ACL link and an L2CAP connection, the mobile phone can obtain the functions and characteristics of the Bluetooth headset through the SDP query process, and then decide whether to start establishing an SLC connection in the HFP connection. Specifically, if the Bluetooth headset is found through the SDP query to have the functions corresponding to the HFP connection, such as remote control and voice calls, then the SLC connection in the HFP connection can be established.

[0171] The specific implementation of S1001 can be any possible implementation, and this application does not impose any specific limitation on this.

[0172] When a service-level connection is established between the mobile phone and the Bluetooth headset, if the mobile phone has a voice call requirement, the mobile phone needs to try to establish a SCO link with the Bluetooth headset to make a voice call through the Bluetooth headset. Before establishing the SCO link, the mobile phone and the Bluetooth headset need to negotiate an encoder (i.e., Codec negotiation), that is, execute S1002-S1008. After the encoder negotiation is successful, the mobile phone can establish a SCO link with the Bluetooth headset for subsequent voice calls through the Bluetooth headset.

[0173] S1002: When there is a need for a voice call, the electronic device determines whether a preset condition is met.

[0174] For example, the voice call demand may specifically refer to the electronic device receiving a call request from another electronic device or sending a call request to another electronic device. That is, when the electronic device receives a call request or sends a call request, it can be determined that the electronic device has a voice call request. The call request may be sent through an instant messaging software (e.g. ) or sent or received by the phone application.

[0175] The preset conditions may include: the electronic device does not receive the AT+BAC command, the Bluetooth headset supports the SWB feature, and the Bluetooth headset is not in the Codec negotiation blacklist.

[0176] Exemplarily, the Codec negotiation blacklist may be stored in a specific storage area of ​​an electronic device for use by the electronic device. The Codec negotiation blacklist may include an identifier (e.g., a name) of at least one device. If the identifier of a Bluetooth headset is an identifier included in the Codec negotiation blacklist, the Bluetooth headset may be considered to be a device included in the Codec negotiation blacklist. In this case, during the process of establishing an SLC connection with the Bluetooth headset, the electronic device will inform the Bluetooth headset through a command that it does not support Codec negotiation.

[0177] The electronic device not receiving the AT+BAC command may specifically refer to whether the electronic device receives the AT+BAC command during the process of establishing a service-level connection with the Bluetooth headset. Whether the Bluetooth headset supports the SWB feature may be obtained by the electronic device through SDP query during the process of establishing a service-level connection with the Bluetooth headset.

[0178] If the preset conditions are met, the electronic device may assume that the failure to receive the AT+BAC command during the establishment of the SLC connection is not because the Bluetooth headset is in the Codec negotiation blacklist. At this time, according to the code logic of the operating system of the electronic device, the electronic device should send the AT command +BCS3 to the Bluetooth headset to negotiate the use of LC3 encoding. That is, S1003 is executed.

[0179] If the preset conditions are not met, the electronic device may assume that both the electronic device and the Bluetooth headset support Codec negotiation, or the Bluetooth headset does not support LC3 encoding, or the Bluetooth headset is in the Codec negotiation blacklist, resulting in the electronic device not receiving the AT+BAC command. At this time, according to the code logic of the operating system of the electronic device, the electronic device may send the AT command +BCS2 to the Bluetooth headset to negotiate the use of MSBC encoding. That is, S1004 is executed.

[0180] S1003: The electronic device sends a third command to the Bluetooth headset.

[0181] Exemplarily, the third command is an AT command, specifically, the AT command +BCS3, which indicates that the electronic device requests to use the encoding method with the encoder identifier of 3 (i.e., LC3 encoding) as the encoding method used when the electronic device and the Bluetooth headset perform real-time audio data transmission. Among them, 3 can be called the second preset value.

[0182] Exemplarily, the code segments corresponding to S1002 and S1003 may be as follows:

[0183] 514void bta_ag_rfe_open(tBTA_AG_SCB*p_scb,const tBTA_AG_DATA&data)

[0184] 515 / *initialize AT feature variables* /

[0185] 516p_scb->clip_enabled=false;

[0186] 517p_scb->ccwa_enabled=false;

[0187] 518p_scb->cmer_enabled=false:

[0188] 519p_scb->cmee_enabled=false;

[0189] 520p_scb->inband enabled=

[0190] 521((p_Scb->features&BTA_AG_FEAT_INBAND)==BTA_AG_FEAT_INBAND);

[0191] 522if(p_scb->con_service==BTA_AG_HFP){

[0192] 523size_t version_value_size=sizeof(p_scb->peer_version)

[0193] 524if(!btif_config_get_bin(

[0194] 525 p_scb->peer_addr.ToString(),HFP_VERSION_CONFIG_KEY,526 (uint8_t*)&p_scb->peer_version,&version_walue_size)){

[0195] 527APPL_TRACE_WARNING("%s:Failed read cached peer HFP version for%s”,528__,func__,ADDRESS_TO_LOGGABLE_CSTR(p_scb->peer addr));529p_scb->peer_version=HFP_HSP_VERSION_NKNOWN;

[0196] 530}

[0197] 531size_t sdp_features_size=sizeof(p_scb->peer_sdp_features);

[0198] 532if(btif_config_get_bin(

[0199] 533 p_scb->peer_addr.ToString(),HFP_SDP_FEATURES_CONFIG_KEY,534(uint8 t*)&p_scb->peer_sdp_features,&sdp_features_size)){

[0200] 535bool_sdp_wbs_support=p_scb->peer_sdp_features&BTA_AG_FEAT_WBS_SUPPO RT;

[0201] 536 / *DTS2018071302731h00385336 20180717begin* /

[0202] 537if(!p_scb->received_at_bac&&sdp_wbs_support538&&!HwInteropMatch(INTEROP_DISABLE_AG_FEATURE_CODEC_NEG,&(p_scb->peer_addr))){

[0203] 539 / *DTS2018071302731h00385336 20180717end* /

[0204] 540p_scb->codec_updated=true;

[0205] 541p_scb->peer_codecs=BTM_SCO_CODEC_CVSD|BTM_SCO_CODEC_MSBC;

[0206] 542p_scb->sco_codec=BTM_SCO_CODEC_MSBC:

[0207]

[0208] 544bool sdp_swb_support=p_scb->peer_sdp_features&BTA_AG_FEAT_SWB_SUPPORT;545if(!p_scb->received_at_bac&&sdp_swb_support546 / *DT82023122240213100017664 20231227begin* /

[0209] 547&&!HwInteropMatch(INTEROP_DISABLE_AG_FEATURE_CODEC_NEG,&(p_scb->peer_addr)){

[0210] 548p scb->codec updated=true;

[0211] 549p_scb->peer codecs=BTH SCO CODEC LC3;

[0212] 550p scb->sco codec=BTH SCO CODEC LC3;

[0213] 551}

[0214] Among them, the content of line 547 is "and the Bluetooth headset is not in the Codec negotiation blacklist."

[0215] After the electronic device sends the first command to the Bluetooth headset, based on the working logic of the existing Bluetooth headset, the Bluetooth headset will return an AT command that does not comply with the HFP specification to the electronic device. That is, S1005 is executed after S1003.

[0216] S1004: The electronic device sends a first command to the Bluetooth headset.

[0217] Exemplarily, the first command is an AT command, specifically, the AT command +BCS2, which indicates that the electronic device requests to use the encoding method with the encoder identifier of 2 (i.e., MSBC encoding) as the encoding method used when the electronic device and the Bluetooth headset perform real-time audio data transmission. Among them, 2 can be called the first preset value.

[0218] After the electronic device sends the first command to the Bluetooth headset, based on the working logic of the existing Bluetooth headset, the Bluetooth headset returns an AT command that complies with the HFP specification to the electronic device, and the encoding method indicated by the AT command is the same as the encoding method indicated by the first command. That is, S1006 is executed after S1004.

[0219] S1005. The Bluetooth headset receives a third command from the mobile phone, and sends a fourth command to the mobile phone in response to the third command.

[0220] The fourth command is an AT command, and specifically may be an AT command "AT+BCS=1,2," which does not comply with HFP regulations.

[0221] Specifically, after receiving the AT command for negotiating the encoding method from the mobile phone, the Bluetooth headset will normally determine whether the encoding method indicated in the AT command is supported by itself. If supported, the corresponding AT command indicating the same encoding method will be returned to the mobile phone; if not supported, the Bluetooth headset can reply with the AT+BAC AT command indicating other encoding methods to indicate that the Bluetooth headset does not support the encoding method indicated by the AT command sent by the mobile phone, and request the mobile phone to determine whether the encoding method indicated by AT+BAC can be used. After receiving the AT+BAC command, the mobile phone performs subsequent actions according to predetermined rules. For example, after receiving the AT+BAC command, the mobile phone can consider that the current encoder negotiation has failed, and then the encoder negotiation process can be repeated, or the encoder negotiation can no longer be performed.

[0222] Since the third command is sent by the mobile phone to the Bluetooth headset when the mobile phone informs the Bluetooth headset that it does not support encoder negotiation, in this abnormal situation, the Bluetooth headset will return an AT command that does not comply with the HFP regulations to the mobile phone, that is, the fourth command. After receiving the fourth command, because the fourth command does not comply with the HFP regulations, the mobile phone can return an error indication (such as an ERROR command) to the Bluetooth headset to indicate that the encoder negotiation failed, that is, S1007 is executed after S1005. At this time, it indicates that the encoder negotiation between the mobile phone and the Bluetooth headset has failed, and the subsequent SCO link is no longer established.

[0223] S1006. The Bluetooth headset receives a first command from the mobile phone, and sends a second command to the mobile phone in response to the first command.

[0224] The second command is an AT command.

[0225] It is normal for the Bluetooth headset to receive the first command, so at this time the Bluetooth headset can determine the content of the second command according to whether the Bluetooth headset supports the encoding method indicated by the first command.

[0226] Generally, the Bluetooth headset supports the MSBC encoding indicated by the first command, so the second command can be specifically the AT command AT+BCS=2. That is, the second command instructs the Bluetooth headset to determine to use the MSBC encoding with the encoder identifier 2 as the encoding method used when the electronic device and the Bluetooth headset perform real-time audio data transmission.

[0227] Of course, in some special cases, if the Bluetooth headset does not support the MSBC encoding indicated by the first command, the Bluetooth headset can send an AT+BAC command indicating other encoding methods to the mobile phone. After receiving the AT+BAC command, the mobile phone performs subsequent actions according to a predetermined rule. In this case, the specific action of the mobile phone can be determined according to the actual situation, and this application does not provide specific examples and limitations for this.

[0228] After the mobile phone receives the second command from the Bluetooth headset, the mobile phone can determine that the encoder negotiation is successful, and then send a success indication (such as an OK command) to the Bluetooth headset to indicate that the encoder negotiation is successful, that is, S1008 is executed after S1006.

[0229] S1007. The mobile phone receives a fourth command from the Bluetooth headset, and returns an error indication to the Bluetooth headset in response to the fourth command.

[0230] The error indication is used to indicate that the encoder negotiation fails.

[0231] If the encoder negotiation fails, the mobile phone cannot establish a SCO link with the Bluetooth headset. After that, the mobile phone cannot make voice calls through the Bluetooth headset, but uses its own speakers to play the audio data during the voice call.

[0232] In some embodiments, in order to avoid the user having to wait for the Bluetooth headset to play the real-time audio data of the voice call, when the mobile phone returns an error indication to the Bluetooth headset, the mobile phone can output a prompt message to remind the user that the Bluetooth headset cannot be used for the voice call, such as outputting "The headset cannot be used for calls at the moment, please use the mobile phone to answer the call!" in audio or text format. Furthermore, the mobile phone can also send the prompt message to the Bluetooth headset so that the Bluetooth headset plays the prompt message in audio format to remind the user.

[0233] S1008. The mobile phone receives a second command from the Bluetooth headset, and returns a success indication to the Bluetooth headset in response to the second command.

[0234] The success indication is used to indicate that the encoder negotiation is successful.

[0235] Reference Fig.10 As shown, when the mobile phone negotiates successfully with the Bluetooth headset encoder, the mobile phone can start to establish a SCO link with the Bluetooth headset. That is, synchronous connection setup is performed. After the SCO link is successfully established, it can be determined that the encoder connection is established. After that, the mobile phone can make a voice call through the Bluetooth headset, that is, the real-time audio data during the voice call is transmitted between the mobile phone and the Bluetooth headset, and the real-time audio data transmitted to the mobile phone is played through the Bluetooth headset, and the real-time audio data that needs to be transmitted to the other end of the voice call (that is, other electronic devices that establish a voice call connection with the mobile phone) is collected.

[0236] In addition, in practice, after the mobile phone and the Bluetooth headset establish a SCO link, the Bluetooth chip in the mobile phone will send a notification of successful SCO link establishment to the corresponding Bluetooth host in the mobile phone (specifically, it can refer to the host control interface); at the same time, the Bluetooth chip in the Bluetooth headset will send a notification of successful SCO link establishment to the corresponding Bluetooth host in the Bluetooth headset (specifically, it can refer to the host control interface). This notification can be specifically called The presence of a new connection is notified.

[0237] Based on the technical solution provided in the embodiment of the present application, when the electronic device informs the Bluetooth headset that it does not support Codec negotiation during the HFP connection establishment process because the Bluetooth headset is in the Codec negotiation blacklist, the electronic device can also normally send the correct AT command (i.e., the first command: +BCS2) to the Bluetooth headset. Then, the Bluetooth headset can reply with a high probability to the AT command (specifically the AT+BAC command) that complies with the HFP regulations, so that the coding negotiation between the electronic device and the Bluetooth headset before establishing the SCO link is successfully completed, and the SCO link can be further established. After that, the electronic device can also smoothly make voice calls through the Bluetooth headset, avoiding the problem in the prior art that the electronic device cannot make voice calls through the Bluetooth headset because the Bluetooth headset is in the Codec negotiation blacklist, thereby ensuring the user experience.

[0238] In practice, in addition to the situation that the Bluetooth call device (such as a Bluetooth headset) is in the Codec negotiation blacklist, which causes the electronic device to be unable to establish a SCO link with the Bluetooth call device, and then cannot make a voice call through the Bluetooth call device, there are other possible reasons that may cause the electronic device to be unable to establish a SCO link with the Bluetooth call device. At the same time, most electronic devices that can make voice calls through Bluetooth child call devices do not support the SWB feature. Based on this, in order to solve the problem that the electronic device cannot establish a SCO link with the Bluetooth call device due to other possible reasons, and then cannot make a voice call through the Bluetooth call device. After the electronic device and the Bluetooth call device have established an SLC connection, when there is a call demand, the electronic device does not receive the AT+BAC command, and the Bluetooth call device supports the SWB feature, and the Bluetooth call device is not in the Codec negotiation blacklist, and the electronic device supports the SWB feature, the electronic device will send +BCS3 to the Bluetooth call device, which will cause the SCO link to fail to be established. In other cases, the electronic device will send +BCS2 (or a similar AT command) to the Bluetooth call device, which can enable the SCO link to be established normally.

[0239] Based on this, in some embodiments, combined with Fig.10 In the example shown, the preset condition may also include: the electronic device supports the SWB feature. In this case, for example, Fig.10 The code segments corresponding to S1002 and S1003 can be shown as follows: 514void bta_ag_rfe_open(tBTA_AG_SCB*p_scb,const tBTA_AG_DATA&data)

[0240] 515 / *initialize AT feature variables* /

[0241] 516p_scb->clip_enabled=false;

[0242] 517p_scb->ccwa_enabled=false;

[0243] 518p_scb->cmer_enabled=false:

[0244] 519p_scb->cmee_enabled=false;

[0245] 520p_scb->inband enabled=

[0246] 521((p_Scb->features&BTA_AG_FEAT_INBAND)==BTA_AG_FEAT_INBAND);

[0247] 522if(p_scb->con_service==BTA_AG_HFP){

[0248] 523size_t version_value_size=sizeof(p_scb->peer_version)

[0249] 524if(!btif_config_get_bin(

[0250] 525 p_scb->peer_addr.ToString(),HFP_VERSION_CONFIG_KEY, 526 (uint8_t*)&p_scb->peer_version,&version_walue_size)){

[0251] 527APPL_TRACE_WARNING("%s:Failed read cached peer HFP version for%s”,528__,func__,ADDRESS_TO_LOGGABLE_CSTR(p_scb->peer addr));529p_scb->peer_version=HFP_HSP_VERSION_NKNOWN;

[0252] 530}

[0253] 531size_t sdp_features_size=sizeof(p_scb->peer_sdp_features);

[0254] 532if(btif_config_get_bin(

[0255] 533 p_scb->peer_addr.ToString(),HFP_SDP_FEATURES_CONFIG_KEY, 534 (uint8 t*)&p_scb->peer_sdp_features,&sdp_features_size)){

[0256] 535bool_sdp_wbs_support=p_scb->peer_sdp_features&BTA_AG_FEAT_WBS_SUPPO RT;

[0257] 536 / *DTS2018071302731h00385336 20180717begin* /

[0258] 537if(!p_scb->received_at_bac&&sdp_wbs_support538&&!HwInteropMatch(INTEROP_DISABLE_AG_FEATURE_CODEC_NEG,&(p_scb->peer_addr))){

[0259] 539 / *DTS2018071302731h00385336 20180717end* /

[0260] 540p_scb->codec_updated=true;

[0261] 541p_scb->peer_codecs=BTM_SCO_CODEC_CVSD|BTM_SCO_CODEC_MSBC;

[0262] 542p_scb->sco_codec=BTM_SCO_CODEC_MSBC:

[0263]

[0264] 544bool sdp_swb_support=p_scb->peer_sdp_features&BTA_AG_FEAT_SWB_SUPPORT; 545if(!p_scb->received_at_bac&&sdp_swb_support546 / *DT82023122240213100017664 20231227begin* /

[0265] 547&&! HwInteropMatch(INTEROP_DISABLE_AG_FEATURE_CODEC_NEG,&(p_scb->peer_addr))

[0266] 548&&hfp_hal_interface::get_gw_supported()){

[0267] 549 / *DTS2023122240213 100017664 20231227end* /

[0268] 550p scb->codec updated=true;

[0269] 551p_scb->peer codecs=BTH SCO CODEC LC3;

[0270] 552p scb->sco codec=BTH SCO CODEC LC3;

[0271] 553}

[0272] Among them, the content of line 548 is "and the electronic device supports SWB features".

[0273] In this way, for the situation where the electronic device cannot make a voice call through the Bluetooth device due to other reasons other than the reason that the non-Bluetooth device (such as a Bluetooth headset) is in the Codec negotiation blacklist, the electronic device can send the correct AT command to the Bluetooth device when negotiating the coder with the Bluetooth device. After that, the electronic device can successfully establish a SCO link with the Bluetooth device, so that the voice call can be made through the Bluetooth device, avoiding the problem in the prior art that the electronic device cannot make a voice call through the Bluetooth headset due to other reasons, and ensuring the user experience.

[0274] It is understandable that, in order to realize the above functions, the above electronic device includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should easily realize that, in combination with the units and algorithm steps of each example described in the embodiments disclosed herein, the embodiments of the present invention can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the embodiments of the present application.

[0275] The embodiment of the present application can divide the functional modules of the above-mentioned electronic device according to the above-mentioned method example. For example, each functional module can be divided corresponding to each function, or two or more functions can be integrated into one processing module. The above-mentioned integrated module can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of modules in the embodiment of the present invention is schematic and is only a logical function division. There may be other division methods in actual implementation.

[0276] The present application also provides an electronic device, which includes: a display screen, a memory and one or more processors; the display screen, the memory and the processor are coupled; wherein the memory stores computer program code, the computer program code includes computer commands, and when the computer commands are executed by the processor, the electronic device executes the communication method provided in the above embodiment. The specific structure of the electronic device can be referred to Figure 7 The structure of the electronic device shown in .

[0277] An embodiment of the present application also provides a computer-readable storage medium, which includes computer commands. When the computer commands are executed on an electronic device, the electronic device executes the communication method provided in the aforementioned embodiment.

[0278] An embodiment of the present application also provides a computer program product, which includes executable commands. When the computer program product is run on an electronic device, the electronic device executes the communication method provided in the above embodiment.

[0279] The present application also provides a chip system, such as Fig.11 As shown, the chip system 1100 includes at least one processor 1101, a memory, and at least one interface circuit 1102. The processor 1101 and the interface circuit 1102 can be interconnected through a line. For example, the interface circuit 1102 can be used to receive signals from other devices (such as target devices). For another example, the interface circuit 1102 can be used to send signals to other devices (such as target devices).

[0280] Exemplarily, the interface circuit 1102 can read the instruction or computer program stored in the memory and send the instruction or computer program to the processor 1101. When the instruction or computer program is executed by the processor 1101, each step of the communication method provided in the above embodiment can be implemented. Of course, the chip system can also include other discrete devices, which is not specifically limited in the embodiment of the present application.

[0281] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0282] In the several embodiments provided in the present application, it should be understood that the disclosed devices / equipment and methods can be implemented in other ways. For example, the device / equipment embodiments described above are only schematic. For example, the division of the modules or units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

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

[0284] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0285] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium, including several commands to enable a device (which can be a single-chip microcomputer, chip, etc.) or a processor (processor) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read only memory (ROM), random access memory (RAM), disk or optical disk and other media that can store program code.

[0286] The above contents are only specific implementation methods of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present application shall be included in the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A communication method, characterized in that: The method comprises: The electronic device establishes a service level connection SLC with the Bluetooth calling device; When there is a need for a voice call, if the preset conditions are not met, the electronic device sends a first command to the Bluetooth call device; the first command is an AT command that complies with the Bluetooth hands-free protocol HFP; the preset conditions include: the electronic device has not received the AT+BAC command, and the Bluetooth call device supports the ultra-wideband voice SWB feature, and the Bluetooth call device is not in the encoder Codec negotiation blacklist; the first command is used to request the use of an encoding method whose encoder identifier is a first preset value, as the encoding method used when the electronic device and the Bluetooth call device perform real-time audio data transmission; wherein, the first preset value is 2, and the encoding method whose encoder identifier is the first preset value is minimum shift keying coding MSBC.

2. The method according to claim 1, characterized in that After the electronic device sends the first command to the Bluetooth calling device, the method further includes: When the electronic device receives the second command from the Bluetooth call device, the electronic device sends a success indication to the Bluetooth call device and establishes a synchronous connection SCO link with the Bluetooth call device; Among them, the second command is used to indicate the encoding method using the encoder identifier as the first preset value as the encoding method used when the electronic device and the Bluetooth call device perform real-time audio data transmission; the success indication is used to indicate that the encoder negotiation is successful; the second command is an AT command that complies with the HFP regulations.

3. The method according to claim 1 or 2, characterized in that: The method further comprises: When there is a need for a voice call, if the preset conditions are met, the electronic device sends a third command to the Bluetooth call device; the third command is used to request the use of an encoding method with an encoder identifier set to a second preset value as the encoding method used when the electronic device and the Bluetooth call device perform real-time audio data transmission; the third command is an AT command that complies with the HFP regulations.

4. The method according to claim 3, characterized in that After the electronic device sends the third command to the Bluetooth calling device, the method further includes: In case that the electronic device receives a fourth command from the Bluetooth calling device, the electronic device sends an error indication to the Bluetooth calling device; The fourth command is a notice AT command that does not comply with the Bluetooth hands-free protocol HFP; the error indication is used to indicate that the encoder negotiation fails.

5. The method according to claim 3, characterized in that: The second preset value is 3, and the encoder identifies that the encoding method of the second preset value is low complexity communication codec LC3.

6. The method according to claim 4, characterized in that In the case where the electronic device sends an error indication to the Bluetooth call device, the method further includes: The electronic device outputs a prompt message; the prompt message is used to indicate that a voice call cannot be made using the Bluetooth calling device.

7. The method according to claim 1, characterized in that The Bluetooth calling device comprises a Bluetooth headset.

8. An electronic device, characterized in that: include: A display screen, a memory and one or more processors; the display screen and the memory are coupled to the processor; wherein the memory stores computer program code, the computer program code includes computer commands, and when the computer commands are executed by the processor, the electronic device executes the communication method as described in any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that: The method comprises a computer command, and when the computer command is executed on an electronic device, the electronic device executes the communication method according to any one of claims 1 to 7.

Citation Information

Patent Citations

  • DE201536A

  • DE202537A

  • DE203539A

  • DE205541A

  • DE209547A