Method and apparatus for managing a call service

Abstract

The application relates to the technical field of electronic products, in particular to a call service management method and device. The method comprises the following steps: in the cooperative processing process of the call service, a host device determines whether a call data transmission abnormality occurs between a hardware abstraction layer and a hardware layer, and if the abnormality occurs, the host device executes relevant management measures on the call service. When the call data transmission abnormality occurs, the user can be informed of the situation in time, so that the situation that the two parties continuously talk when one party cannot receive sound can be avoided, and thus the call quality and user experience can be guaranteed.

Description

Technical Field

[0001] This application relates to the field of electronic product technology, and specifically to a method and apparatus for managing voice call services. Background Technology

[0002] With the development of communication technology, different electronic devices can establish communication connections and share device capabilities to collaboratively process the same service. Device capabilities include, for example, audio, video, printing, and location capabilities. In the collaborative processing of a call, one electronic device (the primary device) can utilize the audio capabilities of another electronic device (the secondary device) to handle the call.

[0003] When the primary device calls upon the audio capabilities of the secondary device to process call data, call data needs to be transmitted between the primary and secondary devices, which may lead to data transmission anomalies. In such cases, the user on the other end may not be able to receive the voice of the user on the primary end, or vice versa.

[0004] In related technologies, when call data transmission anomalies occur, the abnormality may not be detected, making it impossible to take relevant management measures for the call service. Furthermore, users may not be aware of this situation in a timely manner, causing both parties to continue the call even when the other cannot receive sound, impacting call quality and user experience. Therefore, there is an urgent need for a call service management method that can take relevant management measures when call data transmission anomalies occur, thereby improving call quality and user experience. Summary of the Invention

[0005] This application provides a method and apparatus for managing call services, which can identify abnormal call data transmission during the collaborative processing of call services and take corresponding management measures in a timely manner, thereby improving or ensuring the user's call quality and user experience.

[0006] Firstly, a method for managing call services is provided, the method comprising:

[0007] The master device determines whether there is an abnormality in the call data transmission between the hardware abstraction layer and the hardware layer of the master device, and the master device calls the auxiliary device to process the call service to which the call data belongs;

[0008] If any abnormality occurs, relevant management measures will be implemented for the call service.

[0009] In this embodiment, during the collaborative processing of call services, the master device determines whether there is an anomaly in call data transmission between the master device's hardware abstraction layer and hardware layer. If an anomaly occurs, relevant management measures are implemented for the call service. When call data transmission is abnormal, the user can be notified of the situation in a timely manner, thereby preventing the two parties from continuing the call when the other party cannot receive sound, thus ensuring call quality and user experience.

[0010] Optionally, the master device determines whether a call data transmission anomaly occurs between the master device's hardware abstraction layer and hardware layer, including:

[0011] The master device determines whether an anomaly occurs when the hardware abstraction layer writes uplink call data to the hardware layer, and / or, the master device determines whether an anomaly occurs when the hardware abstraction layer reads downlink call data from the hardware layer;

[0012] If an anomaly occurs, it is determined that a communication data transmission anomaly has occurred between the hardware layer and the hardware abstraction layer.

[0013] In this embodiment, the master device determines whether there is a call data transmission anomaly between the hardware layer and the hardware layer by detecting whether an anomaly occurs when the hardware abstraction layer writes uplink call data to the hardware layer, and / or by detecting whether an anomaly occurs when the hardware abstraction layer reads downlink call data from the hardware layer, thereby determining whether there is a call data transmission anomaly between the hardware layer and the hardware abstraction layer. This allows for a more accurate determination of whether call data can be transmitted normally between the hardware abstraction layer and the hardware layer.

[0014] Optionally, the master device determines whether an anomaly occurs when the hardware abstraction layer reads downlink call data from the hardware layer, including:

[0015] When the downlink call data output by the hardware abstraction layer includes a first prompt message, the master device determines that an anomaly has occurred when the hardware abstraction layer reads the downlink call data from the hardware layer.

[0016] The first prompt message is added to the downlink call data by the hardware abstraction layer when it fails to read the downlink call data from the hardware layer.

[0017] In one implementation, when an anomaly occurs in the hardware abstraction layer (HAL) of the master device while reading downlink call data from the hardware layer, it can generate a downlink call data packet with an empty body, add a first prompt message to the header of the downlink call data packet, and then output the downlink call data packet including the first prompt message. The master device can determine whether an anomaly occurred when the HAL read downlink call data from the hardware layer based on the first prompt message in the downlink call data. By notifying the master device of the downlink call data transmission anomaly between the HAL and the hardware layer by adding a first prompt message to the downlink call data, no additional interfaces need to be added to the HAL, thus reducing adjustments to the HAL.

[0018] Optionally, the master device determines whether an anomaly occurs when the hardware abstraction layer writes uplink call data to the hardware layer, including:

[0019] When the downlink call data output by the hardware abstraction layer includes the second prompt information, the master device determines that an anomaly occurred when the hardware abstraction layer writes the uplink call data to the hardware layer.

[0020] The second prompt message is added to the downlink call data by the hardware abstraction layer when writing the uplink call data to the hardware layer fails.

[0021] In one implementation, when an anomaly occurs in the output of uplink call data from the master device's hardware abstraction layer to the slave hardware layer, a second prompt message can be added to the downlink call data, and then the downlink call data including the second prompt message can be output. The master device can determine whether an anomaly occurred when the hardware abstraction layer reads uplink call data from the hardware layer based on the second prompt message in the downlink call data. By adding a second prompt message to the master device to notify it of the uplink call data transmission anomaly between the hardware abstraction layer and the hardware layer, no additional interfaces need to be added to the hardware abstraction layer, thus reducing adjustments to the hardware abstraction layer.

[0022] Optionally, the master device determines whether a call data transmission anomaly occurs between the master device's hardware abstraction layer and hardware layer, including:

[0023] If the hardware abstraction layer fails to output downlink call data read from the hardware layer within a preset time period, the master device determines that there is an abnormal call data transmission between the hardware abstraction layer and the hardware layer.

[0024] In one implementation, if the master device fails to obtain downlink call data from the hardware abstraction layer (HAL) for an extended period during the process of acquiring downlink call data, it can be determined that the transmission of downlink call data between the HAL and the hardware layer is abnormal. For example, when acquiring downlink call data from the HAL, the master device starts a timer after acquiring each downlink call data packet. If the timer duration is less than or equal to a preset duration, and the next downlink call data packet is acquired, the timer restarts. If the timer duration exceeds the preset duration, and the next downlink call data packet is not acquired from the HAL, it is determined that the HAL cannot acquire downlink call data from the hardware layer. In this case, it can be determined that the transmission of downlink call data between the HAL and the hardware layer is abnormal.

[0025] In this embodiment, the master device directly determines whether downlink call data can be output normally from the hardware abstraction layer. When downlink call data cannot be output normally from the hardware abstraction layer, it is determined that the transmission of downlink call data between the hardware abstraction layer and the hardware layer is abnormal. This allows for a quick and simple determination of whether downlink call data can be transmitted normally between the hardware abstraction layer and the hardware layer.

[0026] Optionally, when the hardware abstraction layer fails to write uplink call data to the hardware layer, the hardware abstraction layer stops outputting the downlink call data.

[0027] In one implementation, the hardware abstraction layer can stop outputting downlink call data when it fails to write uplink call data to the hardware layer. Correspondingly, if the hardware abstraction layer does not output downlink call data within a preset time period, the master device determines that the call data transmission between the hardware abstraction layer and the hardware layer is abnormal.

[0028] In this embodiment, the hardware abstraction layer stops outputting downlink call data when it fails to write uplink call data to the hardware layer. This can convert the case of abnormal uplink call data transmission into a case of abnormal downlink call data transmission, thus avoiding sending relevant information to the coordination module and avoiding adjustments to the hardware abstraction layer.

[0029] Optionally, the management measures include: switching the call service to the main device for processing, or terminating the call service.

[0030] In this embodiment, when a data transmission anomaly occurs between the hardware abstraction layer and the hardware layer of the primary device, the call service is switched to the primary device for processing or the call service is terminated. After the call service is switched to the primary device, call data does not need to be transmitted between the hardware layer and the hardware abstraction layer, and the call service can be processed normally on the primary device. This not only allows users to continue receiving calls through the primary device, but also alerts users that calls cannot be received normally through the secondary device, preventing both parties from continuing the call when the other party cannot receive sound, thereby improving call quality and user experience.

[0031] Similarly, when a data transmission anomaly occurs between the hardware abstraction layer and the hardware layer of the main device, the call service is terminated directly. This can prevent the two parties from continuing the call when the other party cannot receive sound, thereby improving call quality and user experience.

[0032] Optionally, the management measures include: notifying the user that the call service is abnormal.

[0033] In this embodiment of the application, when the transmission of call data between the hardware layer and the hardware abstraction layer of the master device is abnormal, resulting in call service abnormality, the master device can notify the user of the call service abnormality, so that the user can be aware of the abnormal call data transmission. This can prevent the user from continuing to make a call when the other party cannot receive the sound, thereby improving or ensuring the user's call quality and user experience.

[0034] Optionally, the management measures include: sending a notification message to the auxiliary device indicating that the call service is abnormal, so that the auxiliary device notifies the user that the call service is abnormal.

[0035] In this embodiment, when call data transmission between the hardware layer and hardware abstraction layer of the main device is abnormal, causing call service abnormality, the main device sends a notification message to the auxiliary device, which then notifies the user of the service abnormality. Since the user is using the auxiliary device to answer the call, the user can promptly perceive the abnormal call data transmission, thereby preventing the user from continuing the call when the other party cannot receive sound, thus improving or ensuring the user's call quality and user experience.

[0036] Secondly, a call service management device is provided, the device comprising:

[0037] The determination module is used by the main device to determine whether there is an abnormality in the call data transmission between the hardware abstraction layer and the hardware layer of the main device. The main device calls the auxiliary device to process the call service to which the call data belongs.

[0038] The execution module is used to perform relevant management measures on the call service if an abnormality occurs.

[0039] Optionally, the determining module includes:

[0040] The first determining unit is used by the master device to determine whether an abnormality occurs when the hardware abstraction layer writes uplink call data to the hardware layer, and / or, the master device to determine whether an abnormality occurs when the hardware abstraction layer reads downlink call data from the hardware layer.

[0041] The second determining unit is used to determine, if an anomaly occurs, that a communication data transmission anomaly has occurred between the hardware layer and the hardware abstraction layer.

[0042] Optionally, the first determining unit is specifically used to determine that an anomaly occurred when the hardware abstraction layer reads the downlink call data from the hardware layer when the first prompt information is included in the downlink call data output by the hardware abstraction layer; wherein, the first prompt information is added to the downlink call data by the hardware abstraction layer when it fails to read the downlink call data from the hardware layer.

[0043] Optionally, the first determining unit is specifically used to determine that an anomaly occurred when the hardware abstraction layer writes the uplink call data to the hardware layer when the downlink call data output by the hardware abstraction layer includes the second prompt information; wherein the second prompt information is added to the downlink call data by the hardware abstraction layer when it fails to write the uplink call data to the hardware layer.

[0044] Optionally, the determining module is specifically used to determine that there is an abnormal call data transmission between the hardware abstraction layer and the hardware layer when the hardware abstraction layer does not output downlink call data read from the hardware layer within a preset time period.

[0045] Optionally, when the hardware abstraction layer fails to write uplink call data to the hardware layer, the hardware abstraction layer stops outputting the downlink call data.

[0046] Optionally, the management measures include: switching the call service to the main device for processing, or terminating the call service.

[0047] Optionally, the management measures include: notifying the user that the call service is abnormal.

[0048] Optionally, the management measures include: sending a notification message to the auxiliary device indicating that the call service is abnormal, so that the auxiliary device notifies the user that the call service is abnormal.

[0049] Thirdly, an electronic device is provided, comprising: one or more processors and one or more memories; the one or more processors being coupled to the one or more memories, the one or more memories being used to store computer program code, the computer program code including computer instructions, which, when executed by the one or more processors, cause the electronic device to perform the method as described in the first aspect.

[0050] Fourthly, a readable storage medium is provided, wherein a computer program product is stored therein, the computer program product including computer instructions that, when executed on an electronic device, cause the electronic device to perform the method as described in the first aspect.

[0051] Fifthly, a chip system is provided, the chip system being applied to an electronic device, the chip system including one or more processors, the processors being configured to invoke computer instructions to cause the electronic device to perform the method as described in the first aspect.

[0052] In a sixth aspect, a computer program product is provided, including computer instructions that, when executed on an electronic device, cause the electronic device to perform the method as described in the first aspect. Attached Figure Description

[0053] Figure 1 A schematic diagram of the structure of a collaborative system provided in an embodiment of this application is shown.

[0054] Figure 2 A schematic diagram of the architecture of an electronic device provided in an embodiment of this application is shown.

[0055] Figure 3 This illustration shows an interactive diagram of an audio capability invocation process provided in an embodiment of this application.

[0056] Figure 4 This illustration shows a schematic diagram of call data transmission according to an embodiment of this application.

[0057] Figure 5 This illustration shows another schematic diagram of call data transmission provided in an embodiment of this application.

[0058] Figure 6 This illustration shows a schematic diagram of a call data transmission anomaly provided in an embodiment of this application.

[0059] Figure 7 This illustration shows another abnormal call data transmission provided in an embodiment of this application.

[0060] Figure 8 A schematic diagram of the hardware structure of an electronic device suitable for the above method is shown.

[0061] Figure 9 A flowchart illustrating the steps of a call service management method provided in an embodiment of this application is shown.

[0062] Figure 10 The illustration shows a flowchart of a call service management method provided in an embodiment of this application.

[0063] Figure 11 This document illustrates a flowchart of another call service management method provided in an embodiment of this application.

[0064] Figure 12 A structural block diagram of an enabling device for device capability provided in an embodiment of this application is shown.

[0065] Figure 13 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0066] The technical solutions of this application will now be described with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them.

[0067] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0068] The term "comprising" in this document indicates the presence of the described feature, whole, step, operation, element, and / or component, but does not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components, and / or collections thereof. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0069] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of embodiments of this application, unless otherwise stated, "a plurality of" means two or more.

[0070] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0071] The term "embodiment" as used herein means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0072] Figure 1 This diagram illustrates the structure of a collaborative system according to an embodiment of this application. The system includes a master device and an auxiliary device. The auxiliary device has audio capabilities. The master device can initiate a call service and utilize the audio capabilities of the auxiliary device to process the call. Figure 1 As shown, the main device can be a mobile phone 1, and the auxiliary device can be a tablet computer 2.

[0073] The primary device can also be other electronic devices capable of initiating call services, such as smartwatches and tablets that support call services, but is not limited to these. The secondary device can also be other electronic devices with audio capabilities, such as laptops, smart screens, personal computers (PCs), ultramobile personal computers (UMPCs), handheld computers, netbooks, smart home devices, personal digital assistants (PDAs), wearable devices, and in-vehicle devices, but is not limited to these.

[0074] In a collaborative system, master and slave devices can securely share data after mutual authentication. The process of mutual trust and recognition between master and slave devices can refer to relevant technologies. For example, it can be determined based on one or more of the following: whether the master and slave devices are logged into the same system account, whether authorization has been granted, and whether near-field communication is used. The specifics will not be elaborated here.

[0075] Based on data sharing between the primary and secondary devices, after initiating a call service, the primary device can utilize the secondary device's audio capabilities to process the call. This means the primary device uses the secondary device's audio capabilities to collaboratively process the call.

[0076] Audio capability, also known as audio function, includes audio playback and audio recording capabilities. An electronic device possesses audio capability when it has hardware modules related to audio playback and recording, along with corresponding software modules. For example, Tablet 2 has a speaker and microphone, and also has software modules related to audio playback and recording; therefore, Tablet 2 has audio capability.

[0077] It should be noted that, for ease of distinction, this embodiment refers to the device providing audio capabilities as the auxiliary device and the device calling the audio capabilities as the primary device. The primary and auxiliary devices can also be referred to by other names; for example, the primary device can also be called the source device or the first device, and the auxiliary device can also be called the target device or the second device. This embodiment does not impose any restrictions on this.

[0078] Figure 2 A schematic diagram of the architecture of an electronic device provided in an embodiment of this application is shown. Figure 2 The left side shows the architecture diagram of the main device, such as mobile phone 1, while the right side shows the architecture diagram of the auxiliary device, such as tablet computer 2.

[0079] Taking a mobile phone as an example, the software part of mobile phone 1 can be divided into the application layer, service layer, device connection layer, device virtualization layer, hardware abstraction layer (HAL) and kernel layer.

[0080] The application layer includes at least one application (APP) package, such as a call application for handling call services. The application layer may also include video applications, navigation applications, etc., but is not limited to these.

[0081] The service layer provides service support for applications in the application layer. For example, for a calling application, the service layer can set up a calling framework and cellular calling services. The calling framework and cellular calling services can provide service support for the calling application, enabling functions such as caller ID, call routing, voicemail, and video conferencing.

[0082] Furthermore, the service layer also includes call continuation services and a collaborative control center. Call continuation services can also be considered business modules. These services and the collaborative control center provide support for the flow of call services between the primary and secondary devices. For example, for call services, the service layer includes a call continuation service. This service connects to the call application and can monitor it. When it detects that the application has initiated a call service, the call continuation service and the collaborative control center can identify the secondary device that supports the call service and interact with the call continuation service on the secondary device to establish a communication connection and collaboratively process the call service.

[0083] The device connectivity layer is used to provide communication support for collaboration between the master device and the auxiliary device, and may include... Figure 2 The device management module, discovery and connection module, data transmission module, and communication module shown are examples, but not limited to these. The functions of each module in the device connection layer can be specifically configured according to requirements, and this embodiment does not impose any restrictions on this.

[0084] The device virtualization layer provides functional support for collaboration between master and slave devices. It can also be called a collaboration module, such as a distributed mobile sensing development platform (DMSDP). A DMSDP can be composed of different virtualization units, for example... Figure 2 The virtualization units shown include audio virtualization, display virtualization, and camera virtualization. These different virtualization units support the sharing of different device capabilities between devices. Specifically, audio virtualization supports the sharing of audio capabilities between the primary and secondary devices. The collaboration module can be located in the framework layer of mobile phone 1.

[0085] The Hardware Abstraction Layer (HAL) provides data support for collaborative modules, enabling them to obtain business data during collaborative processing through interfaces within the HAL. Specifically, the HAL includes an Audio Hardware Abstraction Layer (Audio HAL), which contains software modules supporting audio capability sharing. These software modules can be named virtual audio modules or other names.

[0086] The kernel layer is located between the hardware layer and the HAL (Hardware Algorithm). The kernel layer can contain display drivers, camera drivers, audio drivers, sensor drivers, pulse code modulation (PCM) devices, etc.

[0087] In Linux, all devices are ultimately abstracted into one or more device files that can be accessed by user space. User space processes control the hardware by reading and writing these device files.

[0088] The hardware component in mobile phone 1 includes a hardware layer, which may include multiple different hardware modules, such as speakers, microphones, audio digital signal processing (ADSP), modems, cameras, and displays, but is not limited to these.

[0089] The architecture of the tablet computer 2 and other electronic devices is similar to that of the mobile phone 1, and will not be described in detail here.

[0090] Taking mobile phone 1 as an example, when mobile phone 1 is handling call services independently, it receives downlink call data sent by the other device (another mobile phone) through a modem. The modem transmits the downlink call data to the ADSP, and the ADSP outputs the downlink call data to the speaker for playback. Simultaneously, mobile phone 1 acquires uplink call data through its microphone, inputs the uplink call data to the ADSP, and the ADSP inputs the uplink call data to the modem. The modem then sends the uplink call data to the other device. Uplink and downlink call data are collectively referred to as call data, which is the service data during the call processing.

[0091] Taking the example of mobile phone 1 calling the audio capabilities of tablet computer 2 to handle call services, Figure 3 This diagram illustrates an interactive schematic of an audio capability invocation process provided in an embodiment of this application. After receiving an incoming call notification, the service module of mobile phone 1 can send a simultaneous vibration notification to the service module of tablet computer 2, allowing tablet computer 2 to display the incoming call notification simultaneously with mobile phone 1. Upon receiving an answer operation, tablet computer 2 can execute step 31, sending a handover request to mobile phone 1.

[0092] After receiving the switching request, the service module of mobile phone 1 executes step 32, sending an enable command to the collaboration module to enable the audio capabilities of tablet computer 2, thus making the audio capabilities of tablet computer 2 usable. Simultaneously, a control channel is established between mobile phone 1 and tablet computer 2. The specific enabling process can be configured according to requirements; this embodiment does not impose any limitations on it.

[0093] After enabling the audio capabilities of tablet 2, the mobile phone 1 service module executes step 33, sending a device switching command to the collaboration module. Correspondingly, the collaboration module executes step 34, sending a path switching command to the virtual audio module.

[0094] Upon receiving the channel switching command, the virtual audio module activates the first and second PCM devices in the kernel layer, switching the ADSP output from the speaker of mobile phone 1 to the first PCM device and switching the ADSP input to the second PCM device. The first PCM device is used to read downlink call data from the ADSP, and the second PCM device is used to write uplink call data to the ADSP.

[0095] Furthermore, the collaborative module of mobile phone 1 can execute step 35 to trigger the communication module to establish a downlink data channel with tablet computer 2. The collaborative module of tablet computer 2 can execute step 36 to trigger the communication module to create an uplink data channel with mobile phone 1.

[0096] Meanwhile, the tablet 2's collaboration module can create audio players (AudioTrack or MediaPlayer), audio recorders (AudioRecord), and audio processors (AudioFlinger).

[0097] After establishing uplink and downlink data channels between mobile phone 1 and tablet computer 2, and switching the output of ADSP to the first PCM device and the input of ADSP to the second PCM device, mobile phone 1 switches the call service to tablet computer 2 and begins to process the call service collaboratively with tablet computer 2.

[0098] Figure 4 This diagram illustrates a call data transmission method according to an embodiment of this application. During the collaborative processing of call services, mobile phone 1 and tablet computer 2 establish a control channel P1, a downlink data channel P2, and an uplink data channel P3 via a communication module. The uplink data channel is used to transmit uplink call data, the downlink data channel is used to transmit downlink call data, and the control channel is used to transmit control information during the collaborative processing of call services.

[0099] During the downlink call data output process, the ADSP obtains the downlink call data sent by the peer device from the modem and inputs the downlink call data into the first PCM device. The virtual audio module can read the downlink call data from the first PCM device and output the downlink call data to the collaboration module of mobile phone 1. The collaboration module of mobile phone 1 sends the downlink call data to the collaboration module of tablet computer 2 through the downlink data channel P2.

[0100] Correspondingly, the collaborative module of tablet PC 2 inputs downlink call data into the audio player, the audio player inputs downlink call data into the audio processor for processing, and the audio processor inputs the processed call data into the speaker of tablet PC 2 for playback output through the audio hardware abstraction layer.

[0101] During the transmission of uplink call data, the audio recorder of tablet PC 2 can obtain uplink call data from the microphone through the audio hardware abstraction layer, and the collaboration module of tablet PC 2 sends the uplink call data to the collaboration module of mobile phone 1 through the uplink data channel P3.

[0102] Correspondingly, the collaborative module of mobile phone 1 outputs the uplink call data to the virtual audio module, the virtual audio module writes the uplink call data to the second PCM device, the second PCM device outputs the uplink call data to the ADSP, the ADSP outputs the uplink call data to the modem, and the modem sends the uplink call data to the peer device.

[0103] Among them, Figure 4In the process, there is a control flow S1 between the service module and the collaboration module of mobile phone 1, and a control flow between the virtual audio module and the ADSP. The service module can input control information to the collaboration module to control its actions, and the virtual audio module can input control information to the ADSP to switch audio channels. Similarly, there is a control flow S2 between the service module and the collaboration module of tablet computer 2, and a control flow between the collaboration module and the audio hardware abstraction layer.

[0104] Figure 5 This illustration shows another schematic diagram of call data transmission provided in an embodiment of this application. During the collaborative processing of call services, the virtual audio module of mobile phone 1 needs to obtain downlink call data from the ADSP through the first PCM device and output uplink call data to the ADSP through the second PCM device. If the first PCM device malfunctions or the downlink audio path between the first PCM device and the ADSP malfunctions, the downlink call data will not be transmitted to tablet computer 2, resulting in no sound output from tablet computer 2. Similarly, if the second PCM device malfunctions or the uplink audio path between the second PCM device and the ADSP malfunctions, the uplink call data will not be output to the ADSP, resulting in no sound output from the other end device.

[0105] Figure 6 This illustration shows a schematic diagram of a call data transmission anomaly provided in an embodiment of this application. Figure 7 This illustration shows another abnormal call data transmission scenario provided in an embodiment of this application. During the collaborative processing of call services, two abnormal situations can occur between the hardware abstraction layer (virtual audio module) and the hardware layer (ADSP) of the master device. The first abnormal situation is an audio path abnormality, i.e. Figure 6 An anomaly occurred at locations 61 and 62 as shown. The second type of anomaly is a PCM equipment malfunction, i.e. Figure 7 Anomalies occurred at locations 71 and 72 as shown.

[0106] An abnormality at position 61 and / or position 71 will result in no sound output from the auxiliary device. An abnormality at position 62 and / or position 72 will result in no sound output from the peer device.

[0107] As shown in Table 1, Table 1 illustrates the above-mentioned abnormal situations and the specific problems caused by each abnormal situation.

[0108]

[0109] Table 1

[0110] Currently, there is no detection method in the relevant technologies to address the aforementioned anomalies. Therefore, during the collaborative processing of call services, when call data transmission between the master device's hardware layer and the HAL is abnormal, the master device may not be able to identify the anomaly, thus preventing it from taking relevant management measures for call services exhibiting such anomalies.

[0111] When the aforementioned anomalies occur in call services, users may not be aware of the situation in a timely manner, causing both parties to continue the call without the other party being able to hear them, thus affecting call quality and user experience. Therefore, there is an urgent need for a call service management method that can take relevant management measures when call data transmission is abnormal due to the above-mentioned anomalies, thereby improving or ensuring user call quality and user experience.

[0112] This embodiment provides a method for managing call services. When the main device and the auxiliary device work together to process call services, the main device monitors the transmission process of call data between the hardware layer and the HAL. When an abnormality is detected in the transmission of call data between the hardware layer and the HAL, and the abnormal situation shown in Table 1 occurs, relevant management measures are implemented for the call service. This can prevent users from continuing to make calls without knowing the situation, thereby improving or ensuring the user's call quality and user experience.

[0113] Figure 8 A schematic diagram of the hardware structure of an electronic device suitable for the above method is shown. The electronic device 8 may include a processor 81, a wireless communication module 82, an audio module 83, a mobile communication module 84, a display screen 85, a storage module 86, and a power supply module 87. The electronic device may also include a microphone 831, a receiver 832, a speaker 833, antennas 1 and 2, as well as a sensor module, a universal serial bus (USB) interface, an external memory interface, buttons, a motor, indicators, a subscriber identification module (SIM) card interface, etc., but is not limited thereto.

[0114] The processor 81 may include one or more processing units. For example, the processor 81 may include at least one of the following processing units: application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, video codec, digital signal processor (DSP), baseband processor, and neural network processing unit (NPU). Different processing units may be independent devices or integrated devices.

[0115] The wireless communication module 82 can provide wireless communication solutions such as wireless local area networks (WLAN), Bluetooth, and near-field communication on the application electronic device 8, but is not limited to these. The wireless communication module 82 can be one or more devices integrating at least one communication processing module. The wireless communication module 82 receives electromagnetic waves via antenna 1, performs frequency modulation and filtering of the electromagnetic wave signal, and sends the processed signal to processor 81. The wireless communication module 82 can also receive signals to be transmitted from processor 81, perform frequency modulation and amplification on them, and then convert the signal into electromagnetic waves for radiation via antenna 1.

[0116] Electronic device 8 can perform audio processing functions, such as audio playback and audio recording, through audio module 83, microphone 831, receiver 832, speaker 833, and application processor.

[0117] The audio module 83 is used to convert an audio stream into an analog sound signal for output, and can also be used to convert an analog sound signal into an audio stream. In some embodiments, the audio module 83 or some functional modules of the audio module 83 may be located in the processor 81.

[0118] The microphone 831, also known as a "microphone" or "voice transducer," is used to convert sound signals into audio streams.

[0119] The receiver 832, also known as the "earpiece," is used to convert audio streams into sound signals. When the electronic device 8 receives a phone call or voice message, the receiver 833 can be brought close to the ear to hear the sound.

[0120] The speaker 833, also known as a "loudspeaker," is used to convert audio streams into sound signals for output. Audio streams, such as those in pulse code modulation (PCM) format, are first decoded by an application in an electronic device to obtain a PCM audio stream when the file is played. This PCM audio stream is then sent to the speaker 833, which converts it into a sound signal for output.

[0121] The mobile communication module 84 can provide second-generation (2G), third-generation (3G), fourth-generation (5G), and fifth-generation (5G) mobile communication solutions for use on the electronic device 8. The mobile communication module 84 may include at least one filter, switch, power amplifier, low-noise amplifier (LNA), etc. The mobile communication module 84 can receive electromagnetic waves via the antenna 2, and perform filtering and amplification on the received electromagnetic waves before transmitting them to the modem processor for demodulation. The mobile communication module 84 can also amplify the signal modulated by the modem processor, and the amplified signal is then converted into electromagnetic waves and radiated out via the antenna 2.

[0122] Electronic device 8 can display images through a GPU, a display screen 85, and an application processor, enabling it to have video playback and image display capabilities. The GPU is a microprocessor for image processing, connected to the display screen 85 and the application processor. The GPU performs mathematical and geometric calculations and is used for graphics rendering. Processor 81 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0123] Storage module 86 is used to store instructions and data; storage module 86 may be, for example, a cache memory. Storage module 86 can store instructions or data that the processor 81 has just used or that are being used repeatedly. If the processor 81 needs to use the instruction or data again, it can directly retrieve it from storage module 86. This avoids repeated accesses, reduces the processor 81's waiting time, and thus improves system efficiency.

[0124] The processor 81 and the storage module 86 can be combined into a single processing device, but more commonly they are independent components. In specific implementations, the storage module 86 can be integrated into the processor 81, or it can be independent of the processor 81.

[0125] The power module 87 is used to provide power to various devices or circuits in the electronic device 8, and may include a charging management unit, a power management unit, and a battery.

[0126] It should be noted that, Figure 8 The connection relationships between the modules shown are merely illustrative and do not constitute a limitation on the connection relationships between the modules of the electronic device 8. Optionally, the modules of the electronic device 8 may also adopt a combination of various connection methods described in the above embodiments. Figure 8 The structure shown does not constitute a specific limitation on electronic device 8. Electronic device 8 may include, but is not limited to, other electronic devices. Figure 8 The components shown may include more or fewer components, or the electronic device 8 may include... Figure 8 The combination of certain components shown, or the electronic device 8, may include... Figure 8 Sub-components of some of the components shown. Figure 8 The components shown can be implemented in hardware, software, or a combination of both.

[0127] Figure 9 This illustration shows a flowchart of a call service management method provided in an embodiment of this application. The method is implemented by a master device and may include:

[0128] Step 91: The master device determines whether there is an abnormality in the communication data transmission between the hardware abstraction layer and the hardware layer of the master device.

[0129] In this context, the primary device calls upon the secondary device to process the call data for the specific call service. This refers to the primary device utilizing the secondary device's audio capabilities to handle the call service.

[0130] like Figure 3 As shown, the abnormal call data transmission between the hardware abstraction layer and the hardware layer refers to the abnormal call data transmission between the virtual audio module of the hardware layer and the ADSP. That is, the uplink call data cannot be transmitted from the virtual audio module to the ADSP, and the downlink call data cannot be transmitted from the ADSP to the virtual audio module.

[0131] In this embodiment, when the main device calls the audio capabilities of the auxiliary device to process call services, it can monitor the transmission process of call data between the hardware layer and the HAL to determine whether there are any abnormalities in the transmission of call data between the HAL and the hardware layer. For example... Figure 3 As shown, the virtual audio module in HAL is responsible for obtaining downlink call data from the ADSP in the hardware layer and outputting uplink call data to ADPS. Therefore, the virtual audio module can determine whether there is an abnormality in call data transmission between the hardware abstraction layer and the hardware layer.

[0132] Optionally, step 81 includes: the master device determining whether an anomaly occurs when the hardware abstraction layer writes uplink call data to the hardware layer, and / or, the master device determining whether an anomaly occurs when the hardware abstraction layer reads downlink call data from the hardware layer; if an anomaly occurs, then it is determined that an anomaly has occurred in the call data transmission between the hardware layer and the hardware abstraction layer.

[0133] The hardware abstraction layer reading downlink call data from the hardware layer refers to the virtual audio module obtaining downlink call data from the ADSP, that is, the virtual audio module obtaining downlink call data from the ADSP through the first PCM device.

[0134] like Figure 4 As shown, during the collaborative processing of call services, the ADSP inputs downlink call data to the first PCM device, and the virtual audio module reads the downlink call data from the first PCM device. When both the first PCM device and the downlink audio path are functioning correctly, the virtual audio module can read the downlink call data from the first PCM device. However, if either the first PCM device or the downlink audio path malfunctions, the virtual audio module cannot read the downlink call data from the first PCM device.

[0135] Therefore, if the virtual audio module fails to read downlink call data from the first PCM device and cannot read the downlink call data, it can be determined that at least one of the first PCM device and the downlink audio path is abnormal, and the downlink call data cannot be transmitted normally from the hardware layer to the HAL. Conversely, if the virtual audio module successfully reads downlink call data from the first PCM device and can read the downlink call data, it can be determined that both the first PCM device and the downlink audio path are normal, and the downlink call data can be transmitted normally from the hardware layer to the HAL.

[0136] Specifically, the virtual audio module resides in the HAL, while the first PCM device resides in the kernel layer. The virtual audio module can call the kernel layer's interface to read downlink call data from the first PCM device. If an error is returned when calling the interface to read downlink call data from the first PCM device, it indicates that reading downlink call data from the first PCM device has failed. This suggests an abnormality in the first PCM device and / or a problem with the downlink audio path, preventing downlink call data from being transmitted normally from the hardware layer to the HAL. Consequently, an error occurs when the HAL reads downlink call data from the hardware layer.

[0137] The writing of uplink call data from the hardware abstraction layer to the hardware layer refers to the virtual audio module outputting uplink call data to the ADSP, that is, the virtual audio module writing uplink call data to the ADSP through the second PCM device.

[0138] Similarly, during the collaborative processing of call services, the virtual audio module obtains uplink call data from the collaborative module, writes the uplink call data to the second PCM device, and the second PCM device outputs the uplink call data to the hardware-level ADSP. When both the second PCM device and the uplink audio path are functioning correctly, the virtual audio module can write the uplink call data to the second PCM device normally. However, if either the second PCM device or the uplink audio path malfunctions, the virtual audio module will be unable to write the uplink call data to the second PCM device.

[0139] like Figure 4 As shown, during the collaborative processing of call services, if the virtual audio module successfully writes uplink call data to the second PCM device, it can be determined that both the second PCM device and the uplink audio path are functioning correctly, and the uplink call data can be transmitted normally from the HAL to the hardware layer. Conversely, if the virtual audio module fails to write uplink call data to the second PCM device, it can be determined that at least one of the second PCM device and the uplink audio path is faulty, and the uplink call data cannot be transmitted normally from the HAL to the hardware layer.

[0140] Specifically, the virtual audio module can call the kernel layer interface to write uplink call data to the second PCM device. If an error is returned when calling the interface to write uplink call data to the second PCM device, it can be determined that the uplink call data writing to the second PCM device has failed, indicating that the second PCM device is malfunctioning and / or the uplink audio path is malfunctioning, and that an exception occurred when HAL was writing uplink call data to the hardware layer.

[0141] In this embodiment, the master device determines whether there is a call data transmission anomaly between the hardware layer and the hardware layer by detecting whether an anomaly occurs when the hardware abstraction layer writes uplink call data to the hardware layer, and / or by detecting whether an anomaly occurs when the hardware abstraction layer reads downlink call data from the hardware layer. This allows for a more accurate determination of whether call data can be transmitted normally between the HAL and the hardware layer, thus enabling a more accurate assessment of whether there is a transmission anomaly between the HAL and the hardware layer.

[0142] Optionally, when the hardware abstraction layer fails to read downlink call data from the hardware layer, it can add a first prompt message to the downlink call data. Correspondingly, when the coordination module determines that the downlink call data includes the first prompt message, it can determine that an anomaly has occurred when the hardware abstraction layer reads the downlink call data from the hardware layer.

[0143] like Figure 4As shown, the virtual audio module can output downlink call data to the collaborative module in the master device. If the virtual audio module fails to read downlink call data from the first PCM device, it can generate a downlink call data packet. The body of the downlink call data packet is empty, and the header can be filled with first indication information.

[0144] The first indication message indicates that downlink call data cannot be transmitted normally from the ADSP in the hardware layer to the virtual audio module in the HAL. The first indication message can be an error code corresponding to the downlink call data transmission anomaly. The specific form of the first indication message can be set according to requirements, and this embodiment does not limit it.

[0145] Correspondingly, the collaboration module can call the interface to obtain downlink call data from the virtual audio module. When the downlink call data is obtained, it can be parsed. If the packet header of the downlink call data includes the first prompt information, it is determined that a transmission abnormality has occurred when the downlink call data is transmitted between the HAL and the hardware layer.

[0146] In this embodiment of the application, when an abnormality occurs when the HAL reads downlink call data from the hardware layer, a first prompt message can be added to the downlink call data packet to indicate that the downlink call data transmission between the HAL and the hardware layer is abnormal.

[0147] Since the virtual audio module resides in the HAL (Hardware Aspect Ratio) and the coordination module resides in the framework layer, the virtual audio module needs a corresponding interface to transmit information to the coordination module. When adding a first notification message to the downlink call data, this message can be transmitted to the coordination module through the interface corresponding to the downlink call data. Therefore, if the virtual audio module notifies the coordination module by adding a first notification message to the downlink call data when it determines that there is an anomaly in the transmission of downlink call data between the HAL and the hardware layer, it is not necessary to add any other interfaces to the HAL, thus reducing adjustments to the virtual audio module.

[0148] Optionally, when the hardware abstraction layer fails to write uplink call data to the hardware layer, it can add a second prompt message to the downlink call data. Correspondingly, when the coordination module determines that the downlink call data includes the second prompt message, it can determine that an anomaly occurred when the hardware abstraction layer wrote uplink call data to the hardware layer.

[0149] Optionally, if the virtual audio module fails to write uplink call data to the second PCM device, it can also generate a downlink call data packet with an empty body and a second indication message added to the header. Alternatively, the second indication message can be added directly to the header of a normal downlink call data packet.

[0150] The second indication information indicates that uplink call data cannot be transmitted normally from the virtual audio module to the hardware-level ADSP. The second indication information may be an error code corresponding to the uplink call data transmission anomaly. The specific form of the second indication information can be set according to requirements, and this embodiment does not limit it.

[0151] Correspondingly, when the collaboration module calls the interface to obtain the downlink call data packet from the virtual audio module, if the header of the downlink call data packet includes the second prompt information, it can be determined that a transmission anomaly occurred when the uplink call data was transmitted between the HAL and the hardware layer.

[0152] In this embodiment, when the HAL fails to write uplink call data to the hardware layer, a second prompt message can be added to the downlink call data packet to indicate that the uplink call data transmission between the HAL and the hardware layer is abnormal. Similarly, by adding a second prompt message to the coordination module to notify it of the downlink call data transmission abnormality between the HAL and the hardware layer, it is not necessary to add other interfaces to the HAL, thus reducing adjustments to the virtual audio module.

[0153] In one implementation, when the virtual audio module fails to read downlink call data from the first PCM and fails to write uplink call data to the second PCM device, it can add a third prompt message to the header of the downlink call data packet. Correspondingly, when the coordination module parses the third prompt message from the packet header, it can determine that neither the downlink nor the uplink call data can be transmitted normally between the HAL and the hardware layer.

[0154] As mentioned above, during collaborative call processing, possible scenarios include: uplink call data failing to be transmitted from the HAL to the hardware layer; downlink call data failing to be transmitted from the hardware layer to the HAL; and both uplink and downlink call data failing to be transmitted from the HAL to the hardware layer. When the collaborative module needs to accurately distinguish between these three scenarios, the first, second, and third prompt messages can be different. Conversely, when the collaborative module does not need to accurately distinguish between these three scenarios, the first, second, and third prompt messages can be the same.

[0155] In one embodiment, the virtual audio module can launch two different sub-threads during runtime. The first sub-thread is responsible for reading downlink call data from the first PCM device, and the second sub-thread is responsible for writing uplink call data to the second PCM device. If the first sub-thread fails to read downlink call data from the first PCM device, it can generate a downlink call data packet with an empty body and add a first prompt message to the packet header.

[0156] When the second sub-thread fails to write uplink call data to the second PCM device, it can send a second prompt message to the first sub-thread. Upon receiving the second prompt message from the second sub-thread, the first sub-thread can also generate a downlink call data packet with an empty body and add the second prompt message to the packet header to send an uplink call data packet including the second prompt message to the coordination module. Alternatively, the first sub-thread can add the second prompt message to the header of a normal downlink call data packet to send it to the coordination module.

[0157] It should be noted that the virtual audio module can also notify the collaboration module of abnormal call data transmission between the HAL and the hardware layer in other ways. For example, an interface can be set in the virtual audio module, and the collaboration module can call the interface to retrieve prompt information from the virtual audio module.

[0158] Step 92: If an anomaly occurs, implement relevant management measures for the call service.

[0159] In this embodiment, when the master device determines that the transmission of call data between the hardware layer and the HAL layer is abnormal, it can perform relevant management measures on the call service. For example, step 92 can be performed by... Figure 4 The business modules shown are implemented.

[0160] Optionally, management measures may include switching call traffic to be processed by the primary device.

[0161] For example, when the coordination module determines that uplink call data transmission between the HAL and the hardware layer is abnormal and / or downlink call data transmission between the HAL and the hardware layer is abnormal, it can send an exception notification to the service module. Correspondingly, after receiving the exception notification, the service module can switch the call service to the master device for processing.

[0162] like Figure 3 As shown, after receiving an exception notification, the service module can execute step 37, inputting a device switching command to the collaboration module. Upon receiving the device switching command, the collaboration module can execute step 38, inputting a path switching command to the virtual audio module. Upon receiving the path switching command, the virtual audio module can execute step 39, closing the control and data channels between mobile phone 1 and tablet computer 2. Simultaneously, the virtual audio module can close the first and second PCM devices, switch the ADSP output to the speaker of mobile phone 1, and switch the ADSP input to the microphone of mobile phone 1. At this time, the call service is switched to mobile phone 1, and the ADSP can input downlink call data into the speaker for playback and obtain uplink call data from the microphone. The specific process of switching the call service to the main device can be set according to requirements; this embodiment does not impose any restrictions on this.

[0163] After switching the call service to mobile phone 1, the service module can execute step 310 to input a stop command to the collaboration module. Correspondingly, after receiving the stop command, the collaboration module can execute step 311 to disable the audio capabilities of tablet computer 2 and stop running after being disabled.

[0164] In this embodiment, when a data transmission anomaly occurs between the hardware abstraction layer and the hardware layer of the primary device, the call service is switched to the primary device for processing. After the call service is switched to the primary device, call data does not need to be transmitted between the hardware layer and the HAL, and the call service can be processed normally on the primary device. This not only allows users to continue receiving calls through the primary device, but also alerts users that calls cannot be received normally through the secondary device, preventing both parties from continuing the call when the other party cannot receive sound, thereby improving call quality and user experience.

[0165] Optionally, management measures may include terminating the call.

[0166] In one implementation, the service module can directly terminate the call service when it determines that there is an anomaly in the transmission of call data between the HAL and the hardware layer. For example, after receiving an anomaly notification from the coordination module, the service module can send a stop command to the coordination module and also send a stop command to the call application.

[0167] Correspondingly, the call application can hang up the phone after receiving a stop command. The collaboration module can stop running after receiving a stop command and send a switching command to the virtual audio module. In response to the switching command, the virtual audio module can turn off the first and second PCM devices, switch the ADSP output to the speaker of phone 1, and switch the ADSP input to the microphone of phone 1.

[0168] In this embodiment, when a data transmission anomaly occurs between the hardware abstraction layer and the hardware layer of the main device, the call service is terminated directly. This avoids the two parties continuing the call when the other party cannot receive sound, thereby improving call quality and user experience.

[0169] Optionally, management measures may include: notifying users of call service anomalies.

[0170] For example, after receiving an exception notification from the collaboration module, the service module can control the display screen of mobile phone 1 to show text and / or image notification information to inform the user that the call service has encountered an error. Alternatively, it can control mobile phone 1 to output a voice prompt to inform the user that the call service has encountered an error. Specific methods for notifying the user may include, but are not limited to, the examples above.

[0171] In this embodiment of the application, when the transmission of call data between the hardware layer and the hardware abstraction layer of the master device is abnormal, resulting in call service abnormality, the master device can notify the user of the call service abnormality, so that the user can be aware of the abnormality in call data transmission, thereby preventing the user from continuing to make a call when the other party cannot receive the sound, thereby improving or ensuring the user's call quality and user experience.

[0172] Optionally, management measures may include: sending a notification message to the auxiliary device indicating a call service anomaly, so that the auxiliary device notifies the user of the call service anomaly.

[0173] In one implementation, when a user is notified of a call service anomaly, the primary device can send a notification message to the secondary device, causing the secondary device to output a notification message to inform the user of the call service anomaly. For example, after receiving an anomaly notification from the collaboration module, the service module of mobile phone 1 can respond to the anomaly notification by sending a notification message to tablet computer 2. Correspondingly, after receiving the notification message, tablet computer 2 can output a notification message to inform the user of the call service anomaly. The method by which tablet computer 2 outputs the notification message can refer to that of mobile phone 1, and this embodiment does not limit it in this way.

[0174] In this embodiment, when call data transmission between the hardware layer and hardware abstraction layer of the main device is abnormal, causing call service abnormality, the main device sends a notification message to the auxiliary device, which then notifies the user of the service abnormality. Since the user is using the auxiliary device to answer the call, the user can promptly perceive the abnormal call data transmission, thereby preventing the user from continuing the call when the other party cannot receive sound, thus improving or ensuring the user's call quality and user experience.

[0175] Figure 10 The illustration shows a flowchart of a call service management method provided in an embodiment of this application.

[0176] Taking the call service as an example, after receiving an incoming call notification, if mobile phone 1 receives a switching request from tablet computer 2, it will execute step 101 to switch the call service to tablet computer 2 for processing.

[0177] After switching the call service to tablet PC 2, the virtual audio module executes steps 102 and 104 to write uplink call data to the second PCM device and determines whether the uplink call data writing has failed. If the uplink call data writing is successful, it returns to step 102; if the uplink call data writing fails, it executes step 106.

[0178] Similarly, after switching the call service to tablet 2, the virtual audio module executes steps 103 and 105 to read downlink call data from the first PCM device and determines whether the downlink call data reading failed. If the downlink call data is read successfully, it returns to step 103; if the downlink call data reading fails, it executes step 106.

[0179] In step 106, if uplink call data writing fails, the virtual audio module generates a downlink call data packet with an empty body and adds a first prompt message to the header of the downlink call data packet. If downlink call data reading fails, the virtual audio module generates a downlink call data packet with an empty body and adds a second prompt message to the header of the downlink call data packet. If both uplink call data writing and downlink call data reading fail, the virtual audio module generates a downlink call data packet with an empty body and adds a third prompt message to the header of the downlink call data packet.

[0180] Next, the downlink call data packet with added prompt information is output from the virtual audio module to the coordination module. When the coordination module detects that the prompt information has been added to the header of the downlink call data packet, it executes step 107 and sends an exception notification to the service module.

[0181] Correspondingly, after receiving the abnormal notification, the business module executes step 108 to take relevant management measures for the call service, such as switching the call service to mobile phone 1 or ending the call service.

[0182] Optionally, if the collaboration module fails to obtain downlink call data from the virtual audio module within a preset time period, it can be determined that the downlink call data is being transmitted abnormally between the HAL and the hardware layer.

[0183] Specifically, if either the first PCM device or the downlink audio path malfunctions, the virtual audio module will be unable to read downlink call data from the first PCM device. In this case, the virtual audio module will be unable to output downlink call data to the coordination module.

[0184] Based on this, if the collaboration module fails to obtain downlink call data from the virtual audio module for an extended period during the process of acquiring downlink call data, it can be determined that there is an anomaly in the transmission of downlink call data between the HAL and the hardware layer. For example, when the collaboration module acquires downlink call data from the virtual audio module, it starts timing after acquiring each downlink call data packet. If the timing duration is less than or equal to a preset duration, and the next downlink call data packet is acquired, the timing restarts.

[0185] If the timing duration exceeds the preset duration and the next downlink call data packet is not obtained from the virtual audio module, it is determined that the virtual audio module cannot obtain downlink call data from the first PCM device. In this case, it can be determined that there is an anomaly in the transmission of downlink call data between the HAL and the hardware layer.

[0186] The preset duration can be set according to the interval between two adjacent downlink call data packets when downlink call data transmission is normal, and the preset duration is longer than the interval between two downlink call data packets.

[0187] In this embodiment, the master device can directly determine whether the downlink call data can be transmitted normally between the HAL and the hardware layer based on the reception status of the downlink call data. Compared with other methods, this avoids the need to adjust the existing software structure.

[0188] Optionally, if the virtual audio module fails to write uplink call data to the second PCM device, it can stop outputting downlink call data to the collaboration module, so that the collaboration module cannot receive downlink call data output by the virtual audio module within a preset time period.

[0189] For example, when reading downlink call data from a first PCM device via a first sub-thread and writing uplink call data to a second PCM device via a second sub-thread, if the second sub-thread fails to write uplink call data to the second PCM device, it can send a write failure notification to the first sub-thread. Correspondingly, upon receiving the write failure notification, the first sub-thread deletes the downlink call data obtained from the first PCM device or does not output downlink call data to the coordination module. In this case, since the coordination module cannot obtain downlink call data from the virtual audio module within a preset time, it can determine that an anomaly occurred during the transmission of call data between the HAL and the hardware layer.

[0190] In this embodiment, when the virtual audio module fails to write uplink call data to the second PCM device, it stops outputting downlink call data to the coordination module. Correspondingly, when the coordination module cannot obtain downlink call data from the virtual audio module, it determines that the call data transmission between the HAL and the hardware layer is abnormal. By converting the uplink call data transmission abnormality into a downlink call data transmission abnormality, it is possible to avoid sending relevant information to the coordination module, thereby avoiding adjustments to the hardware abstraction layer.

[0191] Figure 11 This document illustrates a flowchart of another call service management method provided in an embodiment of this application.

[0192] Taking the call service as an example, after receiving an incoming call notification, if mobile phone 1 receives a switching request from tablet computer 2, it will execute step 111 to switch the call service to tablet computer 2 for processing.

[0193] After switching the call service to tablet PC 2, the virtual audio module executes steps 112 and 114 to write uplink call data to the second PCM device and determines whether the uplink call data writing has failed. If the uplink call data writing is successful, it returns to step 112; if the uplink call data writing fails, it executes step 116.

[0194] Similarly, after switching the call service to tablet 2, the virtual audio module executes steps 113 and 115 to read downlink call data from the first PCM device and determine whether the downlink call data reading failed. If the downlink call data is read successfully, it returns to step 113; if the downlink call data reading fails, it executes step 116.

[0195] In step 116, if uplink call data writing fails, downlink call data output to the coordination module is stopped. Similarly, if downlink call data reading fails, downlink call data output to the coordination module is stopped. Furthermore, if both uplink call data writing and downlink call data reading fail, downlink call data output to the coordination module is stopped.

[0196] Next, if the coordination module does not receive downlink call data within a preset time period, it determines that there is an anomaly in the transmission of call data between the HAL and the hardware layer. At this time, the coordination module can execute step 117 to output an anomaly notification to the service module.

[0197] Correspondingly, after receiving the abnormal notification, the business module executes step 118 to take relevant management measures for the call service, such as switching the call service to the mobile phone or ending the call service.

[0198] In summary, in this embodiment of the application, during the collaborative processing of call services, the master device determines whether a call data transmission anomaly occurs between the master device's hardware abstraction layer and hardware layer. If an anomaly occurs, relevant management measures are implemented for the call service. When a call data transmission anomaly occurs, the user can be promptly notified of the situation, thereby preventing situations where both parties continue the call even when the other party cannot receive sound, thus ensuring call quality and user experience.

[0199] Figure 12 The diagram illustrates a structural block diagram of a device capability enabling device 12 provided in an embodiment of this application. The device 12 may include:

[0200] The determination module 121 is used by the master device to determine whether there is an abnormality in the communication data transmission between the hardware abstraction layer and the hardware layer of the master device, and the master device calls the auxiliary device to process the communication service to which the communication data belongs.

[0201] The execution module 122 is used to perform relevant management measures on the call service if an abnormality occurs.

[0202] Optionally, the determining module 121 includes:

[0203] The first determining unit is used by the master device to determine whether an abnormality occurs when the hardware abstraction layer writes uplink call data to the hardware layer, and / or, the master device to determine whether an abnormality occurs when the hardware abstraction layer reads downlink call data from the hardware layer.

[0204] The second determining unit is used to determine, if an anomaly occurs, that a communication data transmission anomaly has occurred between the hardware layer and the hardware abstraction layer.

[0205] Optionally, the first determining unit is specifically used to determine that an anomaly occurred when the hardware abstraction layer reads the downlink call data from the hardware layer when the first prompt information is included in the downlink call data output by the hardware abstraction layer; wherein, the first prompt information is added to the downlink call data by the hardware abstraction layer when it fails to read the downlink call data from the hardware layer.

[0206] Optionally, the first determining unit is specifically used to determine that an anomaly occurred when the hardware abstraction layer writes uplink call data to the hardware layer when the second prompt information is included in the downlink call data output by the hardware abstraction layer; wherein, the second prompt information is added to the downlink call data by the hardware abstraction layer when it fails to write uplink call data to the hardware layer.

[0207] Optionally, the determination module 121 is specifically used to determine that when the hardware abstraction layer does not output downlink call data read from the hardware layer within a preset time period, the master device determines that there is an abnormal call data transmission between the hardware abstraction layer and the hardware layer.

[0208] Optionally, if the hardware abstraction layer fails to write uplink call data to the hardware layer, the hardware abstraction layer stops outputting downlink call data.

[0209] Optionally, management measures may include: switching the call service to the main device for processing, or terminating the call service.

[0210] Optionally, management measures may include: notifying users of abnormal call service.

[0211] Optionally, management measures include: sending a notification message to the auxiliary equipment indicating a call service anomaly, so that the auxiliary equipment notifies the user of the call service anomaly.

[0212] Figure 13This illustration shows a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device 13, for example... Figure 8 The illustrated electronic device 8 includes a processor 131, a memory 132, a communication interface 133, and a bus 134. The memory 131 stores instructions, and the processor 131 executes the instructions stored in the memory 132. The processor 131, memory 132, and communication interface 133 are interconnected via the bus 134.

[0213] This application also provides a chip system applied to an electronic device, the chip system including one or more processors, the processors being configured to invoke computer instructions to cause the electronic device to perform the method described above.

[0214] This application also provides a computer program product, which includes computer program code that, when executed by a call service management device, implements the method described in any of the method embodiments of this application.

[0215] The computer program product can also be code embedded in a chip. This application does not limit the specific form of the computer program product.

[0216] This application also provides a readable storage medium storing a computer program thereon, which, when executed by a call service management device, implements the methods described in any of the method embodiments of this application. The computer program may be a high-level language program or an executable object program.

[0217] The readable storage medium can be volatile memory or non-volatile memory, or it can include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM).

[0218] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process and technical effects of the above-described apparatus and equipment can be referred to the corresponding processes and technical effects in the foregoing method embodiments, and will not be repeated here.

[0219] In the several embodiments provided in this application, the systems, apparatuses, and methods disclosed can be implemented in other ways. For example, some features of the method embodiments described above can be ignored or not performed. The apparatus embodiments described above are merely illustrative; the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Multiple units or components can be combined or integrated into another system. Furthermore, the coupling between units or components can be direct coupling or indirect coupling, including electrical, mechanical, or other forms of connection.

[0220] It should be understood that in the various embodiments of this application, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0221] In summary, the above description is merely a preferred embodiment of the technical solution of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for managing call services, characterized in that, The method includes: During the process of the primary device calling the secondary device to process the call service, the primary device sends downlink call data packets to the primary device's framework layer through the primary device's hardware abstraction layer. The downlink call data packets are used to carry the downlink call data of the call service, and the framework layer is used to send the downlink call data of the call service to the secondary device. In the event of an anomaly in the data transmission of the call service between the hardware abstraction layer and the hardware layer of the master device, the master device sends a first downlink call data packet to the framework layer through the hardware abstraction layer. The first downlink call data packet includes a prompt message. Upon receiving the first downlink call data packet, the master device performs relevant management measures on the call service through the framework layer.

2. The method as described in claim 1, characterized in that, The method further includes: If an anomaly occurs when the Hardware Abstraction Layer (HAL) writes uplink call data of the call service to the Hardware Layer, and / or if an anomaly occurs when the HAL reads downlink call data of the call service from the Hardware Layer, the master device determines, through the HAL, that the call service data transmission between the Hardware Layer and the Hardware Layer is abnormal.

3. The method as described in claim 2, characterized in that, If there is an anomaly when the hardware abstraction layer reads downlink call data of the call service from the hardware layer, the prompt information in the first downlink call data shall be the first prompt information; In the event of an anomaly when the hardware abstraction layer writes uplink call data of the call service to the hardware layer, the prompt information in the first downlink call data becomes the second prompt information; The first prompt message is different from the second prompt message.

4. The method according to any one of claims 1-3, characterized in that, The header of the first downlink call data packet includes a prompt message indicating that the first downlink call data packet does not carry downlink call data of the call service.

5. The method as described in claim 2, characterized in that, The method further includes: If the hardware abstraction layer fails to read downlink call data from the hardware layer within a preset time period, the master device determines through the hardware abstraction layer that there is an anomaly in the hardware abstraction layer's reading of downlink call data for the call service from the hardware layer.

6. The method as described in claim 4, characterized in that, When the hardware abstraction layer fails to write uplink call data to the hardware layer, the hardware abstraction layer stops outputting downlink call data for the call service.

7. The method according to any one of claims 1-3, 5, and 6, characterized in that, The management measures include: switching the call service to the main device for processing, or terminating the call service.

8. The method according to any one of claims 1-3, 5, and 6, characterized in that, The management measures include: notifying users of the abnormal call service.

9. The method according to any one of claims 1-3, 5, and 6, characterized in that, The management measures include: sending a notification message to the auxiliary device indicating that the call service is abnormal, so that the auxiliary device notifies the user that the call service is abnormal.

10. A device for managing call services, characterized in that, Located in the main equipment, the device includes: The sending unit is used to send downlink call data packets to the framework layer of the main device through the hardware abstraction layer of the main device during the process of the main device calling the auxiliary device to process the call service. The downlink call data packets are used to carry the downlink call data of the call service, and the framework layer is used to send the downlink call data of the call service to the auxiliary device. The sending unit is further configured to, in the event of an abnormal call data transmission of the call service between the hardware abstraction layer and the hardware layer of the master device, send a first downlink call data packet to the framework layer through the hardware abstraction layer, wherein the first downlink call data packet includes a prompt message. The execution module is used to perform relevant management measures on the call service through the framework layer upon receiving the first downlink call data packet.

11. The apparatus as claimed in claim 10, characterized in that, The device further includes: The determination module is configured to determine, in the event that an anomaly occurs when the hardware abstraction layer writes uplink call data of the call service to the hardware layer, and / or when the hardware abstraction layer reads downlink call data of the call service from the hardware layer, that the call service data transmission between the hardware layer and the hardware abstraction layer is abnormal.

12. The apparatus as claimed in claim 11, characterized in that, If there is an anomaly in the downlink call data of the call service read by the hardware abstraction layer from the hardware layer, the prompt information in the first downlink call data shall be the first prompt information; In the event of an anomaly when the hardware abstraction layer writes uplink call data of the call service to the hardware layer, the prompt information in the first downlink call data becomes the second prompt information; The first prompt message is different from the second prompt message.

13. The apparatus as claimed in any one of claims 10-12, characterized in that, The header of the first downlink call data packet includes a prompt message indicating that the first downlink call data packet does not carry downlink call data of the call service.

14. The apparatus as claimed in claim 11, characterized in that, The determining module is further configured to, if the hardware abstraction layer fails to read downlink call data from the hardware layer within a preset time period, determine that there is an anomaly in the hardware abstraction layer reading downlink call data of the call service from the hardware layer.

15. The apparatus as claimed in claim 13, characterized in that, When the hardware abstraction layer fails to write uplink call data to the hardware layer, the hardware abstraction layer stops outputting downlink call data for the call service.

16. The apparatus as described in any one of claims 10-12, 14, and 15, characterized in that, The management measures include: switching the call service to the main device for processing, or terminating the call service.

17. The apparatus as described in any one of claims 10-12, 14, and 15, characterized in that, The management measures include: notifying users of the abnormal call service.

18. The apparatus as described in any one of claims 10-12, 14, and 15, characterized in that, The management measures include: sending a notification message to the auxiliary device indicating that the call service is abnormal, so that the auxiliary device notifies the user that the call service is abnormal.

19. An electronic device, characterized in that, include: One or more processors and one or more memories; the one or more processors are coupled to the one or more memories, the one or more memories being used to store computer program code, the computer program code including computer instructions, which, when executed by the one or more processors, cause the electronic device to perform the method as described in any one of claims 1-9.

20. A readable storage medium, characterized in that, The readable storage medium stores a computer program product, which includes computer instructions that, when executed on an electronic device, cause the electronic device to perform the method as described in any one of claims 1-9.

21. A chip system, characterized in that, The chip system is applied to an electronic device, the chip system including one or more processors, the processors being used to invoke computer instructions to cause the electronic device to perform the method as described in any one of claims 1-9.

22. A computer program product, characterized in that, Includes computer instructions that, when executed on an electronic device, cause the electronic device to perform the method as described in any one of claims 1-9.

Images