A call flow processing method and an electronic device

Abstract

The embodiment of the application provides a call flow processing method and an electronic device, relates to the field of communication, and can effectively improve the call transfer success rate of super incoming calls, solves the problem that when a user continuously and quickly connects a phone, hangs up the phone, and then connects the phone again in the process of using the super incoming call function, the mobile phone cannot normally transmit audio data with other devices due to the fact that a waiting thread is not released in time. The method comprises the following steps: in response to call connection to a cooperative device, an audio channel between the electronic device and the cooperative device is established. In response to the call being hung up, a session identifier corresponding to call information is acquired. The call information is used to indicate audio hardware information occupied by the call and opposite device information of the call. The session identifier is used to indicate a session in the process of call connection to the cooperative device. When the session identifier is valid, the call information is deleted, and a waiting thread is released. The session identifier being valid indicates that the session is in progress. The waiting thread refers to resources occupied by the session.

Description

Technical Field

[0001] This application relates to the field of communications, and more particularly to a call flow processing method and an electronic device. Background Technology

[0002] With the continuous development of electronic technology, users are owning an increasing number and variety of electronic devices. For example, a user may simultaneously own three electronic devices: a mobile phone, a tablet, and a personal computer. In some scenarios, multiple electronic devices owned by a user can form a trust network, allowing devices other than the mobile phone within the network to share the mobile phone's communication capabilities. For instance, after a trust network is established between a user's mobile phone, tablet, and personal computer, the user can answer calls from the mobile phone on the tablet or personal computer, and also make calls from the mobile phone on the tablet or personal computer.

[0003] However, when making or receiving calls on a mobile phone from an electronic device within a trusted network, there may be a problem where the call audio cannot be transferred to that electronic device. Summary of the Invention

[0004] The call flow processing method and electronic device provided in this application embodiment can effectively improve the call transfer success rate of Super Call and solve the problem that when users continuously and quickly connect, hang up and reconnect to the phone while using the Super Call function, the phone cannot transmit audio data normally with other devices because the waiting thread is not released in time.

[0005] To achieve the above objectives, the embodiments of this application adopt the following technical solutions.

[0006] Firstly, a call processing method is provided, applied to the audio hardware abstraction layer in an electronic device. The method includes: in response to a call being connected from an electronic device to a collaborating device, establishing an audio channel between the electronic device and the collaborating device; the audio channel is used to transmit audio data during the call; the collaborating device and the electronic device are on the same trust ring. In response to a call being hung up, obtaining a session identifier corresponding to the call information. The call information indicates the audio hardware information used by the call and the information of the peer device in the call. The session identifier indicates the session in progress during the call connection to the collaborating device. The peer device refers to the device communicating with the electronic device. When the session identifier is valid, deleting the call information and releasing waiting threads. Here, a valid session identifier indicates that a session is in progress. Waiting threads refer to the resources used by the session.

[0007] Based on this solution, electronic devices will clear the waiting thread in the call immediately after it is hung up. This avoids the problem that the phone cannot transmit audio data normally with other devices when the user makes and hangs up the call quickly and continuously while using the Super Call function. This is because the waiting thread is not released in time. This helps to improve the success rate of call transfer in Super Call and improve the user experience.

[0008] In one possible implementation, when the session identifier is valid, call information is deleted and waiting threads are released. This includes: deleting call information and generating a simulated success command when the session identifier is valid. The simulated success command simulates the successful establishment of any channel or the successful configuration of any channel parameter in the audio channel corresponding to the call. The audio channel includes at least a control channel, a downlink data channel, and an uplink data channel. The channel parameters in the audio channel include at least the configuration parameters of the downlink data channel and the configuration parameters of the uplink data channel. The waiting thread is released based on the simulated success command. Based on this scheme, the purpose of releasing waiting threads can be achieved with relatively small resource consumption.

[0009] In one possible implementation, after releasing the waiting thread, the method further includes sending a call cancellation command to the audio virtualization module of the electronic device, instructing the audio virtualization module not to forward the command corresponding to the call. The command corresponding to the call includes commands indicating that any channel in the audio channel corresponding to the call has been successfully established or that any channel parameter has been successfully configured. The audio channel includes at least a control channel, a downlink data channel, and an uplink data channel. The channel parameters in the audio channel include at least the configuration parameters of the downlink data channel and the configuration parameters of the uplink data channel. Based on this scheme, invalid transmission of commands after call cancellation can be avoided, which helps improve command transmission efficiency.

[0010] In one possible implementation, the session during the call connection process from the electronic device to the cooperating device includes at least: a session for establishing a control channel, a session for establishing a downlink data channel, a session for establishing an uplink channel, a session for configuring downlink data channel parameters, and a session for configuring uplink data channel parameters.

[0011] In one possible implementation, the method further includes deleting call information when the session identifier is invalid. An invalid session identifier indicates that the session has ended.

[0012] In one possible implementation, when the session identifier is valid, the method also includes: unloading the driver occupied by the session.

[0013] In one possible implementation, the session identifier includes a field indicating whether the session is valid. When the session identifier is valid, call information is deleted and waiting threads are released, including: deleting call information and releasing waiting threads when the field indicates that the session identifier is valid.

[0014] In one possible implementation, the call is terminated in one of the following ways: receiving a call cancellation instruction; or receiving an instruction to delete call information.

[0015] Secondly, an electronic device is provided, comprising one or more processors, one or more memories, and an audio hardware abstraction layer. The one or more memories are coupled to the one or more processors, the audio hardware abstraction layer is coupled to the one or more processors, and the one or more memories store computer instructions. When the one or more processors execute the computer instructions, the electronic device performs the call processing method as described in the first aspect.

[0016] Thirdly, a computer-readable storage medium is provided, the computer-readable storage medium including computer instructions, which, when executed, perform a call flow processing method as described in any of the first aspects.

[0017] Fourthly, a chip system is provided, the chip including processing circuitry and an interface. The processing circuitry is used to retrieve and execute a computer program stored in a storage medium to perform a call flow processing method as described in any of the first aspects.

[0018] Fifthly, a computer program product is provided, which includes instructions that, when the computer program product is run on a computer, enable the computer to execute a call flow processing method as described in any of the first aspects according to the instructions.

[0019] It should be understood that the technical features of the technical solutions provided in the second, third, fourth and fifth aspects mentioned above can all be corresponded to the call flow processing methods provided in the first aspect and its possible designs. Therefore, the beneficial effects that can be achieved are similar, and will not be elaborated here. Attached Figure Description

[0020] Figure 1 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0021] Figure 2 A schematic diagram of the software architecture of an electronic device provided in an embodiment of this application;

[0022] Figure 3 A schematic diagram illustrating an audio channel establishment process provided in an embodiment of this application;

[0023] Figure 4 A schematic diagram of a call flow provided in an embodiment of this application;

[0024] Figure 5 A schematic diagram of yet another call flow provided in an embodiment of this application;

[0025] Figure 6 A flowchart of a call flow processing method provided in an embodiment of this application;

[0026] Figure 7 A flowchart illustrating another call flow processing method provided in this application embodiment;

[0027] Figure 8 This is a schematic diagram of the composition of a chip system provided in an embodiment of this application. Detailed Implementation

[0028] In this application's embodiments, terms such as "first," "second," and "third" are used to distinguish different objects, not to limit a specific order. Furthermore, words such as "exemplary" or "for example" are used to indicate that something is being described as an example, illustration, or illustration. Any embodiment or design described as "exemplary" or "for example" in this application's embodiments should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0029] To facilitate understanding of the embodiments of this application, the application background of the embodiments of this application will be introduced first.

[0030] With the development of communication technology, multiple electronic devices can form a trust network and work collaboratively based on it. This trust network can include multiple electronic devices such as mobile phones, tablets, personal computers, smart screens, and watches, with trusted connections between them. In some possible implementations, the trust network can also be called a collaborative network, a trust ring, or a MagicRing trust ring.

[0031] In this embodiment of the application, for each electronic device to establish a trust network, each electronic device must simultaneously meet the following conditions:

[0032] Condition 1: All electronic devices communicate with each other via an NFC (near field communication) network or the same Wi-Fi (Wireless Fidelity) network.

[0033] When communication is established through a near-field communication network or the same Wi-Fi, the network latency between electronic devices is lower and the collaboration efficiency is higher.

[0034] Condition 2: All electronic devices log in with the same system account.

[0035] In this embodiment, the system account can be an account provided by the operating system of the electronic device. For example, both electronic device A and electronic device B are powered by operating system S, and the account provided by operating system S is the system account. The account provided by operating system S can be an account registered by the user on the cloud server of operating system S.

[0036] It should be noted that the operating system S of electronic device A and electronic device B can be the same version or different versions. That is to say, the version number of the operating system S of electronic device A and the version number of the operating system S of electronic device B can be different.

[0037] In addition, in this embodiment of the application, the operating system of the electronic device can be an operating system independently developed by the electronic device manufacturer, or it can be an operating system based on an existing operating system (such as...). An operating system developed using a kernel.

[0038] It should be understood that for multiple electronic devices that communicate via an NFC network or the same Wi-Fi, a trusted network can be established after verifying that the logged-in system accounts are the same.

[0039] Electronic devices within the same trusted network have a call synchronization function, which in this embodiment can also be called a "super call." Exemplarily, the trusted network includes three electronic devices: a mobile phone, a tablet, and a personal computer. When a mobile phone receives an incoming call, the tablet and personal computer simultaneously provide call notifications, such as vibration, ringing, or displaying a call notification interface. The user can answer the call on the tablet or personal computer. Similarly, the user can also make calls from the mobile phone on the tablet or personal computer.

[0040] However, in practical applications, when a user makes or receives a call on a mobile device other than their mobile phone within a trusted network and then quickly hangs up, and then makes or receives another call on the same mobile device within the same trusted network, the call audio may not be transferred from the mobile phone to the mobile device making or receiving the call. This can prevent the user from making a normal call and affect their communication experience.

[0041] To address the aforementioned issues, this application provides a call flow processing method and an electronic device that can promptly release thread resources between the mobile phone and the electronic device making or receiving calls when the user hangs up, thereby ensuring that subsequent calls can be normally transferred to the electronic device making or receiving calls.

[0042] The call processing method provided in this application is applied to electronic devices with communication functions within a trusted network. These electronic devices include, but are not limited to, mobile phones, smartwatches, tablets, personal computers, and in-vehicle devices.

[0043] As an example, please refer to Figure 1 This is a schematic diagram of the structure of an electronic device 100 provided in an embodiment of this application. The call processing method provided in this embodiment can be applied to, for example... Figure 1 In the electronic device 100 shown.

[0044] like Figure 1 As shown, the electronic device 100 may include a processor 101, a communication module 102, a display screen 103, an internal memory 104, an audio module 105, a subscriber identification module (SIM) card interface 106, etc.

[0045] The processor 101 may include one or more processing units, such as an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, memory, a video stream codec, a digital signal processor (DSP), a baseband processor, and / or a neural network processing unit (NPU). These different processing units may be independent devices or integrated into one or more processors 101.

[0046] The electronic device 100 implements display functions through a GPU, a display screen 103, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 103 and the application processor. The processor 101 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0047] Display screen 103 is used to display images, video streams, etc.

[0048] The communication module 102 may include a mobile communication module 102A and a wireless communication module 102B. The wireless communication function of the electronic device 100 can be implemented through the mobile communication module 102A, the wireless communication module 102B, a modem processor, and a baseband processor, etc.

[0049] The mobile communication module 102A can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied to the electronic device 100. The mobile communication module 102A may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. In some embodiments, at least some functional modules of the mobile communication module 102A may be housed in the processor 101. In some embodiments, at least some functional modules of the mobile communication module 102A and at least some modules of the processor 101 may be housed in the same device.

[0050] The wireless communication module 102B can provide solutions for wireless communication applications on the electronic device 100, including wireless local area networks (WLAN) (such as Wi-Fi networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), NFC, infrared (IR), and other wireless communication technologies. The wireless communication module 102B can be one or more devices integrating at least one communication processing module.

[0051] In some embodiments, the mobile communication module 102A and wireless communication module 102B of the electronic device 100 enable the electronic device 100 to communicate with networks and other devices via wireless communication technologies. The wireless communication technologies may include Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Time-Division Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technologies, etc.

[0052] The internal memory 104 can be used to store computer executable program code, which includes instructions. The processor 101 executes various functional applications and data processing of the electronic device 100 by running the instructions stored in the internal memory 104. For example, the internal memory 104 can also store one or more computer programs corresponding to the call flow processing method provided in the embodiments of this application. When the processor 101 executes these computer programs, it can implement the call flow processing method provided in the embodiments of this application.

[0053] The audio module 106 can be used to receive sound information or play sound. The audio module 106 may include, but is not limited to, a microphone, a speaker, etc.

[0054] Electronic device 100 can implement audio functions through audio module 106 and application processor, such as music playback, recording, and communication with other electronic devices.

[0055] The SIM card interface 106 is used to connect a SIM card. The SIM card can be inserted into or removed from the SIM card interface to make contact with and detach from the electronic device 100. The SIM card interface supports Nano SIM cards, Micro SIM cards, and other SIM cards. The electronic device 100 interacts with the network through the SIM card to perform functions such as calls and data communication.

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

[0057] The above has been approved. Figure 1 The hardware structure of the electronic device provided in the embodiments of this application is described below, using a layered architecture. Taking the system as an example, the software architecture of the electronic device provided in the embodiments of this application is illustrated.

[0058] Please refer to Figure 2 This is a schematic diagram of the software architecture of an electronic device provided in an embodiment of this application. Figure 2 As shown, the software architecture of the electronic device in this embodiment can be divided into an application layer 201, a service layer 202, a device connection layer 203, a device virtualization layer 204, a hardware abstraction layer (HAL) 205, and a hardware layer 206.

[0059] like Figure 2As shown, application layer 201 may include applications such as an Incall UI program and a contacts application. For example, when an electronic device receives an incoming call, it can launch the Incall UI program to display the incoming call interface to prompt the user to answer the call.

[0060] Service layer 202 provides application programming interfaces (APIs) and programming frameworks for the applications in application layer 201. The service layer includes some predefined functions.

[0061] The programming framework can include the Telecom AOSP (Android Open Source Project) call framework. The Telecom AOSP call framework can be used to manage audio and video calls on electronic devices, such as SIM (subscriber identity module) based calls.

[0062] In addition, service layer 202 may also include APIs for calling Telephony cellular calling services, APIs for calling Profile information services, APIs for calling call continuation services, and APIs for calling the SuperTerminal Control Center. This allows installed applications to call the corresponding APIs or programming frameworks from the service layer to implement the services required by their business needs. Specifically, the call continuation service API is used to continue calls from electronic device 200 to other electronic devices. For example, when the trusted network includes mobile phones and tablets, incoming calls received by the mobile phone can be continued to the tablet via the call continuation service API.

[0063] The device connection layer 203 includes a data transmission module and a connection management module. The data transmission module is used for data transmission between the electronic device 200 and other devices. The connection management module is used to manage the devices connected to the electronic device 200.

[0064] The device virtualization layer 204 can virtualize modules that implement specific functions based on hardware modules. For example, the device virtualization layer may include an audio virtualization module. The audio virtualization module is used to virtualize modules that implement audio functions.

[0065] The Hardware Abstraction Layer 205 provides HALs corresponding to different hardware modules, such as the Audio HAL and the Camera HAL. Figure 2 (not shown in the image), etc. In this way, each HAL can drive the corresponding hardware module to realize the corresponding function of the hardware module.

[0066] For example, hardware layer 206 includes various types of hardware modules, each capable of performing different functions. For instance, hardware layer 206 includes a modem, an audio module, and an audio digital signal processor (ADSP). The modem is used for converting between digital and analog signals. The audio module can be hardware such as a speaker, earpiece, audio system, or HiFi (high-fidelity) audio system. The audio digital signal processor is used to process audio signals.

[0067] It should be noted that the layering of the software architecture of the electronic device in the embodiments of this application is merely exemplary, and other methods can also be used to layer the software architecture of the electronic device, which is not limited in this application.

[0068] For electronic devices in a trust network that lack communication capabilities, their software architecture is similar to the above. Figure 2 Similar. The difference is that electronic devices without communication capabilities do not include the Telecom AOSP calling framework, Telephony cellular calling service, or other calling modules.

[0069] When an electronic device lacking communication capabilities is within the same trusted network as an electronic device possessing such capabilities, the device lacking communication capabilities can share the communication capabilities of the device possessing such capabilities. For example, when a mobile phone and a tablet lacking communication capabilities are within the same trusted network, the tablet can share the mobile phone's communication capabilities. In this way, the user can answer or reject calls from the mobile phone on the tablet, or make calls from the mobile phone on the tablet. The electronic device lacking communication capabilities can also be referred to as a collaborative device.

[0070] For ease of explanation, the following embodiments use a mobile phone as an example of an electronic device with communication capabilities in a trusted network, and a tablet as an example of an electronic device without communication capabilities. It should be understood that the mobile phone in the following embodiments can be replaced by any type of electronic device with communication capabilities, and the tablet can be replaced by any one or more electronic devices of different types, which will not be elaborated further below.

[0071] Regarding the process of a tablet simultaneously notifying a user of an incoming call when the phone receives it, relevant technologies can be referenced, and this application will not elaborate on it. To explain the cause of the technical problem to be solved by the call flow processing method provided in this application, the following describes the process after a user answers a call from a phone on the tablet, or after a call made from a phone on the tablet is connected. For ease of explanation, the following embodiments refer to both the period after a user answers a call from a phone on the tablet and the period after a call made from a phone on the tablet is connected as "after the call is connected." In some possible implementations, "after the call is connected" may also refer to the period after a user answers a call on their phone and then transfers the call to the tablet.

[0072] After a call is connected, an audio channel needs to be established between the mobile phone and the tablet for transmitting audio data during the call. Specifically, this audio channel is used to send the voice heard on the mobile phone during the call to the tablet for the user to listen to; or to send the user's voice heard on the tablet to the mobile phone so that the mobile phone can transmit it to the other party in the call. In this embodiment, the audio channel may include at least three channels: a control channel, a downlink data channel, and an uplink data channel. The control channel can be used to control parameters such as audio volume. The downlink data channel is used to send the voice heard on the mobile phone during the call to the tablet. The uplink data channel is used to send the user's voice heard on the tablet to the mobile phone.

[0073] Please refer to Figure 3 This is a schematic diagram illustrating an audio channel establishment process provided in an embodiment of this application. Figure 3 As shown, when the electronic device with communication capability in the trusted network is a mobile phone and the electronic device without communication capability is a tablet, the process of establishing the audio channel after the call is connected may include the following steps.

[0074] S301, The call module in the mobile phone sends a command to the audio virtualization module to establish a virtual channel.

[0075] The virtualization channel instruction is used to instruct the establishment of a channel for transmitting audio data between the phone and the tablet. This channel can be called a virtual channel or an audio channel. The call module is... Figure 2 The Telecom AOSP call framework and Telephony cellular call service are among the technologies mentioned.

[0076] S302, the audio virtualization module in the mobile phone responds to the received virtual channel establishment instruction by sending a switching call device instruction to the audio HAL.

[0077] The instruction to switch calling devices can specify either the device to be used during a call or to switch the calling device from the mobile phone to another device in a trusted network. This instruction may include the identity identifier of the other device. For example, in this embodiment, the other device could be a tablet or other device within the trusted network where the mobile phone is located.

[0078] For audio virtualization modules and audio HAL, please refer to [link / reference]. Figure 2 The relevant explanations will not be repeated here.

[0079] It's important to note that when a phone receives an incoming call, other electronic devices on the trusted network will simultaneously send a call notification. After the user answers a call on the tablet, the tablet sends an "answered" command to the audio virtualization module in the phone. This command includes the identity (ID) of the receiving device, which is essentially the tablet's identity. When the phone's audio virtualization module receives the command to establish a virtual channel, it can send a "switch call device" command to the audio HAL based on the receiving device's identity. This "switch call device" command will also include the receiving device's identity.

[0080] S303: The audio HAL in the mobile phone generates a control channel establishment command based on the call device switching command.

[0081] The command to establish a control channel can be used to instruct the tablet to establish a control channel between the audio virtualization module in the tablet and the audio HAL in the mobile phone.

[0082] Optionally, after receiving a call device switching instruction, the audio HAL stores the ID of the receiving device in the instruction, i.e., the identity identifier of the aforementioned tablet. Additionally, when the audio HAL generates a control channel establishment instruction, the control channel establishment service begins, and the audio HAL simultaneously generates and stores the service information for establishing the control channel. In this embodiment, the service information refers to the information of the audio hardware used to establish the audio channel. This audio hardware may include a handset, microphone, speaker, etc.

[0083] S304, the audio HAL in the mobile phone will send the control channel establishment command to the audio virtualization module in the mobile phone.

[0084] Correspondingly, the audio virtualization module in the mobile phone receives the command to establish a control channel. Optionally, upon receiving the command from the audio HAL in the mobile phone, the audio virtualization module generates a control channel identifier (session ID). On one hand, the audio virtualization module can return this control channel identifier to the audio HAL in the mobile phone. Thus, the audio HAL in the mobile phone stores at least three pieces of information: the identifier of the receiving device, service information, and the identifier of the control channel. On the other hand, the audio virtualization module can also update the command to establish a control channel based on the identifier, enabling the audio virtualization module in the tablet to establish the control channel corresponding to that identifier. Updating the command based on the identifier can mean adding the identifier to the command itself.

[0085] S305: The audio virtualization module in the mobile phone will send the control channel establishment command to the audio virtualization module in the tablet.

[0086] S306. The audio virtualization module in the tablet establishes a control channel between the tablet's audio virtualization module and the phone's audio HAL according to the control channel establishment instruction. The process of establishing a control channel between the tablet's audio virtualization module and the phone's audio HAL can be referred to relevant technologies, and this application will not describe it in detail.

[0087] As mentioned above, the instructions for establishing a control channel in S305 and S306 may differ from those in S304. For example, the instructions for establishing a control channel in S305 and S306 may include the identity information of the control channel compared to those in S304.

[0088] S307. After successfully establishing the control channel, the audio virtualization module in the tablet sends a completion command to the audio virtualization module in the mobile phone.

[0089] Correspondingly, the audio virtualization module in the phone receives the completion command.

[0090] Optionally, a completion command can be used to indicate that the control channel has been successfully established. The completion command can contain a preset message command, which may not include specific completion information. Alternatively, the completion command may include information indicating that the control channel has been successfully established.

[0091] S308, the audio virtualization module in the mobile phone will send the completion command to the audio HAL in the mobile phone.

[0092] Correspondingly, the audio HAL reception in the mobile phone completes the command.

[0093] Optionally, after receiving the completion command, the audio virtualization module in the mobile phone will also check whether the service information is valid. For example, the audio virtualization module can use a service flag to indicate whether the service information is valid. When the call is not disconnected, the audio virtualization module can set the service flag to true to indicate that the service information is valid. When the call is disconnected, the audio virtualization module can set the service flag to false to indicate that the service information is invalid. In this embodiment, the process of the audio virtualization module setting the service to false can also be referred to as service de-enabling.

[0094] In this embodiment, when the audio virtualization module in the mobile phone receives a completion command and determines that the service information corresponding to the completion command is valid, it will continue to execute the subsequent audio channel establishment steps. If it determines that the service information corresponding to the completion command is invalid, it will stop executing the audio channel establishment steps, that is, it will not send the completion command to the audio HAL in the mobile phone.

[0095] Alternatively, in response to the completion command, the audio HAL in the phone unlocks the current thread in the phone's audio HAL, namely the thread that establishes the control channel, and continues to execute subsequent steps, such as establishing a downlink data path and establishing an uplink data path.

[0096] It should be noted that in this application, the steps of establishing a control channel, establishing a downlink data path, and establishing an uplink data path in the audio HAL of the mobile phone are performed sequentially. The current thread is locked during each step and is only unlocked upon receiving a completion command. For example, the audio HAL in the mobile phone locks its current thread while sending the control path establishment command in S304, and unlocks the current thread after receiving the completion command. During the period the current thread is locked, the audio HAL will not perform subsequent steps to establish the audio channel.

[0097] In some possible implementations, the thread generated when initiating the control channel establishment process can be called a session. The audio HAL in the mobile phone generates a session ID corresponding to this session when initiating the control channel establishment process. When initiating a session, the audio HAL in the mobile phone can set this session ID to a valid state. When receiving a completion command, the audio HAL in the mobile phone can set the session ID to an invalid state. Based on this, it should be understood that the audio HAL in the mobile phone stores at least four types of information: the identity of the receiving device, service information, the identity of the control channel, and the session ID. In this embodiment, locking the thread can refer to locking the resources occupied by the corresponding session, such as channel resources or hardware resources. Unlocking or releasing the thread refers to releasing the resources occupied by the corresponding session.

[0098] Furthermore, the identification, service information, and session identifier of the receiving device stored in the audio HAL of the mobile phone are corresponding. In other words, after determining the identification and service information of the receiving device, the session identifier corresponding to that identification and service information can be uniquely determined.

[0099] S309. Upon receiving the completion command, the audio HAL in the mobile phone generates a downlink channel establishment command.

[0100] This downlink channel establishment command instructs the tablet to establish a downlink data channel between the tablet's audio virtualization module and the audio HAL in the phone.

[0101] S310: The audio HAL in the mobile phone will send the downlink channel establishment command to the audio virtualization module in the mobile phone.

[0102] Correspondingly, the audio virtualization module in the mobile phone receives the instruction to establish a downlink channel.

[0103] S311, the audio virtualization module in the mobile phone sends the downlink channel establishment command to the audio virtualization module in the tablet.

[0104] Similar to the description in S305 above, when the audio virtualization module in the mobile phone receives the downlink channel establishment command, it generates an identity identifier for the downlink data channel. The audio virtualization module returns this downlink data channel identity identifier to the audio HAL in the mobile phone. Thus, the audio HAL in the mobile phone stores at least four pieces of information: the identity identifier of the receiving device, service information, the identity identifier of the downlink data channel, and a session identifier. On the other hand, it updates the downlink channel establishment command based on the downlink data channel identity identifier, enabling the audio virtualization module in the tablet to establish the downlink data channel corresponding to that identity identifier. Updating the downlink channel establishment command based on the downlink data channel identity identifier can mean adding the downlink data channel identity identifier to the downlink channel establishment command.

[0105] S312. The audio virtualization module in the tablet establishes a downlink data channel between the audio virtualization module of the tablet and the audio HAL of the mobile phone according to the downlink channel establishment instruction.

[0106] S313. After successfully establishing the downlink data channel, the audio virtualization module in the tablet sends a completion command to the audio virtualization module in the phone.

[0107] Correspondingly, the audio virtualization module in the phone receives the completion command.

[0108] S314, the audio virtualization module in the mobile phone will send the completion instruction to the audio HAL in the mobile phone.

[0109] Correspondingly, the audio HAL reception in the mobile phone completes the command.

[0110] S315, the audio HAL in the mobile phone responds to the completion command and generates a command to configure downlink channel parameters.

[0111] This downlink channel parameter configuration command instructs the tablet's audio virtualization module to configure audio parameters such as frequency for the downlink data channel.

[0112] It should also be noted that, similar to the description in S307 above, the audio HAL in the phone will lock the current thread when sending the command to establish a downlink channel in S310, and will not unlock the current thread until a completion command is received.

[0113] S316, the audio HAL in the mobile phone sends the configuration downlink channel parameter command to the audio virtualization module in the mobile phone.

[0114] Correspondingly, the audio virtualization module in the mobile phone receives instructions to configure downlink channel parameters.

[0115] S317 The audio virtualization module in the mobile phone sends the configuration downlink channel parameter command to the audio virtualization module in the tablet.

[0116] Correspondingly, the audio virtualization module in the tablet receives instructions to configure downlink channel parameters.

[0117] S318, the audio virtualization module in the tablet configures audio parameters for the downlink data channel according to the downlink channel parameter configuration instruction.

[0118] S319. After successfully configuring the audio parameters for the downlink data channel, the audio virtualization module in the tablet sends a completion command to the audio virtualization module in the phone.

[0119] Correspondingly, the audio virtualization module in the phone receives the completion command.

[0120] The S320 and the audio virtualization module in the mobile phone will send the completion command to the audio HAL in the mobile phone.

[0121] Correspondingly, the audio HAL reception in the mobile phone completes the command.

[0122] S321. Upon receiving the completion command, the audio HAL in the mobile phone generates an uplink channel establishment command.

[0123] The uplink channel establishment command instructs the tablet to establish an uplink data channel between the tablet's audio virtualization module and the audio HAL in the phone.

[0124] Similar to the description in S307 above, when the audio HAL in the mobile phone sends the instruction to configure downlink channel parameters in S316, the current thread will be locked until the completion instruction is received before the current thread is unlocked.

[0125] It should be noted that during the establishment of the downlink data channel, the control channel established in S303 to S308 may fail. Therefore, between S320 and S321, the audio HAL in the mobile phone can also perform a step to determine whether the control channel exists. If the audio HAL in the mobile phone can determine that the control channel already exists, then S321 is executed; if the audio HAL in the mobile phone determines that the control channel does not exist, then the control channel can be established through the same steps as in S303 to S308. This application will not elaborate on this further.

[0126] S322, the audio HAL in the mobile phone sends the uplink channel establishment command to the audio virtualization module in the mobile phone.

[0127] Correspondingly, the audio virtualization module in the mobile phone receives the instruction to establish an uplink channel.

[0128] S323, the audio virtualization module in the mobile phone sends the uplink channel establishment command to the audio virtualization module in the tablet.

[0129] Correspondingly, the audio virtualization module in the tablet receives the uplink channel establishment command. Similar to the description in S305 above, when the audio virtualization module in the phone receives the uplink channel command, it generates an uplink data channel identifier. The audio virtualization module in the phone returns this uplink data channel identifier to the audio HAL in the phone, thus the audio HAL in the phone stores at least four pieces of information: the identifier of the receiving device, service information, the identifier of the uplink data channel, and the session identifier. On the other hand, it updates the uplink channel establishment command based on the uplink data channel identifier, enabling the audio virtualization module in the tablet to establish the uplink data channel corresponding to the identifier of that uplink data channel.

[0130] S324. The audio virtualization module in the tablet establishes an uplink data channel between the audio virtualization module of the tablet and the audio HAL of the mobile phone according to the uplink channel establishment instruction.

[0131] S325. After successfully establishing the uplink data channel, the audio virtualization module in the tablet sends a completion command to the audio virtualization module in the phone.

[0132] Correspondingly, the audio virtualization module in the phone receives the completion command.

[0133] S326, The audio virtualization module in the mobile phone will send the completion instruction to the audio HAL in the mobile phone.

[0134] Correspondingly, the audio HAL reception in the mobile phone completes the command.

[0135] S327. Upon receiving the completion command, the audio HAL in the mobile phone generates a command to configure the uplink channel parameters.

[0136] This uplink channel parameter configuration command instructs the tablet's audio virtualization module to configure audio parameters such as frequency for the uplink data channel.

[0137] Similar to the description in S307 above, when the audio HAL in the phone sends the uplink channel establishment command in S322, the current thread will be locked until the completion command is received before the current thread is unlocked.

[0138] S328, the audio HAL in the mobile phone sends the instruction to configure the uplink channel parameters to the audio virtualization module in the mobile phone.

[0139] Correspondingly, the audio virtualization module in the mobile phone receives instructions to configure the uplink channel parameters.

[0140] S329, The audio virtualization module in the mobile phone sends the configuration uplink channel parameter command to the audio virtualization module in the tablet.

[0141] Correspondingly, the audio virtualization module in the tablet receives instructions to configure the uplink channel parameters.

[0142] The audio virtualization module in the S330 tablet configures audio parameters for the uplink data channel according to the uplink channel parameter configuration instructions.

[0143] S331. After successfully configuring the audio parameters for the uplink data channel, the audio virtualization module in the tablet sends a completion command to the audio virtualization module in the phone.

[0144] Correspondingly, the audio virtualization module in the phone receives the completion command.

[0145] S332, the audio virtualization module in the mobile phone will send the completion instruction to the audio HAL in the mobile phone.

[0146] Correspondingly, the audio HAL reception in the mobile phone completes the command.

[0147] Similar to the description in S307 above, when the audio HAL in the mobile phone sends the instruction to configure uplink channel parameters in S327, it locks the current thread until a completion instruction is received, at which point the current thread is unlocked. It can be seen that in the above audio path establishment process, the completion instruction in each step can be the same. In this embodiment, a locked thread can also be called a waiting thread, and unlocking a locked thread can also be called releasing a waiting thread.

[0148] From a session perspective, the above process can be summarized as follows: When the audio HAL in the phone initiates the process of establishing a control channel, it generates a session identifier 'a' and sets it to a valid state. Upon receiving a completion command, the audio HAL in the phone sets session identifier 'a' to an invalid state and releases the resources occupied by the session corresponding to session identifier 'a' (i.e., unlocks the waiting thread). When the audio HAL in the phone initiates the process of establishing a downlink data channel, it generates a session identifier 'b' and sets it to a valid state. Upon receiving a completion command, the audio HAL in the phone sets session identifier 'b' to an invalid state and releases the resources occupied by the session corresponding to session identifier 'b'. The processes for configuring downlink data channel parameters, establishing uplink data channel, and configuring uplink data channel parameters are similar and will not be elaborated here.

[0149] In this way, an audio channel can be established between the phone and the tablet to transmit audio data during a call. Once the audio channel is successfully established, the user can listen to voice messages received on the phone on the tablet, or send voice messages to the other party in a phone call via the tablet.

[0150] It should be noted that the above-mentioned command transmission between the mobile phone and the tablet can be achieved through... Figure 2 The data transmission module in the device connection layer 203 ( Figure 3 (Not shown in the image) is implemented.

[0151] As can be seen from the above explanation, after a call is connected, there needs to be a period of time to establish an audio channel before the tablet and mobile phone can transmit audio data during the call.

[0152] If a user hangs up the phone before the audio channel is established, and then receives and answers an incoming call, a problem may occur where audio data cannot be transmitted properly between the phone and the tablet; that is, the audio channel may not be established correctly between the phone and the tablet. The following example, where a user hangs up the phone after S305 and before S308 and then answers it, illustrates the cause of this problem. It should be noted that hanging up the phone here can refer to hanging up on the phone, or hanging up the phone on the tablet, or on any electronic device within a trusted network. Answering the phone here refers to answering a call received on the phone on the tablet, or answering a call dialed from the phone on the tablet, or transferring a call answered on the phone to the tablet. This embodiment does not specifically limit this.

[0153] In addition, in the second call connected by the mobile phone in this application embodiment (i.e., the call connected again as mentioned above), the other end device can be the device from the previous call or other devices, and this application does not limit it.

[0154] Please refer to Figure 4This is a schematic diagram of a call flow provided in an embodiment of this application. Figure 4 As shown, when the call ends, the phone's audio virtualization module has already sent a control path establishment command to the tablet's audio virtualization module, but has not yet received a completion command from the tablet's audio virtualization module. The subsequent call process may include the following steps.

[0155] S401, The phone's call module sends a call cancellation command to the phone's audio HAL.

[0156] The call cancellation command indicates that the call has been disconnected. The call can refer to a telephone as described in the previous embodiments.

[0157] Correspondingly, the phone's audio HAL receives the call cancellation command.

[0158] S402. The phone's audio HAL deletes the stored device information and service information based on the call cancellation command.

[0159] The device information may include the identity identifier of the receiving device in the aforementioned embodiments. The service information may refer to the service information for establishing the audio channel in the aforementioned embodiments. In some possible implementations, the audio HAL may also unload the already loaded driver module used for the call when it receives a call command.

[0160] S403, the audio HAL in the phone sends the call cancellation command to the audio virtualization module in the phone.

[0161] Correspondingly, the audio virtualization module in the phone receives the call cancellation command.

[0162] S404, The audio virtualization module in the mobile phone sets the service flag to false.

[0163] As described in the previous embodiments, the audio virtualization module identifies whether the service information is valid by using a service tag, which will not be repeated here.

[0164] It should be understood that after the audio virtualization module in the mobile phone sets the service flag to false, when it receives the completion command sent in S307, since the service flag indicates that the establishment service of the corresponding audio channel has failed, the audio virtualization module in the mobile phone will not send the completion command to the audio HAL in the mobile phone.

[0165] However, as described in the previous embodiment, when the audio HAL in the mobile phone executes the S304 command to send the control path establishment instruction, it locks the current thread. Until a completion instruction is received, the audio HAL in the mobile phone will remain locked. At this time, if the user answers a call, the subsequent call process is as follows.

[0166] S405: Establish a control channel between the mobile phone and the tablet.

[0167] The specific process for establishing a control channel can be found in the relevant descriptions in S303-S308 of the aforementioned embodiments. However, it should be noted that during the establishment of the control channel, when the audio HAL in the phone receives a completion command, it will prioritize unlocking based on that completion command. Figure 4 The thread locked when S304 sends the command to establish a control path.

[0168] Please refer to Figure 5 This is a schematic diagram of another call process provided in an embodiment of this application. Figure 5 As shown, after the call is reconnected, the call process may include the following steps.

[0169] S501, the call module in the mobile phone sends a command to the audio virtualization module to establish a virtual channel.

[0170] Correspondingly, the audio virtualization module in the phone receives virtual channel instructions.

[0171] S502, the audio virtualization module in the mobile phone responds to the received virtual channel establishment instruction by sending a switching call device instruction to the audio HAL.

[0172] Correspondingly, the audio HAL in the mobile phone receives virtual channel commands.

[0173] S503: The audio HAL in the mobile phone generates a control channel establishment command based on the call device switching command.

[0174] S504, the audio HAL in the mobile phone will send the control channel establishment command to the audio virtualization module in the mobile phone.

[0175] Correspondingly, the audio virtualization module in the mobile phone receives the command to establish a control channel.

[0176] S505: The audio virtualization module in the mobile phone will send the control channel command to the audio virtualization module in the tablet.

[0177] Correspondingly, the audio virtualization module in the tablet receives the command to establish a control channel.

[0178] S506: The audio virtualization module in the tablet establishes a control channel between the audio virtualization module of the tablet and the audio HAL of the mobile phone according to the control channel establishment instruction.

[0179] S507. After successfully establishing the control channel, the audio virtualization module in the tablet sends a completion command to the audio virtualization module in the mobile phone.

[0180] Correspondingly, the audio virtualization module in the phone receives the completion command.

[0181] S508, the audio virtualization module in the mobile phone will send the completion command to the audio HAL in the mobile phone.

[0182] Correspondingly, the audio HAL reception in the mobile phone completes the command.

[0183] It should be noted that after receiving the completion command, the audio HAL in the phone will unlock the thread locked in S304 according to the completion command. Thus, the thread locked in S504 remains locked.

[0184] Then, the phone and tablet will go through the process of establishing a downlink data channel.

[0185] S406. Establish a downlink data channel.

[0186] The process of establishing a downlink data channel can be found in the relevant instructions in S309-S314, and will not be repeated here.

[0187] It should be understood that when the audio HAL in the phone receives a completion command corresponding to the successful establishment of the downlink data channel, it will unlock the thread locked in S504 based on the completion command. Therefore, the thread locked by the audio HAL in the phone when sending the downlink channel establishment command remains locked.

[0188] S407. Configure the parameters for the downlink data channel.

[0189] The process of configuring the parameters of the downlink data channel can be found in the relevant instructions in S315-S320, and will not be repeated here.

[0190] It should be understood that when the audio HAL in the phone receives a completion command corresponding to the successful configuration of the downlink data channel parameters, it will unlock the thread that was locked when sending the downlink channel establishment command based on this completion command. Therefore, the thread locked by the audio HAL in the phone when sending the downlink channel parameter configuration command remains locked.

[0191] S408. Establish an uplink data channel.

[0192] The process of configuring the uplink data channel can be found in the relevant instructions in S321-S326, and will not be elaborated here.

[0193] It should be understood that when the audio HAL in the phone receives a completion command corresponding to the successful establishment of the uplink data channel, it will unlock the thread that was locked when sending the command to configure the downlink channel parameters based on this completion command. Therefore, the thread locked by the audio HAL in the phone when sending the command to establish the uplink channel remains locked.

[0194] S409. Configure the parameters for the uplink data channel.

[0195] The process of configuring the parameters of the uplink data channel can be found in the relevant instructions in S327-S332, and will not be elaborated here.

[0196] It should be understood that when the audio HAL in the phone receives a completion command corresponding to the successful configuration of the uplink data channel parameters, it will unlock the thread that was locked when sending the uplink channel establishment command based on this completion command. Therefore, the thread locked by the audio HAL in the phone when sending the uplink channel parameter configuration command remains locked.

[0197] The audio HAL in the phone continuously waits for a completion command to unlock the thread locked when sending the command to configure the uplink channel parameters. However, since the audio channel establishment process is already complete, the audio HAL in the phone will no longer receive a completion command, and this wait will time out (if no completion command is received after 10 seconds, it is considered a timeout). This causes the process of establishing an audio channel between the phone and the tablet to fail, meaning that audio data cannot be transmitted normally between the phone and the tablet.

[0198] From a session perspective, the above process can be summarized as follows: When the audio HAL in the phone initiates the process of establishing a control channel, it generates a session identifier 'a' and sets it to a valid state. If the call is then disconnected and reconnected, the audio HAL in the phone initiates a new process of establishing a control channel, generating a new session identifier 'c' and setting it to a valid state. Upon receiving a completion command, the audio HAL in the phone sets session identifier 'a' (not session identifier 'c') to an invalid state based on this command. In other words, the audio HAL in the phone unlocks the waiting thread from the previous call based on the first completion command in this call, creating an offset between the completion command and the waiting thread. Therefore, when the audio HAL in the phone initiates the process of configuring uplink data channel parameters, the generated session identifier 'd' will remain valid, and the waiting thread generated during the uplink data channel parameter configuration process lacks a completion command to unlock it. Consequently, the session corresponding to session identifier 'd' cannot be completed, causing the process of establishing an audio channel between the phone and the tablet to fail, meaning that audio data cannot be transmitted normally between the phone and the tablet.

[0199] The above explains why audio data cannot be transmitted properly between the phone and tablet when a user repeatedly and rapidly answers, hangs up, and then answers another call on a tablet. Based on the above analysis, the call processing method provided in this application can promptly release all related resources and threads when the user hangs up the call, ensuring the normal progress of subsequent calls.

[0200] It should be noted that the call flow processing method provided in this application embodiment can be applied to the audio HAL in a mobile phone. In other words, the execution subject of the call flow processing method provided in this application embodiment can be the audio HAL in a mobile phone.

[0201] Please refer to Figure 6 This is a flowchart illustrating a call processing method provided in an embodiment of this application. Figure 6 As shown, the method includes the following steps.

[0202] S601. In response to a call being disconnected, obtain the session identifier corresponding to the call information.

[0203] The call information may include device information and service information from the aforementioned embodiments. As described in the previous embodiments, the device information, service information, and session identifier in the audio HAL are in a one-to-one correspondence. In the field of communication, this session identifier can also be called a sessionid. For a description of the device information, service information, and session identifier, please refer to the previous embodiments; further details will not be provided here.

[0204] In addition, in this embodiment of the application, the audio HAL in the mobile phone responding to the call being hung up may mean that the audio HAL in the mobile phone receives a call cancellation instruction, or it may mean that the audio HAL in the mobile phone receives an instruction to delete the call information, or it may mean that the audio HAL in the mobile phone detects that the corresponding service flag for the call is false.

[0205] S602. Determine if the session identifier is valid. If valid, execute S603a; if invalid, execute S603b.

[0206] For example, a session identifier may include a field indicating whether the session identifier is valid, and the specific content of this field can indicate whether the session identifier is valid or invalid. For example, the character 1 indicates that the session identifier is valid, and the character 0 indicates that the session identifier is invalid. As another example, the string "true" indicates that the session identifier is valid, and the string "false" indicates that the session identifier is invalid. Based on this, the audio HAL in the mobile phone can determine whether the session identifier is valid by referring to the specific content of the field indicating whether the session identifier is valid.

[0207] S603a, Delete call information and release waiting thread.

[0208] When the session identifier is valid, the audio HAL in the phone can delete device information and service information, and generate a simulated completion command. This simulated completion command can be the same as the completion command in the aforementioned embodiments. The audio HAL in the phone can release the waiting thread based on this simulated completion command.

[0209] As described in the previous embodiments, the audio HAL release waiting thread in the mobile phone refers to releasing the resources occupied by the session corresponding to the waiting thread. Only after the release is completed can the mobile phone and other devices establish an audio channel normally.

[0210] S603b, Delete call information.

[0211] If the session identifier is invalid, it means that the waiting thread has been released. You can delete the device information and service information in the audio HAL on your phone.

[0212] It should be noted that this method can be used in Figure 4 In step S402, after the audio HAL in the mobile phone receives the call cancellation command and before deleting device and service information, the call flow processing method provided in this application embodiment can be executed synchronously. It should be noted that... Figure 4 This application describes a call flow scenario after a phone call is disconnected during the establishment of a control channel. The call flow processing method provided in this embodiment can also be applied to other scenarios, such as the call flow scenario after a phone call is disconnected during the establishment of a downlink data channel, the configuration of downlink data channel parameters, the establishment of an uplink data channel, or the configuration of uplink data channel parameters on a mobile phone or tablet. These scenarios will not be elaborated upon here.

[0213] Taking the call flow processing method provided in this application embodiment as an example, which is executed in the mobile phone's audio HAL response after receiving the call cancellation command and before deleting device information and service information, the effect of the call flow processing method provided in this application embodiment is explained.

[0214] Please refer to Figure 7 This is a flowchart illustrating another call processing method provided in an embodiment of this application. Figure 7 As shown, the method includes the following steps.

[0215] S701. In response to receiving a call cancellation command, obtain the session identifier corresponding to the call information.

[0216] S702. When the session identifier is valid, delete the call information and release the waiting thread.

[0217] Thus, in Figure 7 In the S307, since the service flag is false, although the audio virtualization module in the phone will not send the completion command to the audio HAL in the phone after receiving the completion command, the waiting thread has been released and will not affect subsequent calls.

[0218] In other words, Figure 7In the S508, when the audio HAL in the phone receives a completion command, it will release the waiting thread established by the S504 based on the completion command, instead of... Figure 5 The waiting thread established during the execution of S304 is released. This ensures that the audio channel between the phone and tablet can be connected normally during subsequent calls, preventing issues such as inability to transmit audio data or failure to transfer calls.

[0219] As can be seen from the above description, the call flow processing method provided in this application embodiment can effectively improve the call transfer success rate of Super Call and solve the problem that when users continuously and quickly connect and disconnect calls while using the Super Call function, the mobile phone cannot transmit audio data normally with other devices because the waiting thread is not released in time.

[0220] Figure 8 A schematic diagram of a chip system 800 is shown. This chip system 800 can be installed in an electronic device, such as a mobile phone. Exemplarily, the chip system 800 may include a processor 801 and a communication interface 802, used to support the electronic device in implementing the functions involved in the above embodiments. In one possible design, the chip system 800 also includes a memory for storing necessary program instructions and data of the electronic device. This chip system can be composed of chips or may include chips and other discrete devices. It should be noted that in some implementations of this application, the communication interface 802 may also be referred to as an interface circuit.

[0221] It should be noted that all relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0222] This application also provides a computer storage medium storing computer instructions. When the computer instructions are executed on an electronic device, the electronic device performs the aforementioned method steps to implement the methods described in the above embodiments.

[0223] This application also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned steps to implement the methods described in the above embodiments.

[0224] In addition, embodiments of this application also provide an apparatus, which may specifically be a chip, component, or module. The apparatus may include a connected processor and a memory; wherein the memory is used to store computer execution instructions, and when the apparatus is running, the processor may execute the computer execution instructions stored in the memory to cause the chip to execute the methods in the above-described method embodiments.

[0225] In this application, the electronic devices, computer storage media, computer program products or chips provided in the embodiments are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0226] The foregoing primarily describes the solutions provided by the embodiments of this application from the perspective of electronic devices. To achieve the aforementioned functions, it includes corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0227] This application embodiment can divide the device involved into functional modules according to the above method examples. For example, each function can be divided into its own functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0228] The functions, actions, operations, or steps in the above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. When implemented using software programs, they can be implemented, in whole or in part, in the form of a computer program product. This computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or include one or more data storage devices such as servers and data centers that can be integrated with the medium. The usable medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)). Although this application has been described in conjunction with specific features and embodiments, it is obvious that various modifications and combinations can be made thereto without departing from the spirit and scope of this application. Accordingly, this specification and drawings are merely exemplary illustrations of this application as defined by the appended claims, and are considered to cover any and all modifications, variations, combinations, or equivalents within the scope of this application. Obviously, those skilled in the art can make various alterations and modifications to this application without departing from the spirit and scope of this application. Thus, if such modifications and modifications of this application fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and modifications.

Claims

1. A call flow processing method, characterized in that, An audio hardware abstraction layer applied in electronic devices; the method includes: In response to a call being connected from the electronic device to a collaborating device, an audio channel is established between the electronic device and the collaborating device; the audio channel is used to transmit audio data during the call; the collaborating device and the electronic device are in the same trust ring. In response to the call being hung up, a session identifier corresponding to the call information is obtained; the call information is used to indicate the audio hardware information used by the call and the peer device information of the call; the session identifier is used to indicate the session in the process of the call being continued to the collaborating device; the peer device refers to the device that is talking to the electronic device. When the session identifier is valid, the call information is deleted and the waiting thread is released; wherein, the valid session identifier indicates that the session is in progress; and the release of the waiting thread means releasing the resources occupied by the session corresponding to the waiting thread.

2. The method according to claim 1, characterized in that, The step of deleting the call information and releasing the waiting thread when the session identifier is valid includes: When the session identifier is valid, the call information is deleted and a simulated success command is generated; the simulated success command is used to simulate the command that any channel in the audio channel corresponding to the call is successfully established or any channel parameter is successfully configured; the audio channel includes at least a control channel, a downlink data channel, and an uplink data channel; the channel parameters in the audio channel include at least: the configuration parameters of the downlink data channel and the configuration parameters of the uplink data channel; The waiting thread is released based on the simulated success instruction.

3. The method according to claim 1, characterized in that, After releasing the waiting thread, the method further includes: A call cancellation command is sent to the audio virtualization module of the electronic device to instruct the audio virtualization module not to forward the command corresponding to the call; the command corresponding to the call includes a command indicating that any channel in the audio channel corresponding to the call has been successfully established or that any channel parameter has been successfully configured; the audio channel includes at least a control channel, a downlink data channel, and an uplink data channel; the channel parameters in the audio channel include at least: configuration parameters of the downlink data channel and configuration parameters of the uplink data channel.

4. The method according to any one of claims 1-3, characterized in that, The sessions during the process of connecting the call to the collaborative device include at least: a session for establishing a control channel, a session for establishing a downlink data channel, a session for establishing an uplink channel, a session for configuring downlink data channel parameters, and a session for configuring uplink data channel parameters.

5. The method according to any one of claims 1-3, characterized in that, The method further includes: If the session identifier is invalid, the call information is deleted; the invalid session identifier indicates that the session has ended.

6. The method according to any one of claims 1-3, characterized in that, When the session identifier is valid, the method further includes: Unload the driver used by the session.

7. The method according to any one of claims 1-3, characterized in that, The session identifier includes a field indicating whether the session is valid; when the session identifier is valid, deleting the call information and releasing the waiting thread includes: When the field indicates that the session identifier is valid, delete the call information and release the waiting thread.

8. The method according to any one of claims 1-3, characterized in that, The call is terminated in any of the following ways: a call cancellation instruction is received; or an instruction to delete the call information is received.

9. An electronic device, characterized in that, The electronic device includes one or more processors, one or more memories, and an audio hardware abstraction layer; the one or more memories are coupled to the one or more processors, the audio hardware abstraction layer is coupled to the one or more processors, and the one or more memories store computer instructions; When the one or more processors execute the computer instructions, the electronic device performs the call flow processing method as described in any one of claims 1-8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes computer instructions that, when executed, perform the call flow processing method as described in any one of claims 1-8.

Images