Audio conflict processing method and apparatus, electronic device, system, and storage medium

Abstract

The application discloses an audio conflict processing method and device, electronic equipment, a system and a storage medium, and belongs to the technical field of terminals. The method comprises the following steps: when it is detected that a user initiates a request instruction of a target service to a second device, the audio priorities of the target service in a first device and the second device are acquired, the audio priorities comprise high priority and low priority; when the audio priority of the target service in at least one of the first device and the second device is low, prompt information of service occupation and a selection control of whether to preempt are displayed on a display interface; and in response to a preempting instruction input by the user clicking the selection control, the enabling of the target service initiated to the second device is completed. In this way, when multiple services are concurrently initiated between interconnected devices, if the audio priority of the service initiated later is lower than the priority of the current service of the device, the ability resources can be dynamically scheduled based on the user demand, and the problem of flexibly processing the audio conflict can be solved.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to an audio conflict handling method, apparatus, electronic device, system, and storage medium. Background Technology

[0002] With the rapid development of terminal technology, interconnection and collaboration among multiple electronic devices such as personal computers (PCs), smartphones, tablets, and smart screens has become a part of modern life; for example, the companion function between PCs and tablets, and screen sharing between smartphones and tablets.

[0003] However, for interconnected applications between multiple devices, in scenarios where multiple services operate concurrently, audio conflicts can easily arise due to the different services' demands for audio resources, leading to service failures. Summary of the Invention

[0004] In view of this, this application provides an audio conflict handling method, apparatus, electronic device, system, and storage medium, which can flexibly schedule audio streams and resolve audio conflict problems when multiple services occur concurrently during the interconnection of multiple devices.

[0005] In a first aspect, an audio conflict handling method is provided, applied to a first device; the method includes: when a user initiates a request instruction for a target service to a second device, obtaining the audio priorities of the target service on the first device and the second device respectively, the audio priorities including high priority and low priority; when the audio priority of the target service corresponding to at least one of the first device and the second device is low priority, displaying a prompt message indicating service occupancy and a selection control for whether to preempt the service on a display interface; and in response to a preemption instruction input by the user clicking the selection control, enabling the initiation of the target service to the second device.

[0006] In this manner, when the first device sends a request command for a target service to the second device, due to the different audio levels corresponding to different services, resource conflicts may occur between different services when multiple services run concurrently on the device. If the priority of the resource required by the later-initiated target service is lower than the audio priority of the current service in the first and / or second devices, it will not directly cause the initiated target service to fail. Instead, it will return a prompt message indicating service occupancy and display a selection control for whether to preempt the service. Upon receiving a preemption command from the user, it will continue to enable the target service. Thus, when multiple services run concurrently between interconnected devices, resource allocation can be dynamically scheduled based on user needs to flexibly handle audio conflicts. This approach offers strong ease of use and practicality.

[0007] In one possible implementation of the first aspect, when a user initiates a request instruction for a target service to the second device, the method further includes: obtaining a first audio priority of the target service on the first device; when the first audio priority is high, obtaining a second audio priority of the target service on the second device; when the second audio priority is high, enabling the initiation of the target service to the second device; or, when the second audio priority is low, displaying a prompt message indicating service occupancy and a selection control for whether to preempt the service on the display interface.

[0008] In one possible implementation of the first aspect, the method further includes: when the first audio priority is low, displaying a prompt message indicating service occupancy and a selection control for whether to preempt the service on the display interface; in response to a preemption command input by the user clicking the selection control, obtaining the second audio priority of the target service on the second device; when the second audio priority is high, enabling the target service to the second device; or, when the second audio priority is low, displaying a prompt message indicating service occupancy and a selection control for whether to preempt the service on the display interface.

[0009] By employing the above method, since the traditional approach of first obtaining the audio priority of the target service on the peer device is time-consuming, this application first determines the audio priority of the target service on the first device, and then determines the audio priority of the target service on the second device. By first obtaining the first audio priority of the target service on the first device, the occupancy status of the local device (first device) and whether the user has preempted the device can be quickly determined, and then the occupancy status of the peer device (second device) can be determined. Therefore, if the local device is found to be occupied, there is no need to determine the occupancy status of the peer device. Furthermore, if the audio priority of the target service is high on the local device or the user chooses to preempt the device on the local device, the occupancy status of the peer device is then determined, and whether preemption is performed if the device is occupied. This approach can shorten the process time and improve the response rate compared to the traditional method.

[0010] In one possible implementation of the first aspect, obtaining the audio priority of the target service on the first device includes: querying the first service status of the first device; when the first service status is occupied, comparing the audio level of the first current service on the first device with the audio level of the target service to determine the audio priority of the target service on the first device; or, when the first service status is unoccupied, determining that the audio priority of the target service on the first device is high priority.

[0011] In one possible implementation of the first aspect, obtaining the audio priority of the target service on the second device includes: sending a query instruction to the second device; the query instruction instructs the second device to query the status of the second service, and when the second service status is occupied, determining the audio priority of the target service on the second device by comparing the audio level of the second current service on the second device with the audio level of the target service, or, when the second service status is unoccupied, determining that the audio priority of the target service on the second device is high priority; and receiving the audio priority of the target service on the second device sent by the second device.

[0012] For example, by using the above query method, in order to improve system response efficiency, the first device can query the audio priority of the target service on the first device and the second device at the same time, or it can query the audio priority of the target service on the first device and the second device separately, such as first querying the occupancy status of the first device and then querying the occupancy status of the second device.

[0013] By using the above method, a query mechanism is provided to determine the audio priority of the target service on the first and second devices. This allows us to confirm the occupancy status of the first and second devices, thereby providing more options for subsequent target services based on business needs and device capabilities. Priority is given to meeting the audio needs of the user's most core business, ensuring efficient system operation and optimized user experience.

[0014] In one possible implementation of the first aspect, obtaining the audio priority of the target service on the first device and the second device respectively includes: determining the audio priority of the target service on the first device and the second device respectively by querying the device management module. The device management module is used to store and synchronize the audio service information of the first device and the second device. The audio service information includes the first service status and audio level of the first device, and the second service status and audio level of the second device.

[0015] Accordingly, after enabling the initiation of the target service to the second device, the method further includes: updating the audio service information of the first device in the device management module, and synchronizing the updated audio service information in the device management module to the second device.

[0016] In this way, the first device can directly obtain the audio priority of the target service corresponding to the first and second devices by querying the device management module. Thus, the first device no longer needs to send a query command to the second device and wait for the second device to query and compare before returning the audio priority. Based on the audio service information of the first and second devices stored in the device management module, the first device can directly query the audio priority corresponding to the target service, improving response efficiency. By storing and synchronizing audio service information through the device management module, the audio occupancy of each electronic device in the system can be understood in real time, thereby making more accurate resource allocation and scheduling decisions faster.

[0017] In one possible implementation of the first aspect, before determining the audio priority of the target service on the first device and the second device by querying the device management module, the method further includes: sending an initialization instruction to the second device, the initialization instruction being used to instruct the second device to update the audio service information in the device management module.

[0018] By performing an initial refresh before querying, the audio service information of each device in the device management module is updated to ensure that the first device can query the most accurate audio service information. This allows for accurate resource allocation and scheduling decisions to be made based on the real-time audio occupancy of each electronic device in the system.

[0019] In one possible implementation of the first aspect, when the audio priority of the target service corresponding to at least one of the first device and the second device is low, a prompt message indicating that the service is occupied and a selection control for whether to preempt the service are displayed on the display interface, including: when the audio priority of the target service is low on the first device and high on the second device, a prompt message indicating that the service is occupied and a selection control for whether to preempt the service are displayed on the display interface.

[0020] Accordingly, in response to the preemption command input by the user clicking the selection control, the enabling of initiating the target service to the second device is completed, including: in response to the preemption command input by the user clicking the selection control, ending the first current service and completing the enabling of initiating the target service to the second device.

[0021] In one possible implementation of the first aspect, when the audio priority of the target service corresponding to at least one of the first device and the second device is low, a prompt message indicating that the service is occupied and a selection control for whether to preempt the service are displayed on the display interface, including: when the audio priority of the target service is high on the first device and low on the second device, a prompt message indicating that the other end is occupied and a selection control for whether to preempt the service are displayed on the display interface.

[0022] Accordingly, in response to the preemption command input by the user clicking the selection control, the enabling of initiating the target service to the second device is completed, including: in response to the preemption command input by the user clicking the selection control, ending the second current service and completing the enabling of initiating the target service to the second device.

[0023] In one possible implementation of the first aspect, when the audio priority of the target service corresponding to at least one of the first device and the second device is low, a prompt message indicating service occupancy and a selection control for whether to preempt the service are displayed on the display interface, including: when the audio priority of the target service is low on both the first device and the second device, a prompt message indicating dual-end occupancy and a selection control for whether to preempt the service are displayed on the display interface.

[0024] Accordingly, in response to the preemption command input by the user clicking the selection control, the enabling of the target service initiated to the second device is completed, including: in response to the preemption command input by the user clicking the selection control, ending the first current service and the second current service, and completing the enabling of the target service initiated to the second device.

[0025] In one possible implementation of the first aspect, after displaying a prompt message indicating service occupancy and a selection control for whether to preempt service on the display interface, the method further includes: in response to a non-preemption instruction input by the user clicking the selection control, maintaining the first current service of the first device and / or the second current service of the second device.

[0026] By providing feedback on the different occupancy statuses of the first and second devices in the above manner, users can gain a clearer understanding of the occupancy status of each electronic device. Depending on whether the first device, the second device, or both devices are occupied simultaneously, resources can be allocated reasonably and flexibly based on business needs, importance, urgency, and other factors to meet the core needs of users in different application scenarios.

[0027] In one possible implementation of the first aspect, the request instruction includes the target capability resource name of the target service; obtaining the audio priority of the target service on the first device and the second device includes: querying the target audio level corresponding to the capability resource name in the audio level configuration list based on the target capability resource name; and determining the audio priority of the target service on the first device and the second device based on the target audio level.

[0028] In this way, the audio level configuration list can be configured to specify the audio levels of the capability resources occupied by each service of the device based on the user's actual application needs. By querying the audio level configuration list, the target audio level of the target resource name corresponding to the target service can be determined. By supporting user configuration, the use of capability resources becomes more flexible. For interconnection services between different devices, the audio levels of the capability resources occupied by different services can be flexibly configured, realizing flexible and efficient scheduling of capability resources within the system and meeting increasingly complex business and user needs.

[0029] In one possible implementation of the first aspect, the request instruction includes the target capability resource name and the target audio level of the target service; obtaining the audio priority of the target service on the first device and the second device respectively includes: passing the target capability resource name and the target audio level to the capability resource level key-value pair in the first device and the second device; determining the audio priority of the target service on the first device and the second device by querying the capability resource level key-value pair.

[0030] For example, devices that are interconnected for services can store the capability resource names and corresponding audio levels of each initiated service to form capability resource level key-value pairs. When the first device initiates a target service to the second device, the incoming request instruction may include the target capability resource name and the target audio level. The device determines the audio priority corresponding to the target service by traversing the stored capability resource level key-value pairs.

[0031] By using the above method, a mechanism is provided to query the audio priority of the target business based on the input audio level, so as to understand the occupancy of each audio component in the system in real time, ensuring the efficient operation of the system and the optimization of user experience.

[0032] In one possible implementation of the first aspect, obtaining the audio priority of the target service on the first device and the second device respectively further includes: determining the service type of the target service according to the request instruction; and querying the audio priority of the target service on the first device and the second device based on the service type.

[0033] In this way, different service types can occupy different audio priorities on different devices, and the request instruction includes a field corresponding to the service type. By identifying the request instruction, the service type of the target service can be determined, and the audio priority of the required capacity resources on each device can be determined based on the service type. Based on the service type requirements and device capabilities, the audio stream can be dynamically invoked to flexibly handle audio conflict issues.

[0034] In a second aspect, an audio conflict resolution device is provided, applied to a first device; the device includes:

[0035] The acquisition unit is used to acquire the audio priority of the target service on the first device and the second device respectively when a user initiates a request instruction for the target service to the second device. The audio priority includes high priority and low priority.

[0036] The display unit is used to display a prompt message indicating whether the service is occupied and a selection control for whether to preempt the service on the display interface when the audio priority of the target service corresponding to at least one of the first and second devices is low.

[0037] The control unit is used to respond to the preemption command input by the user clicking the selection control and enable the initiation of the target service to the second device.

[0038] Thirdly, an electronic device is provided, comprising: one or more processors, and a memory; the memory is coupled to the one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, and the one or more processors invoking the computer instructions to cause the electronic device to perform the method as described in the first aspect.

[0039] Fourthly, an audio conflict handling system is provided, comprising a first device; the first device is configured to, upon detecting a user's request instruction to a second device for a target service, acquire the audio priorities of the target service on the first and second devices respectively, the audio priorities including high priority and low priority; the first device is further configured to, when the audio priority of the target service corresponding to at least one of the first and second devices is low priority, display a prompt message indicating service occupancy and a selection control for whether to preempt the service on a display interface; the first device is further configured to, in response to a preemption instruction input by the user clicking the selection control, enable the initiation of the target service to the second device.

[0040] In one possible implementation of the fourth aspect, the system further includes a second device, and the first device is communicatively connected to the second device;

[0041] The first device is also used to send query commands to the second device;

[0042] The second device is also used to query the status of the second service based on the query command, and when the second service status is occupied, to determine the audio priority of the target service in the second device by comparing the audio level of the second current service in the second device with the audio level of the target service, or when the second service status is unoccupied, to determine that the audio priority of the target service in the second device is high priority, and to feed back the audio priority of the target service in the first device.

[0043] The first device is also used to receive the audio priority of the target service on the second device.

[0044] In one possible implementation of the fourth aspect, the first device is further configured to send an initialization command to the second device before acquiring the audio priority of the target service on the second device;

[0045] The second device is also used to receive initialization instructions and update the audio service information in the device management module based on the initialization instructions; the device management module is used to store and synchronize the audio service information of the first device and the second device, the audio service information including the first service status and audio level of the first device, and the second service status and audio level of the second device;

[0046] Accordingly, the first device is also configured to update the audio service information of the first device in the device management module and send a first synchronization command to the second device after enabling the initiation of the target service to the second device.

[0047] The second device is also used to receive the first synchronization command and update the audio service information in the device management module based on the first synchronization command.

[0048] In one possible implementation of the fourth aspect, the first device is further configured to send a service termination instruction to the second device in response to a preemption instruction entered by the user by clicking the selection control when displaying a prompt message indicating that the peer or both ends are occupied.

[0049] The second device is also used to receive a service termination instruction and stop the second current service based on the service termination instruction.

[0050] In one possible implementation of the fourth aspect, the second device is also used to update the audio service information in the device management module and send a second synchronization command to the first device after stopping the second current service;

[0051] The first device is also used to receive the second synchronization command and update the audio service information in the device management module based on the second synchronization command.

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

[0053] In a sixth aspect, a computer-readable storage medium is provided, the computer-readable storage medium including instructions that, when executed on an electronic device, cause the electronic device to perform the method as described in the first aspect.

[0054] In a seventh aspect, a computer program product is provided that, when run on an electronic device, causes the electronic device to perform the method described in the first aspect.

[0055] It is understood that the beneficial effects of the second to seventh aspects mentioned above can be found in the relevant descriptions in the first aspect, and will not be repeated here. Attached Figure Description

[0056] Figure 1 These are example diagrams illustrating application scenarios provided in the embodiments of this application;

[0057] Figure 2 This is an example diagram of a service enablement process provided in an embodiment of this application;

[0058] Figure 3 This is a schematic diagram illustrating the principle of a service enablement process provided in an embodiment of this application.

[0059] Figure 4 This is an example diagram illustrating the implementation flow of the audio conflict handling method provided in this application embodiment;

[0060] Figure 5 This is an example diagram illustrating the implementation principle of the audio conflict handling method provided in this application embodiment;

[0061] Figure 6 This is another example diagram illustrating the implementation flow of the audio conflict handling method provided in the embodiments of this application;

[0062] Figure 7 This is another example diagram illustrating the implementation principle of the audio conflict handling method provided in the embodiments of this application;

[0063] Figure 8 This is another example diagram illustrating the implementation flow of the audio conflict handling method provided in the embodiments of this application;

[0064] Figure 9 This is another example diagram illustrating the implementation principle of the audio conflict handling method provided in the embodiments of this application;

[0065] Figure 10 This is an example diagram of an application scenario provided in the embodiments of this application;

[0066] Figure 11 This is another example diagram illustrating an application scenario provided in the embodiments of this application;

[0067] Figure 12 This is yet another example diagram illustrating an application scenario provided in the embodiments of this application;

[0068] Figure 13 This is yet another example diagram illustrating an application scenario provided in the embodiments of this application;

[0069] Figure 14 This is yet another example diagram illustrating an application scenario provided in the embodiments of this application;

[0070] Figure 15 This is yet another example diagram illustrating an application scenario provided in the embodiments of this application;

[0071] Figure 16 This is another example diagram illustrating an application scenario provided in the embodiments of this application;

[0072] Figure 17 This is a schematic flowchart of the audio conflict handling method provided in the embodiments of this application;

[0073] Figure 18 This is a schematic diagram of the audio conflict processing device provided in the embodiments of this application;

[0074] Figure 19 This is a schematic diagram of a hardware system for an electronic device applicable to this application;

[0075] Figure 20 This is a schematic diagram of a software system applicable to the electronic device described in this application. Detailed Implementation

[0076] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0077] It should be understood that "multiple" as mentioned in this application refers to two or more. In the description of this application, unless otherwise stated, " / " indicates "or," for example, A / B can mean A or B; "and / or" in this document 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, and B existing alone. Furthermore, to facilitate a clear description of the technical solutions of this application, the terms "first," "second," etc., are used to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first," "second," etc., do not limit the quantity or execution order, and that "first," "second," etc., do not necessarily imply differences.

[0078] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0079] The technical solution of this application embodiment is applied to scenarios where multiple services are concurrently running when electronic devices are interconnected.

[0080] Please see Figure 1 , Figure 1 This diagram illustrates an application scenario for multi-device interconnection provided in an embodiment of this application. Figure 1 As shown, in scenarios where electronic devices are on the same local area network and their Bluetooth is enabled, or they belong to the same user account, different electronic devices can communicate and collaborate across systems to enable business services to flow and be shared between different electronic devices. Examples include screen sharing or super call services between a mobile phone and a tablet (Pad or in-vehicle terminal), a laptop (PC), or a smart screen; the companion service between a laptop (PC) and a tablet; and collaborative or heterogeneous services between a mobile phone and a laptop.

[0081] Different services have different audio priority requirements. When multiple services run concurrently on electronic devices, audio conflicts can directly cause the later-initiated service to fail, impacting user experience. For example, if a phone and tablet are working together, and the same phone is also playing a video on a PC, the phone will issue a message that the current device (phone) is using screen sharing and simultaneous use is not supported. This causes the later-initiated service to fail, requiring the user to manually stop the previous service before initiating another. In some urgent or complex application scenarios, this makes the operation cumbersome and negatively affects the user experience.

[0082] It should be noted that, Figure 1 The various electronic devices and the interconnection services between them shown are merely illustrative examples and may include other business scenarios, such as collaborative services between mobile phones and tablets. Collaboration and heterogeneous connections can fall under the category of screen sharing services. The in-vehicle terminal can be a central control display device or a rear-seat display device. This application does not limit the specific type of electronic device, including but not limited to electronic devices capable of establishing trusted interconnections.

[0083] To facilitate understanding of the technical problems addressed and objectives of this application, the principles of its implementation process are described below through embodiments.

[0084] Figure 2 and Figure 3 The scenario examples shown only support enabling services when the electronic device's capability resources are not occupied; or, if the priority of the capability resources required by the initiated service is higher than the current running priority of the electronic device, the service can be enabled directly after preemption; otherwise, the service will fail.

[0085] like Figure 2The diagram shown is an example of a service enablement process provided in this application embodiment.

[0086] Currently, in the process of interconnecting electronic devices, when a user initiates service enablement from a first device (local end) to a second device (peer end), the first device identifies the type of service by judging the process name, determining whether the service is a screen sharing service or a call service. For different service types, it then queries the resource usage of both the first and second devices.

[0087] For example, screen sharing services generally use audio resources, while call services use modem resources; in electronic devices, modem resources generally have a higher priority than audio resources.

[0088] Because of the current interconnection mechanism, if either the first or second device is occupied when a service is initiated, the service will fail. Therefore, after enabling the service, the system first checks whether the other end (the second device) is occupied. If the other end is occupied, the process ends directly without checking whether the local end is occupied, thus reducing the decision process and time. Only when it is determined that the other end is not occupied will the system further check whether the local end is occupied.

[0089] like Figure 2 As shown, when the initiated service is identified as a collaborative service, which is a screen sharing service and uses audio resources, the system queries whether the audio and modem resources on the other end (sink end) are occupied by the service. If they are occupied, the system notifies the service that the resources are occupied and the service initiation fails. If the resources on the other end are not occupied, the system continues to query whether the audio and modem resources on the local end (source end) are occupied. If the local end is not occupied, the initiated service is successfully enabled. If the local end's audio or modem resources are occupied, the system notifies the service that the resources are occupied and the service initiation fails.

[0090] Since similar services do not directly preempt each other's priorities, when initiating a collaborative service corresponding to Audio resources, it is necessary to simultaneously determine the occupancy status of Audio and Modem resources. However, since Modem resources have a higher priority than Audio resources, when initiating a Super Call service, only the occupancy status of Modem resources needs to be determined.

[0091] like Figure 2As shown, when the initiated service is identified as the Super Call service, this is a call-related service that uses Modem resources. Modem resources have a higher priority than Audio resources, and resources of the same priority cannot be preempted. Therefore, only the Modem resource occupancy of the first and second devices is checked. By querying whether the peer's Modem resources are occupied by the service, if they are occupied, the service is notified that it is occupied, and the service initiation fails. If the peer's Modem resources are not occupied, the occupancy of the local Modem resources is checked. If not occupied, the initiated service is successfully enabled, and the service status is refreshed; if occupied, the service is notified that it is occupied, and the service initiation fails.

[0092] In one possible implementation, when the initiated service is a call-type service, which requires Modem resources, and the first or second device is in a service using Audio resources, such as when playing video in collaboration with other devices, the priority of the Modem resources corresponding to the currently initiated call-type service is higher than the priority of the Audio resources used for collaborative video playback. In this case, the collaborative service of the electronic device can be terminated directly, enabling the initiated call-type service and transferring the audio stream of the call-type service from the first device to the second device.

[0093] Among them, refreshing the service status updates the status of the latest services corresponding to the capability resources in the electronic device. For example, after the collaborative service is successfully enabled, the service status corresponding to the audio resources of the first and second devices is updated to the collaborative service; after the super call service is successfully enabled, the service status corresponding to the modem resources of the first and second devices is the super call service.

[0094] To more clearly describe the timing relationships between modules when an electronic device initiates a service, the implementation process of the above process is further explained below through a timing diagram of the service modules.

[0095] like Figure 3 As shown, the first device and the second device each include a Distributed Mobile Sensing Development Platform (DMSDP). The DMSDP of the first device includes a service management (DvService) module and a multi-service concurrent processing module (MultiBusinessManage), while the DMSDP of the second device may include a multi-service concurrent processing module (MultiBusinessManage). Taking screen-sharing collaborative services and call-related incoming call services as examples, the process may include the following steps:

[0096] 1. Enable. The first device receives a request command from the user to initiate a service, and then enables the service through the service management module.

[0097] 2. Determine the process name. The first device determines the service type by determining the process name through DMSDP.

[0098] The first application scenario is defined as a collaborative business type:

[0099] 3.1. Check if the Audio / Modem of the second device is occupied. The first device sends a query command to the second device, and the second device queries whether the Audio / Modem resources are occupied by services through the MultiBusinessManage module.

[0100] 3.2. The second device returns occupancy information to the multi-service concurrent processing module of the first device. The occupancy information includes whether the service is occupied or not.

[0101] 3.3. The multi-service concurrent processing module of the first device returns the resource occupancy status to the service management module. When the Audio / Modem resources of the second device are occupied, the occupancy result is returned.

[0102] 3.4. Notification of Service Occupancy. The first device sends a notification of service occupancy through the service management module.

[0103] 3.5. Check if the device is occupied. If the second device is not occupied, the service management module of the first device sends a query command to the multi-service concurrent processing module to check whether the audio / modem resources of the first device are occupied by a service.

[0104] 3.6. Return the occupied status. 3.7. Notify the service of occupied status. When the Audio / Modem resources of the first device are occupied, return the occupied status and issue a notification of the occupied status through the service management module.

[0105] 3.8. Returns "Not in Use". When the Audio / Modem resources of the first device are also not in use, the multi-service concurrent processing module of the first device notifies the service management module that the resources are not in use.

[0106] 3.9. Enabled Successfully. The service management module of the first device continues to enable collaborative services, realizing collaboration between the first device and the second device. That is, the second device can control the first device; for example, through the collaboration between the first device and the second device, the first device can transfer the audio and video streams it is playing to the second device for playback.

[0107] 3.10. Refresh Service Status. The service management module of the first device notifies the multi-service concurrent processing module to refresh the service status, updating the service corresponding to the audio resource to collaborative, so as to facilitate the judgment of the capacity resource usage when the service is enabled in the next call.

[0108] 3.11. Refresh Service Status. The service management module of the first device sends a notification to the multi-service concurrent processing module of the second device to refresh the service status. The second device updates the service corresponding to the audio resource to collaborative, which facilitates the judgment of the capacity resource usage when the service is enabled in the next call.

[0109] The second application scenario involves identifying the service type as an incoming call:

[0110] 4.1. Check if the modem of the second device is occupied. The service management module of the first device sends a query command to the multi-service concurrency processing module of the second device; the multi-service concurrency processing module of the second device queries the occupation status of the capacity resources and returns the occupation information.

[0111] 4.2. Returning Occupancy Information. The multi-service concurrent processing module of the second device determines whether the Modem resource is occupied by comparing the priority of the capability resources corresponding to the services and returns the occupancy information to the first device.

[0112] 4.3. Return Occupancy. If the Modem resource of the second device is being used by other services, the system returns a result to the first device indicating that the Modem resource is occupied.

[0113] 4.4. Notification of Service Occupancy. The service management module of the first device issues a notification that the capacity resources have been occupied by other services.

[0114] 4.5. Check resource usage. If the second device's resources are not occupied, continue to check the resource usage status of the first device.

[0115] 4.6. Return of Occupancy. If the resource capacity of the first device is occupied by other services, the multi-service concurrent processing module of the first device returns the occupation result to the service management module.

[0116] 4.7. Notification of Service Occupancy. The service management module of the first device issues a notification that the capacity resources have been occupied by other services.

[0117] 4.8. Return "Unoccupied". If the resource capacity of the first device is not occupied, the multi-service concurrent processing module of the first device sends an unoccupied result to the service management module.

[0118] 4.9. Enable Successful. With the resources of both the second and first devices unused, the first device enables the incoming call service and transfers the audio stream of the incoming call service to the second device, allowing the user to make calls through the second device.

[0119] 4.10. Refresh Service Status. The service management module of the first device notifies the multi-service concurrent processing module to refresh the service status, updating the service corresponding to the Modem resource to incoming call, so as to facilitate the judgment of the resource utilization status when the service is enabled again.

[0120] 4.11. Refresh Service Status. The service management module of the first device sends a notification to the multi-service concurrent processing module of the second device to refresh the service status. The second device updates the service corresponding to the Modem resource to incoming call, which facilitates the judgment of the resource utilization status when the service is enabled again.

[0121] In order to facilitate the illustrative explanation of various application scenarios (occupied or unoccupied), the sequence numbers of the above examples do not limit the specific execution logic. Different branches are selected to implement the processing of each example for different situations.

[0122] The above example only enables the subsequent service if the capability resources of the first and second devices are not occupied, or if the priority of the capability resources corresponding to the subsequent service is higher than the priority of the service currently running on the device. Otherwise, the subsequent service will fail. Therefore, in cases where the application scenario is complex or urgent, the operation process for triggering the service will be cumbersome, affecting the user experience.

[0123] To address the shortcomings of the aforementioned processing methods, this application provides a method for handling audio conflicts during multi-service concurrency. This method allows for flexible audio stream transfer between multiple devices based on user selections for different application scenarios, thus satisfying service enablement requirements in various application environments. The specific implementation process and principles of the audio conflict handling method provided in this application are described below.

[0124] Example 1

[0125] Figure 4 and Figure 5 This refers to the audio conflict handling process that sequentially assesses the resource occupancy of the first device (local end) and the second device (peer end) after the service is enabled.

[0126] like Figure 4The diagram shown is an example of the implementation flow of the audio conflict handling method provided in this application embodiment. For ease of subsequent explanation, the meanings of several identifiers are clarified first:

[0127] 201: Indicates that the capability resource is available;

[0128] 2140: Indicates that the local end is in use;

[0129] 2141: Indicates that the other end is in use.

[0130] Since the embodiments of this application support selective audio transfer when there are audio conflicts in concurrent services between multiple devices, it is faster to determine the resource occupancy of the local end that initiated the service than to determine the resource occupancy of the other end. In the case where the local end occupies the resources but does not need to preempt to transfer the audio, it saves more process processing time. Therefore, the resource occupancy of the local end that initiated the service can be determined first.

[0131] Unlike the above embodiments, this embodiment judges the priority of the capability resources to provide a prompt on the occupancy status; thus, it can flexibly handle the problem of concurrent audio conflicts of multiple services based on the user's choice.

[0132] In this embodiment, when the first device detects a user's request instruction for a target service to the second device, the target service calls the enable interface and passes in the priority of the capability resource corresponding to the target service, such as Map.<String,Object> The data format input is the priority of the capability resources corresponding to the target service. Here, a String represents the type of capability resource corresponding to the service, and an Object represents the priority level (e.g., 0, 1, and 2 represent low, medium, and high priorities, respectively). Alternatively, the priority of the capability resources already configured in the electronic device can be determined based on the service information of the service.

[0133] like Figure 4 As shown, the DMSDP module of the first device determines the first audio priority of the target service on the first device by querying the level of the capability resources corresponding to each service in the Map data structure. For example, if the level of the capability resource corresponding to the target service is 2, and the level of the capability resource corresponding to the currently running service on the first device is 1, then the first audio priority of the target service on the first device is high priority; conversely, the first audio priority of the target service on the first device is low priority. Specifically, when the level of the capability resource corresponding to the target service is the same as the level of the capability resource of the currently running service on the first device, the returned first audio priority is also low priority, meaning that direct preemption is not supported at the same level.

[0134] For example, when the first audio priority is low, the first device prompts that the local device is occupied (i.e., 2140), notifies the service that the local device is occupied, and sends a prompt message asking whether to preempt the local device by the XX service. When the user selects not to preempt the local device, the process ends directly, maintaining the current service scenario of the first device. When the user selects to preempt the local device, the current service being run on the first device is disabled, and the target service being initiated is enabled. At this time, the service being run on the first device has ended, and the target service has a high first audio priority on the first device, so the second audio priority on the second device is then determined.

[0135] For example, the request instruction to initiate the target service may include the device identifier of the second device (peer). The first device can send a query instruction to the second device based on this device identifier. The second device, using the same query method as the first device, determines the second audio priority of the capability resources corresponding to the target service on the second device. When the second audio priority is high, the first device is successfully enabled, completing the audio flow from the first device to the second device. When the second audio priority is low, the second device sends a peer-occupied notification message (i.e., 2141) to the first device. The first device sends a service occupancy notification and a prompt message asking whether the peer is occupied by the XX service and whether to preempt it. When the user selects not to preempt, the process ends directly, maintaining the current service scenario of the second device. When the user selects to preempt, the first device notifies the second device to remove the current service enabled for the second device. The first device successfully enables the target service, completing the audio flow from the first device to the second device.

[0136] like Figure 5 As shown, the first device and the second device each include a DMSDP module, which comprises a service management DvService module and a multi-service concurrent processing module. The service management DvService module provides hardware virtualization capabilities for services, enabling the first device to use the hardware capabilities of the second device across devices. The multi-service concurrent processing module handles the status (occupied or unoccupied) of capability resources and manages their priorities. Through message interaction and cache management with the service management module, it obtains the latest occupancy status of capability resources and notifies the service initiator to execute the corresponding callback. Taking collaborative or incoming call services as an example, cross-device services within the same local area network are implemented. The implementation process of the above process is further illustrated through the timing diagrams of each module. This process may include the following steps:

[0137] 1. Enable. The first device receives a user's request command to initiate a target service to the second device and calls the enable interface.

[0138] On the one hand, when the business calls the enable interface, it will pass in the device identifier (DeviceId) to be enabled, the capability resources to be used (such as Audio, Modem, or Camera), and the priority level of the required capability resources (such as Map).<String,Object> ).

[0139] On the other hand, the priority level of the capability resources required by the target business (e.g., Map)<String,Object> It can be configured in the first and second devices to configure the corresponding priority levels based on user habits and application scenarios, and generate an audio level configuration list; when the business calls the enable interface, after identifying the business type by identifying the process type, the priority of the corresponding capability resources is determined based on the priority level configured in the audio level configuration list.

[0140] In one possible implementation, the request instruction may include the target capability resource name of the target service, and based on the target capability resource name, query the audio level in the audio level configuration list corresponding to the capability resource name; and based on the target audio level, determine the audio priority of the target service on the first device and the second device.

[0141] For example, when the target service calls the enable interface, it can pass the target capability resource name and the target audio level to the capability resource level key-value pair in the first and second devices; by querying the capability resource level key-value pair, the audio priority of the target service in the first and second devices can be determined.

[0142] As shown in Table 1, the key-value pairs for each capability resource level are:

[0143] Speaker 1 MIC microphone 0 Modem 2

[0144] Table 1

[0145] Among them, the speaker and microphone belong to the Audio class of resources. Each hardware capability resource can correspond to an audio level value of 0, 1, or 2, which can be set according to the actual application scenario requirements. For example, the value corresponding to the speaker is 0, the value corresponding to the microphone is 1, and the value corresponding to the modem is 2. This is only an example to illustrate that when the target service calls the enable interface, the audio level corresponding to the capability resource required by the target service can be passed at the same time. It can be flexibly configured on the electronic device side according to the actual application scenario requirements.

[0146] In addition to the above information, business-related audio parameters will also be included, such as sampling rate, bit width, and number of channels.

[0147] For example, the instruction when a business calls the enable interface can be enableVirtualService(dmsdpDevice,capability,Map).<String,Object> (info), where enableVirtualService indicates the enabled virtual service, dmsdpDevice indicates the corresponding enabled device identifier, capability indicates the capability resources required by the business, Map<String,Object> This indicates the priority of the capability resource, and info can be audio parameters related to the business.

[0148] 2. Negotiating Service Information. The first device sends a message to the second device, informing the second device of the required capability resources and service-related audio parameters based on the information from the aforementioned service call enable interface.

[0149] For example, the DMSDP of the first and second devices creates a control channel, through which the first device sends audio parameters, such as sampling rate, bit width, and number of channels, to the second device.

[0150] 3. Whether it is occupied. The first device first determines the priority of the capability resources required by the target service on its own end based on the priority of the capability resources passed in the request command. The DMSDP module traverses the priority level of each service on the local end and compares the priority of the capability resources required by the target service on its own end; or it determines the priority of the capability resources required by the target service on its own end based on the priority level of the capability resources configured in the first device.

[0151] For example, the DMSDP of the first device uses the dmsdpDeviceService.getServiceType(deviceID) command to obtain service information of the target service, such as service type, device identifier, and required device service capabilities and resources, so as to compare priorities by traversing the Map.

[0152] 4. Local Occupancy. When the comparison result shows that the priority of the capability resource corresponding to the target service is lower than the priority of the capability resource of the current service of the first device, the first audio priority of the target service on the first device is low priority, and the multi-service concurrency module returns a notification of local occupancy (2140) to the service management module.

[0153] 5. Service occupancy and preemption. The service management module of the first device issues a prompt message indicating whether the service is occupied and whether preemption is required. This prompt message may also include a prompt message indicating that the service is occupied on the local end, a prompt message indicating the type of service occupied on the local end, and a selection control for the user to choose whether to preempt.

[0154] 6. Remove enable. Upon receiving a user's preemption command, the first device disables the currently running service. For example, based on disableVirtualService(dmsdpDevice,capability,Map...)<String,Object> The `info` command, via the service management module, terminates the currently running service of the first device. This current service can be a cross-device service between the first device and other devices besides the second device, such as collaborative video playback with other devices. The device identifier corresponding to `dmsdpDevice` in the deactivation command can be the identifier of another device. Upon receiving a user's instruction to not preempt, the process ends, maintaining the running state of the first device.

[0155] 7. Refresh Service Status. This service status indicates whether the capability resources of the first device are occupied by the service, meaning that the capability resources required by the target service are currently unoccupied. Then, the first device continues to enable the target service and determines the audio priority on the first device by traversing the Map and comparing priorities. At this point, the capability resources used by the target service have a higher audio priority on the first device.

[0156] For example, based on the updateVirtualDeviceService directive, the multi-service concurrent processing module is notified to refresh the service status.

[0157] 8. Is it occupied? If it is determined that the target service has a high audio priority on the first device, the first device continues to send a query command to the second device to check the audio priority of the capability resources required by the target service on the second device. The second device's DMSDP iterates through the Map, compares the priorities, and returns the comparison result to the first device.

[0158] 9. Peer Occupancy. When the target service corresponds to a low audio priority on the second device, the multi-service concurrent processing module of the second device returns a notification of peer occupancy (i.e., 2141) to the service management module of the first device.

[0159] 10. Service Occupancy and Preemption. After receiving a notification from the second device that the service has been occupied, the first device sends a prompt message indicating whether the service is occupied and whether preemption is required. This prompt message may also include information about the service being occupied, the type of service being occupied, and a selection control for the user to choose whether to preempt the service.

[0160] 11. Deactivate. After receiving the user's preemption command, the first device sends a deactivation notification to the service management module of the second device through the service management module.

[0161] 12. Removal of enable successful. After receiving the notification from the first device that the first device has removed the enable, the second device terminates the currently running service and refreshes its service status. At this time, the first device resumes enabling the target service, which has a high audio priority on both the first and second devices. The second device returns an unoccupied notification (i.e., 201: Capability Available) to the first device.

[0162] 13. Enable successful, preemption successful. Thus, the first device completes the enablement of the target service initiated by the second device, realizing the transfer of the audio stream from the first device to the second device.

[0163] 14. Refresh Service Status. After enabling the target service, the first device should promptly refresh the service status, updating the services occupying capacity resources to the latest target service.

[0164] 15. Refresh Service Status. The service management module of the first device sends a notification to the multi-service concurrent processing module of the second device to refresh the service status. Upon receiving this notification, the second device updates the services occupying capacity resources to the latest target services.

[0165] 16. Is it occupied? After the first device traverses the Map and compares priorities, if it determines that the audio priority of the target service is higher on the first device, the first device sends a query command to the second device to check whether it is occupied, and continues to query the audio priority of the target service on the second device.

[0166] 17. Peer Occupancy. The second device iterates through the Map, compares priorities, and determines the capability resources used by the target service. If the audio priority of the second device is low, the second device returns the peer occupancy result (i.e., 2141) to the first device.

[0167] 18. Service Occupancy and Preemption. After receiving a notification from the second device that the service has been occupied, the first device sends a prompt indicating whether to preempt the service. This prompt may also include information about the occupied service, the type of service being occupied, and a selection control for the user to choose whether to preempt the service. Subsequently, as shown in step 11, upon receiving a preemption command from the user, the currently running service on the second device is removed, thus enabling the target service.

[0168] 19. Unoccupied. After the first device traverses the Map and compares priorities, if the audio priority of the capability resource required by the target service is high on the first device, it continues to query the audio priority of the target service on the second device. If the audio priority on the second device is also high, the second device returns an unoccupied notification (i.e., 201) to the first device.

[0169] 20. Enable Successful. When the audio priority of the target service is high on both the first and second devices, the target service is enabled directly, enabling cross-device operation of the target service and transferring the audio stream of the target service to the second device.

[0170] Understandably, the sequence numbers in the above examples do not limit the specific execution logic. Different branches are selected to implement the processing of each example for different situations.

[0171] The above embodiments provide a query of the resource occupancy status and control the corresponding audio priority of the business. When the enable interface is called, it is passed through to the DMSDP module. Based on user selection, business needs and device capabilities, the audio stream is dynamically scheduled, which can flexibly deal with and handle audio conflicts that occur when multiple businesses are running concurrently. It can be applied to more complex, changeable and emergency application scenarios, and improve the user experience.

[0172] Example 2

[0173] In addition to the above example, this application also provides another example of the implementation flow of the audio conflict handling method, such as... Figure 6 and Figure 7 As shown, this application embodiment can support simultaneous querying of the audio priority of the target service on the first device and the second device. It does not require waiting for the judgment of the first device to be completed before the judgment of the second device. The judgment of the three cases can be performed directly on the first device (local end), thereby improving the efficiency of the processing flow.

[0174] like Figure 6 The diagram shown is another example of the implementation flow of the audio conflict handling method provided in this application embodiment. For ease of subsequent explanation, the meanings of several identifiers are clarified first:

[0175] 201: Indicates that the capability resource is available;

[0176] 214: Indicates that the capability resource is unavailable;

[0177] 2140: Indicates that the local end is in use;

[0178] 2141: Indicates that the other end is using the device;

[0179] 2142: Indicates double-ended occupancy;

[0180] 2010: Indicates that both ends are available.

[0181] In this embodiment of the application, based on the same implementation principle as the above example, when the first device detects that the user has initiated a request instruction for the target service to the second device, it passes in the priority of the capability resources corresponding to the target service, or determines the audio priority of the capability resources required by the target service in the device by the priority of the capability resources already configured in the device.

[0182] like Figure 6 As shown, while the first device queries its own service usage, it sends a query command to the second device to query the second device's service usage. By traversing the Map on both the first and second devices and comparing the priority of the corresponding resource capabilities, it determines that the target service on the first device may have two possible scenarios: low priority (214 occupied) and high priority (201 unoccupied). Similarly, the target service on the second device may also have two possible scenarios: low priority (214 occupied) and high priority (201 unoccupied).

[0183] For example, based on the query results for both devices simultaneously, the final query result is determined: dual-end occupancy 2142, peer occupancy 2141, local occupancy 2140, or both resources are available. For each of the three different occupancy scenarios, a corresponding service occupancy notification is issued based on the query result, along with a prompt indicating whether the service occupancy has been preempted. Upon receiving a preemption command from the user, the currently running service on the device is terminated, enabling the subsequent target service. After successful enabling, the service status of both devices is refreshed.

[0184] For example, when the first device finds that its first service status is occupied, it can determine that it is currently running the first current service. The audio level of the first current service is then compared with the audio level of the target service to determine the first audio priority of the target service on the first device. When the first device queries the status of the second service on the other end, it sends a query command to the second device. Based on the query command, if the second device finds that its second service status is occupied, it can determine that it is currently running the second current service. The audio level of the second current service is then compared with the audio level of the target service to determine the second audio priority of the target service on the second device.

[0185] Specifically, when the first service state of the first device is unoccupied, the target service's first audio priority on the first device is determined to be high priority; similarly, when the second service state of the second device is unoccupied, the target service's second audio priority on the second device is determined to be high priority. When the audio level of the first current service on the first device is higher than or equal to the audio level of the target service, the target service's first audio priority on the first device is low priority; otherwise, it is high priority. Similarly, when the audio level of the second current service on the second device is higher than or equal to the audio level of the target service, the target service's second audio priority on the second device is low priority; otherwise, it is high priority.

[0186] The following describes the timing interaction process of an example of simultaneously querying the audio priority of the target service on the first and second devices.

[0187] like Figure 7 The module sequence diagram shown illustrates the operation of cross-device services within the same local area network, using collaborative or incoming call services as an example. The parts based on the same implementation principles as the above example will not be elaborated upon here. This process may include the following steps:

[0188] 1. Enable.

[0189] 2. Consultation service information.

[0190] 3. Check if the service is in use. While querying its own end, the first device sends a query command to the second device to check the service status of the second device.

[0191] 4. Occupancy Feedback. When the second device finds that the audio level corresponding to the target service is low priority on the second device, it returns an occupancy notification to the first device.

[0192] 5. Dual-end occupancy feedback. When the first device receives the occupancy notification from the second device, and the query result of the first device is also low priority, the multi-service concurrent processing module of the first device sends a dual-end occupancy prompt (i.e., 2142) to the service management module.

[0193] 6. Service usage, whether it is preempted.

[0194] 7. Deactivation. In the case of dual-end occupancy, when the first device receives a preemption command from the user, it deactivates the currently running first current service through the service management module and refreshes the service status of the multi-service concurrent processing module; at the same time, it sends a deactivation notification to the second device, and the service management module of the second device deactivates the currently running second current service and refreshes the service status of the multi-service concurrent processing module.

[0195] 8. Enable.

[0196] 9. Send an enable notification. The first device continues to enable the target service and sends an enable notification to the second device. At this time, the service status of both the first and second devices after the refresh is in an unoccupied state, that is, the audio priority of the target service is high on both the first and second devices, and the second device successfully enables the target service.

[0197] 10. Refresh Service Status. After successfully enabling the target service, the second device refreshes the resource occupancy status of the second device to reflect the latest target service and sends a notification to the first device that the resource is not occupied.

[0198] 11. Enable Successful. The first device successfully enables the target service and updates the resource occupancy status of the first device to reflect the latest target service.

[0199] 12. Feedback on Occupancy. When the audio priority of the second device is low, the second device sends a notification to the first device indicating that it is occupied.

[0200] 13. Peer Occupancy. When the target service has a high audio priority on the first device and a low audio priority on the second device, the multi-service concurrent processing module of the first device sends a notification of peer occupancy to the service management module.

[0201] 14. Service occupancy and preemption. When the first device receives a preemption command from the user, it continues to execute the de-enablement step as in step 7, sends a de-enablement notification to the second device, the second device de-enables the second current service, and after refreshing the service status, continues to enable the target service, completing the enabling process.

[0202] 15. Feedback indicates no content is being used. If the audio priority of the second device serving the target service is high, the second device sends a notification to the first device indicating that the content is not being used.

[0203] 16. Local Access Occupancy. When the target service has a low audio priority on the first device and a high audio priority on the second device, the multi-service concurrent processing module of the first device sends a notification of local access occupancy to the service management module.

[0204] 17. Service occupancy, preemption. When the first device receives a preemption command from the user, it continues to execute the de-enablement step as in step 7. The first device de-enables the first current service, and after refreshing the service status, it enables the target service again, completing the enabling process.

[0205] 18. Feedback indicates no content is being used. If the audio priority of the second device serving the target service is high, the second device sends a notification to the first device indicating that the content is not being used.

[0206] 19. Capability Available. When the target service has a high audio priority on the first device and a high audio priority on the second device, the multi-service concurrent processing module of the first device sends a capability available notification (i.e., 2010) to the service management module.

[0207] 20. Enabled successfully. If the target service has high audio priority on both the first and second devices, enable the target service directly and refresh the service status.

[0208] Through the above embodiments, while querying the service usage status on the local end, the service usage status on the peer end is queried concurrently. Based on the obtained usage status of the local and peer ends, a status judgment is performed, including local end usage 2140, peer end usage 2141, and dual end usage 2142. By providing simultaneous querying of the resource usage status of the first and second devices, the processing time is shortened and the response efficiency is improved. Furthermore, the audio priority of the service is controlled, and when the enable interface is called, it is passed to the DMSDP module. Based on user selection, service requirements, and device capabilities, the audio stream is dynamically scheduled, which can flexibly cope with and handle audio conflicts that occur when multiple services are concurrent. It can be applied to more complex, changeable, and emergency application scenarios, improving the user experience.

[0209] Example 3

[0210] To further shorten the query time during processing, this application also provides an example of an audio conflict handling method. This example only requires the first device initiating service enable to perform the query, eliminating the need to send a query command to a second device, which then compares the results and returns them. This reduces processing latency and improves response speed.

[0211] The specific implementation process and principle of the audio conflict handling method provided in the embodiments of this application are described below. Figure 8 and Figure 9 This refers to the process where, after the service is enabled, the first device queries the network to check the resource usage of both the local and remote ends, and then handles audio conflicts.

[0212] like Figure 8 The diagram shown is another example of the implementation flow of the audio conflict handling method provided in this application embodiment.

[0213] In this embodiment, when the first device detects a user's request instruction for a target service to the second device, it passes in the priority of the capability resource corresponding to the target service and writes the passed capability resource priority into the device management profile module; or it writes the priority of the capability resource already configured in the device into the device management profile module, thereby determining the audio priority of the capability resource required by the target service in the first and second devices.

[0214] The device management profile module can be a specific file or data structure that describes the device's characteristics, functions, interfaces, and interaction methods. It provides a standardized interface and protocol for communication and interaction between electronic devices and servers. Electronic devices can query various information stored on the server by connecting to the network.

[0215] Accordingly, the device management profile module includes information about each electronic device with a trusted connection, and can be synchronized within the trusted connection ring. The audio service information of each electronic device with a trusted connection is stored in the device management profile module. The audio service information of each electronic device includes the capability resources of each electronic device and the corresponding service status. When the service status changes or is initialized, the audio service information will be updated in the device management profile module. When a device goes online or offline, or when device attributes change, it will also be synchronized within the trusted connection ring of the device management profile module.

[0216] For example, the priority of the capability resource corresponding to the target service or the priority of the capability resource already configured in the device can be represented based on the audio level corresponding to the capability resource. For example, 0, 1, and 2 can be used to represent the audio level respectively, with the corresponding priorities being low, medium, and high.

[0217] like Figure 8 As shown, when the first device detects a user's request instruction to the second device for a target service, it calls the enable interface based on the target service, queries the device management profile module, obtains the capability resources and service status of the first and second devices, and determines the audio level of the capability resources corresponding to the target service after querying. When the audio priority is high, the capability resources of the first and second devices are available, and the device returns a successful service enable. At the same time, the capability resources and service status of the first and second devices in the device management profile module are updated.

[0218] For example, when the audio priority of the target service initiated later is low on the first or second device, the capability resources of the first and / or second devices are occupied. The system returns a local occupation 2140, peer occupation 2141, or dual-end occupation 2142, and notifies the target service that the capability resources required are occupied, for example, the local and / or peer devices are occupied by service XX, and asks whether to preempt. When a user input preemption command is received, the system removes the services currently running on the first and / or second devices, updates the capability resources and corresponding service status of the first and / or second devices in the device management profile module, and performs an audio service information synchronization throughout the entire trusted connection ring. The target service is then re-enabled. After successful enabling, the service preemption is successful.

[0219] It should be noted that, in this example, the capability resources in the audio service information of each electronic device are virtualized capabilities, that is, independent virtual environments created after abstracting and transforming various physical capability resources (such as audio / modem) of the peer device. When the first device detects a user's request instruction for the target service to the second device, it calls the enable interface based on the target service to query the virtualization capabilities of the first and second devices and their corresponding service status in the device management profile module.

[0220] The following section describes the timing interaction process of determining the audio priority of the target service device in the first and second devices by querying the device management profile module.

[0221] like Figure 9 The module sequence diagram shown indicates that both the first and second devices include a DMSDP module and a device management profile module. Taking collaborative or incoming call services as an example, this sequence flow enables cross-device service operation within the same local area network and may include the following steps:

[0222] 1. Enable. Similar to the previous example, the target business calls the enable interface.

[0223] 2. Sending a notification. The first device sends a notification to the second device regarding the target service call. Upon receiving the notification, the service management module of the second device initializes and notifies the device management profile module to update the virtualization capabilities of the second device to ensure that its virtualization capabilities are up-to-date. The device management profile module uniformly records the virtualization capabilities and service status of each electronic device. When the service status of each electronic device changes, the device management profile module is triggered to update.

[0224] 3. Is it occupied? The service management module of the first device sends a query command to the multi-service concurrent processing module to query the capacity resources and occupancy status of the first and second devices.

[0225] 4. Query virtualization capabilities and service status. The multi-service concurrent processing module of the first device queries the device management Profile module for the virtualization capabilities and service status of the first and second devices. The virtualization capabilities and service status of the first and second devices are obtained using the getProperties command.

[0226] 5. Return virtualization capabilities and service status. The device management profile module returns the virtualization capabilities and service status of the first and second devices to the multi-service concurrent processing module.

[0227] 6. Capability Available. If the target service has high audio priority on both the first and second devices, return a query result indicating capability availability (i.e., 201).

[0228] 7. Enable Successful. After successful enable, update the virtualization capabilities of the first and second devices in the device management profile module, and notify the second device to synchronize its device virtualization capabilities. The second device then updates the virtualization capabilities of the first and second devices in its corresponding device management profile module.

[0229] 8. Peer Occupancy. When the target service has a low audio priority on the second device, return the query result for peer occupancy (i.e., 2141).

[0230] 9. Service occupancy, preemption required. Similar to the example above, the first device sends a prompt asking whether the service occupancy has been preempted.

[0231] 10. Remove enable. Since the service is occupied by the peer, the first device sends a notification to the service management module of the second device to remove the enable for the current service. After successful removal, the virtualization capabilities of the second device in the device management profile module are updated.

[0232] 11. Device Virtualization Capability Synchronization. After the second device updates its virtualization capabilities in the device management profile module, it notifies the first device to synchronize.

[0233] 12. Enable. The first device continues to enable the target service. After preemption, if the audio priority of the target service is high on both the first and second devices, then the enable is successful.

[0234] Accordingly, after successful enabling, the first device can continue to update the virtualization capabilities of the first and second devices in the device management profile module, and notify the second device to synchronize.

[0235] 13. Local usage. When the query finds that the target service has a low audio priority on the first device and a high audio priority on the second device, the query result for local usage (i.e., 2140) is returned.

[0236] 14. Service occupancy, preemption required. Similar to the example above, the first device sends a prompt asking whether the service occupancy has been preempted.

[0237] 15. Remove enable. Since the device is occupied by the local end, after the first device is removed from the enable, the virtualization capability of the first device in the device management profile module is updated, and the device management profile module of the second device is notified to synchronize the virtualization capability of the first device.

[0238] 16. Enable. The first device continues to enable the target service. After preemption, if the audio priority of the target service is high on both the first and second devices, then the enable is successful.

[0239] Accordingly, after successful enabling, the first device can continue to update the virtualization capabilities of the first and second devices in the device management profile module, and notify the second device to synchronize.

[0240] In the example above, when the target service calls the enable interface, it passes the name of the required capability resource. In one scenario, the priority of the capability resource is also passed; in another scenario, the required capability resource is passed to the device management profile module based on the priority of each capability resource already configured in the electronic device. Since the device management profile module stores audio service information of various trusted connected devices (such as mobile phones, tablets, laptops, smart screens, and in-vehicle terminals), DMSDP can obtain the local and peer occupancy status by querying (getProperties) the capability resources and service status stored in the device management profile module. When the local end occupies and / or the peer end occupies, it issues a prompt message indicating whether the service is occupied and whether to preempt. When it receives a user input to not preempt, the initiated target service ends and the current service status is maintained. When it receives a user input to preempt, DMSDP first removes the enable of the first service (the service currently running on the electronic device), and then re-initiates the enable. After successful enable, the second service (the target service) successfully preempts, completing the cross-device operation service from the first device to the second device.

[0241] The above embodiments synchronize audio service information of trusted connected devices through the device management profile module. Through single-end querying, the electronic device initiating the target service can simultaneously obtain the capability resources and service status of the peer device, thereby quickly determining the occupancy status of the local and peer devices and improving the response rate.

[0242] Based on the implementation principles of the above examples, the implementation process in practical application scenarios will be further introduced below.

[0243] This application uses collaboration and incoming call services as examples to illustrate the application scenarios. Collaboration is a screen sharing service, mainly targeting office and entertainment scenarios. It can project the screen and audio of the mobile phone onto a tablet or laptop, allowing users to watch videos on the tablet or laptop. The incoming call service is for when there is an incoming call on the mobile phone. Through call sharing, an incoming call banner notification will appear on the tablet or laptop. When users are working on the tablet or laptop, they can answer the call directly on the device side of the tablet or laptop, transferring the call from the mobile phone side to the tablet or laptop side.

[0244] Scenario 1: Local terminal usage

[0245] like Figure 10 The diagram shown is an example of an application scenario provided in this application embodiment.

[0246] Mobile phone A (the first device) and PC are in the process of receiving a call. That is, mobile phone A transfers the audio of the incoming call to the PC through call sharing, and the user answers the call through the PC.

[0247] At this point, mobile phone A initiates a collaborative audio service (i.e., the subsequent target service) to another electronic device, the Pad, projecting the screen and audio from mobile phone A onto the Pad's interface for playback. Figure 10 The mobile phone A shown in the figure initiates a collaborative service to the Pad through the trust ring.

[0248] The collaborative service requires Audio as its resource. Currently, mobile phone A is running an incoming call service, which uses Modem, resulting in an audio conflict. After querying and comparing the priorities of the resource resources on mobile phone A and the tablet, if the tablet's (peer) resource is available, mobile phone A will issue a prompt indicating whether it is attempting to preempt the resource because the priority of Audio for the collaborative service is lower than that of Modem for the incoming call service. Figure 10 The mobile phone A shown displays a selection control for service usage and whether it is preempted. The selection control includes "Yes" and "No".

[0249] When mobile phone A receives the user's "Yes" input command to preempt the call, mobile phone A removes the cross-device enable for the incoming call service, ending the call transfer to the PC, i.e., the call is transferred back to mobile phone A; mobile phone A then re-enables the collaborative service to the tablet, completing the audio transfer to the tablet; such as Figure 10 As shown, the interface and audio of mobile phone A are projected onto the interface of the tablet, completing the collaboration and successfully preempting the call. That is, while the call on mobile phone A is not disconnected, the audio is streamed to the tablet, allowing the user to answer the call on the tablet while simultaneously using a mouse or touchscreen to operate the interface of mobile phone A projected onto the PC (or tablet). Upon receiving a "No" input from the user to discontinue preemption, the call service on both mobile phone A and the PC is maintained.

[0250] Scenario 2: Remote end occupancy

[0251] like Figure 11 As shown, this is another example diagram of an application scenario provided in the embodiments of this application.

[0252] Mobile phone A is currently interacting with a PC (or tablet). Figure 11 (Taking PC as an example) In the incoming call service, mobile phone A transfers the audio stream of the incoming call service to the PC through call sharing, and the user answers the call through the PC.

[0253] At this time, another mobile phone B (the local end) initiates a collaborative (or heterogeneous) service (i.e., the target service initiated later) to the PC (or Pad end), projecting the screen and audio of mobile phone B onto the interface of the PC (or Pad) for playback; for example Figure 11 The mobile phone B shown in the figure initiates collaborative / heterogeneous business to the PC through the trust ring.

[0254] The capability resource required for the collaborative / heterogeneous service can be Audio. Currently, the PC (or Pad) is running an incoming call service, which uses the Modem capability resource. After querying and comparing the priority of the capability resources of mobile phone B and the PC (or Pad), if the capability of mobile phone B (this end) is available, since the priority of the Audio capability resource corresponding to the collaborative / heterogeneous service is lower than the priority of the Modem capability resource corresponding to the incoming call service, the audio priority of the collaborative / heterogeneous service on the PC is low. Mobile phone B sends a prompt to the other end indicating whether it is occupying the audio resource and whether it is preempting the access. Figure 11 The mobile phone B shown displays a selection control indicating whether the service is occupied and whether it is preempted. The selection control includes "Yes" and "No".

[0255] After receiving the user's "Yes" input command to preempt the call, mobile phone B notifies the PC to deactivate the incoming call service, transferring the audio stream of the incoming call service back to mobile phone A, thus ending the incoming call service on the PC. Mobile phone B then re-enables the collaborative / heterogeneous service to the PC, completing the audio stream transfer to the PC. Figure 11 As shown, the screen and audio of phone B are projected onto the interface of the tablet, completing the collaboration and successfully preempting the call. The user can operate the screen projected onto the PC (or tablet) using a mouse or touch screen. When the user clicks "No" to indicate that they do not preempt the call, the incoming call service between phone A and the PC is maintained.

[0256] For example, when the target service initiated later calls the enable interface, it can pass in the corresponding capability resource type or name, as well as the priority level of the capability resource. Alternatively, it can determine the priority level of the target service based on the audio level configuration list corresponding to the capability resources already configured in the device. By comparing the priority levels, the device occupancy status can be determined. That is, when the target service initiated later is collaborative, the corresponding capability resource can also be a Modem resource. The above is only an example using Audio resources, and there is no limitation on the specific capability resources used by different services.

[0257] Scenario 3: Dual-device occupancy (two-device scenario)

[0258] like Figure 12 As shown, this is another example diagram of an application scenario provided in the embodiments of this application.

[0259] Mobile and PC / Pad devices Figure 12 (Taking a PC as an example) Currently, a call is in progress. At this time, mobile phone A initiates a collaborative service with the PC. After querying and comparing the priorities of the capability resources on both mobile phone A and the PC, it is determined that the priority of the Audio capability resource corresponding to the collaborative service is lower than the priority of the Modem capability resource corresponding to the call. Therefore, the audio priority of the later-initiated collaborative service is lower on both mobile phone A (the local device) and the PC. Mobile phone A then issues a notification regarding dual-device occupancy and whether it intends to preempt the call. Figure 11 The mobile phone A shown displays a selection control for service usage and whether it is preempted. The selection control includes "Yes" and "No".

[0260] After receiving the user's "Yes" input command to preempt the call, mobile phone A deactivates the cross-device call service, ending the call transfer to the PC, i.e., the call is transferred back to mobile phone A; it also notifies the PC to deactivate the call service, ending the call service; mobile phone A then reactivates the collaborative service to the PC, completing the audio transfer to the PC; as follows: Figure 10As shown, the interface and audio of mobile phone A are projected onto the interface of the tablet, completing the collaboration and successfully preempting the call. That is, while the call on mobile phone A is not disconnected, the audio is transferred to the PC via the collaboration service. This allows the user to answer the call on the PC while simultaneously operating the interface projected onto the PC using a mouse or touchscreen. Upon receiving a "No" command from the user to not preempt the call, the call service between mobile phone A and the PC is maintained.

[0261] Scenario 4: Dual-device occupancy (four-device scenario)

[0262] like Figure 13 As shown, this is another example diagram of an application scenario provided in the embodiments of this application.

[0263] Mobile phone A and PC are both receiving incoming calls, as are mobile phone B and tablet. At this moment, mobile phone B (the local device) initiates a collaborative / differential call to PC (the peer device). The subsequent collaborative / differential call has a low audio priority on both mobile phone B and PC. Mobile phone B then issues a notification indicating dual-device occupancy and whether it wants to preempt the call. Figure 13 The mobile phone A shown displays a selection control for service usage and whether it is preempted. The selection control includes "Yes" and "No".

[0264] After receiving the user's "Yes" input command to preempt the call, mobile phone B deactivates the cross-device call service to the Pad, ending the call transfer on the Pad and returning the call to mobile phone B. It also notifies the PC to deactivate its corresponding call service, and the PC transfers the audio stream of the call back to mobile phone A, ending the call service on the PC. Mobile phone B then reactivates the collaborative / heterogeneous service to the PC, completing the audio transfer to the PC. Figure 13 As shown, the screen and audio of phone B are projected onto the PC interface, completing the collaboration and successfully preempting the call. Specifically, while phone B's call is still active, the audio is transferred to the PC via collaborative / heterogeneous data transfer, allowing the user to answer the call on the PC while simultaneously interacting with the projected screen of phone B using a mouse or touchscreen. When phone B receives a "no" command from the user to not preempt the call, it maintains incoming call services between phone A and the PC, as well as between phone B and the tablet.

[0265] Scenario 5: Local devices with the same priority occupy space.

[0266] like Figure 13 As shown, this is another example diagram of an application scenario provided in the embodiments of this application.

[0267] Mobile phone A and PC are running a collaborative service, where the screen and audio of mobile phone A are projected onto the PC's interface for display and playback, allowing control of the mobile phone via the PC. At this time, the PC (local device) initiates a follow-along service to the Pad (peer device); for example... Figure 13 As shown, on the PC's display interface, the follow-up service is initiated to the Pad via the trust ring.

[0268] The accompanying flight service and the collaborative service both use Audio as their resource and have the same priority. Since resources with the same priority cannot be forcibly occupied, the audio priority query result for the later-initiated accompanying flight service on the PC will be lower. If the Pad is available, a prompt will be sent on the PC indicating whether the service is currently occupied and whether it is ready to preempt the access request. Figure 14 The PC client displays a selection control for service usage and whether to preempt the service. This selection control includes "Yes" and "No".

[0269] After receiving the user's "Yes" command to preempt the call, the PC ends the collaborative service with mobile phone A, thus ending the PC's collaborative service. The PC then re-enables the follow-along service on the Pad, completing the screen extension and audio streaming to the Pad. Figure 14 As shown, the PC extends its screen to the Pad, displaying a first window on the PC and a second window on the Pad. The second window on the Pad can be controlled using the mouse, and video and audio can be played through it, completing the follow-along and successfully preempting the device. When the PC receives a "No" command from the user to not preempt, it maintains the collaborative service between the PC and mobile phone A.

[0270] Scenario 6: When querying the local and remote endpoint occupancy status sequentially, the corresponding local and remote endpoint occupancy is as follows.

[0271] like Figure 15 As shown, this is another example diagram of an application scenario provided in the embodiments of this application.

[0272] Mobile phone A and PC are receiving incoming calls, while mobile phone B and tablet are also receiving incoming calls. At this moment, mobile phone B (the local device) initiates a collaborative service to PC (the peer device).

[0273] For subsequent collaborative services, phone B first checks its local audio resource allocation. If the audio priority of the collaborative service on phone B is low, phone B sends a notification indicating local resource allocation and whether it intends to preempt the service. Figure 15 The mobile phone B shown displays a service occupancy (local end) and a selection control for whether to preempt the service. The selection control includes "Yes" and "No".

[0274] When phone B receives the user's "No" input to not preempt, the incoming call service between phone B and the tablet is maintained. When phone B receives the user's "Yes" input to preempt, the cross-device incoming call service to the tablet is disabled, the call flow on the tablet ends, and the call flow is returned to phone B; phone B continues to enable the collaborative service to the PC; at this time, the virtualization capability corresponding to the incoming call service on phone B (this end) has ended, and the audio priority of the virtualization capability corresponding to the collaborative service on this end is high priority; the occupancy status of the PC (the other end) is checked again. At this time, the PC and phone A are in the incoming call service, and the audio priority of the collaborative service on the PC is low priority. Phone B continues to send prompts about the other end's occupancy and whether to preempt; Figure 15 The mobile phone B shown displays a service occupancy (peer end) and a selection control for whether to preempt the service, which includes "Yes" and "No".

[0275] After receiving the user's "Yes" input command to preempt the call, mobile phone B notifies the PC to deactivate its corresponding incoming call service. The PC then transfers the audio stream of the incoming call service back to mobile phone A, ending the incoming call service on the PC. Mobile phone B then re-enables the collaborative service to the PC, completing the audio stream transfer to the PC. Figure 15 As shown, the screen and audio of mobile phone B are projected onto the PC interface to complete the collaboration and successfully seize the call. That is, while the call on mobile phone B is not disconnected, the audio of the call is transferred to the PC based on the collaboration / heterogeneous service flow. Thus, the user can answer the call on the PC and operate the interface of mobile phone B projected on the PC via mouse or touch.

[0276] When mobile phone B receives a "No" command from the user to not preempt the call, it maintains the incoming call service between mobile phone A and the PC; and the incoming call service between mobile phone B and the tablet. When mobile phone B receives a "No" command from the user to not preempt the call, it maintains the incoming call service between mobile phone A and the PC.

[0277] Scenario 7: Enable subsequent business processes directly when capabilities are available.

[0278] like Figure 16 As shown, this is another example diagram of an application scenario provided in the embodiments of this application.

[0279] The PC and Pad are currently in the onboarding service, which uses audio resources. At this time, the phone initiates another call sharing service to the Pad, such as... Figure 16The example shown demonstrates how to select the tablet as the target device for the call flow by triggering a control on the phone's call interface. At this point, the phone (local device) checks the tablet's usage status. If the modem priority for the incoming call service is higher than the audio priority for the onboard service, and the audio priority for the incoming call service on the tablet is high, then the capability is available and enabled successfully. Figure 16 As shown, the call audio stream from the phone is transferred to the Pad; the call was successfully preempted.

[0280] For example, the incoming call service can also be triggered by other interfaces. For instance, when the phone has call sharing enabled, the interface of the Pad running the Hangback service on the PC can display an incoming call banner, directly seizing the audio stream capability resources by answering the call.

[0281] It should be noted that, in the above embodiments, the audio priority of the capability resources used by the target service in the device is the audio priority of the virtualization capabilities used by the target service in the electronic device; that is, the capability resources mentioned in the above embodiments are the virtualization capability resources in the electronic device for the target service; the priority of the virtualization capabilities on different devices can be configured based on the user's actual application scenario, or it can be passed in when the target service calls the enabled interface. The display interface diagram of the above embodiments is only an illustrative example of the scenario where audio conflicts exist in multiple concurrent services, and the audio streams corresponding to each service are flexibly transferred based on user selection and the capabilities of each device. It does not limit the actual display interface. For some more complex scenarios, it is also possible to occupy capability resources only and keep the video picture of the original service paused (i.e., the picture remains unchanged temporarily, and the audio is temporarily stopped).

[0282] Corresponding to the examples of the above implementation principles and various application scenarios, this application also provides a schematic diagram of an audio conflict handling method, such as... Figure 17 As shown, based on the same implementation principle as above, and without further elaboration, this method may include the following steps:

[0283] S1701, when a user initiates a request instruction for a target service to the second device, the audio priorities of the target service on the first device and the second device are obtained respectively, and the audio priorities include high priority and low priority.

[0284] S1702, when the audio priority of the target service corresponding to at least one of the first and second devices is low, display a prompt message indicating service occupancy and a selection control for whether to preempt the service on the display interface.

[0285] S1703, in response to the preemption command input by the user clicking the selection control, enables the initiation of the target service to the second device.

[0286] In this context, the second device is the peer device, the target service is the service initiated later, and the request command is the command to initiate services such as collaboration or follow-up in the aforementioned application scenarios. The capability resources required by the target service have different priorities in electronic devices. For example, the audio priority corresponds to an audio level identifier of 0, while the modem priority corresponds to an audio level identifier of 1, meaning the modem priority is higher than the audio priority. Accordingly, when the capability resource required by the later-initiated service is audio, if the service currently running on the local or peer device occupies modem resources, the audio priority of the later-initiated service on the local or peer device will be lower, and a notification of local, peer, or dual-device occupancy will be issued. Upon receiving a preemption command, the current service can be disabled, and once the capability resources become available again, the enabling of the later-initiated service can continue.

[0287] In some embodiments, the method sequentially queries the occupancy status of the local and remote ends. When a user initiates a request for a target service to the second device, the method further includes:

[0288] Obtain the first audio priority of the target service on the first device; if the first audio priority is high, obtain the second audio priority of the target service on the second device; if the second audio priority is high, initiate the enabling of the target service to the second device; or, if the second audio priority is low, display a prompt message indicating service occupancy and a selection control for whether to preempt the service on the display interface.

[0289] Accordingly, when the first audio priority is low, a prompt message indicating service occupancy and a selection control for whether to preempt the service are displayed on the display interface; in response to the preemption command entered by the user clicking the selection control, the second audio priority of the target service on the second device is obtained; when the second audio priority is high, the enabling of the target service is initiated to the second device; or, when the second audio priority is low, a prompt message indicating service occupancy and a selection control for whether to preempt the service are displayed on the display interface.

[0290] In one possible implementation, during the query process, obtaining the audio priority of the target service on the first device includes: querying the first service status of the first device; when the first service status is occupied, comparing the audio level of the first current service on the first device with the audio level of the target service to determine the audio priority of the target service on the first device; or, when the first service status is unoccupied, determining that the audio priority of the target service on the first device is high priority.

[0291] In one possible implementation, the audio priority of the target service on the second device is obtained by sending a query command to the second device to query the occupancy status. This includes: sending a query command to the second device; the query command instructing the second device to query the status of the second service, and when the second service status is occupied, determining the audio priority of the target service on the second device by comparing the audio level of the second current service on the second device with the audio level of the target service; or, when the second service status is unoccupied, determining that the audio priority of the target service on the second device is high priority; and receiving the audio priority of the target service on the second device sent by the second device.

[0292] In one possible implementation, in order to improve the response rate of the processing flow, during the process of obtaining the occupancy status based on querying the device management profile module, the audio priority of the target service on the first device and the second device is obtained, including: determining the audio priority of the target service on the first device and the second device by querying the device management module. The device management module is used to store and synchronize the audio service information of the first device and the second device. The audio service information includes the first service status and audio level of the first device, and the second service status and audio level of the second device.

[0293] Accordingly, after enabling the target service to be initiated to the second device, the method further includes: updating the audio service information of the first device in the device management module, and synchronizing the updated audio service information in the device management module to the second device. Before determining the audio priority of the target service on the first and second devices by querying the device management module, the method further includes: sending an initialization command to the second device, which instructs the second device to update the audio service information in the device management module. Maintaining timely synchronization and updates ensures that the query results obtained during the query process reflect the latest service status and resource utilization of each device.

[0294] In one possible implementation, corresponding prompts are issued for different occupancy situations, and user input is received based on the prompts to preempt the service, thereby enabling the target service.

[0295] When the audio priority of the target service corresponding to at least one of the first and second devices is low, a prompt message indicating that the service is occupied and a selection control for whether to preempt the service are displayed on the display interface, including: when the audio priority of the target service is low on the first device and high on the second device, a prompt message indicating that the service is occupied and a selection control for whether to preempt the service are displayed on the display interface.

[0296] Accordingly, in response to the preemption command input by the user clicking the selection control, the enabling of initiating the target service to the second device is completed, including: in response to the preemption command input by the user clicking the selection control, ending the first current service and completing the enabling of initiating the target service to the second device.

[0297] When the target service has a high audio priority on the first device and a low audio priority on the second device, a prompt message indicating that the other end is occupying the service, along with a selection control for whether to preempt the service, is displayed on the screen. Accordingly, in response to the user's preemption command entered by clicking the selection control, the second current service ends, and the initiation of the target service to the second device is completed.

[0298] When the target service has both low audio priority on the first device and low audio priority on the second device, a dual-device occupancy prompt and a preemption selection control are displayed on the screen. Correspondingly, in response to the preemption command entered by the user clicking the selection control, the first and second current services are terminated, and the enabling of the target service to be sent to the second device is completed.

[0299] Accordingly, in response to the user's non-preemptive instruction input by clicking the selection control, the first current service of the first device and / or the second current service of the second device are maintained.

[0300] In some embodiments, during the above-described audio conflict handling method, the service type of the target service can be determined according to the request instruction; based on the service type, the audio priority of the target service on the first device and the second device can be queried. For example, for screen sharing services, the priority of the corresponding Audio resource is lower than the priority of the Modem resource corresponding to call services. When it is identified that the subsequently initiated service is a screen sharing service and the currently running service is a call service, the audio priority of the subsequently initiated service can be directly determined to be low priority; conversely, when it is identified that the subsequently initiated service is a call service and the currently running service is a screen sharing service, the audio priority of the subsequently initiated service can be directly determined to be high priority. When it is identified that the subsequently initiated service and the currently running service are of the same type, the audio priority of the subsequently initiated service is directly determined to be low priority.

[0301] This application embodiment provides a query for the status of capability resource occupancy and manages the corresponding audio priority of services. When calling the enable interface, it dynamically schedules audio streams based on user selection, business needs, and device capabilities. This can flexibly address and handle audio conflicts that occur when multiple services are running concurrently. It can be applied to more complex, changeable, and emergency application scenarios, improving the user experience.

[0302] It should be understood that the sequence number of each step in the above embodiments 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.

[0303] Corresponding to the audio conflict handling method provided in the above embodiments, Figure 18 A schematic diagram of the audio conflict processing device provided in the embodiments of this application is shown. For ease of explanation, only the parts related to the embodiments of this application are shown.

[0304] Reference Figure 18 The device includes:

[0305] The acquisition unit 1801 is used to acquire the audio priority of the target service in the first device and the second device respectively when a user initiates a request instruction for the target service to the second device. The audio priority includes high priority and low priority.

[0306] The display unit 1802 is used to display a prompt message about service occupancy and a selection control for whether to preempt the service on the display interface when the audio priority of the target service corresponding to at least one of the first device and the second device is low.

[0307] The control unit 1803 is used to enable the initiation of the target service to the second device in response to the preemption command input by the user clicking the selection control.

[0308] In one possible implementation, the acquisition unit 1801 is further configured to acquire the first audio priority of the target service on the first device; when the first audio priority is high, acquire the second audio priority of the target service on the second device; the control unit 1803 is further configured to enable the target service to the second device when the second audio priority is high; or, the display unit 1802 is further configured to display a prompt message indicating service occupancy and a selection control for whether to preempt the service on the display interface when the second audio priority is low.

[0309] In one possible implementation, the display unit 1802 is further configured to display a service occupancy prompt and a preemption selection control on the display interface when the first audio priority is low; the control unit 1803 is further configured to, in response to a preemption command input by the user clicking the selection control, obtain the second audio priority of the target service on the second device; and, when the second audio priority is high, complete the enabling of the target service to the second device; or, the display unit 1802 is further configured to display a service occupancy prompt and a preemption selection control on the display interface when the second audio priority is low.

[0310] In one possible implementation, the acquisition unit 1801 is further configured to query the first service status of the first device; when the first service status is occupied, compare the audio level of the first current service of the first device with the audio level of the target service to determine the audio priority of the target service in the first device; or, when the first service status is unoccupied, determine that the audio priority of the target service in the first device is high priority.

[0311] In one possible implementation, the acquisition unit 1801 is further configured to send a query instruction to the second device; the query instruction is configured to instruct the second device to query the status of the second service, and when the second service status is occupied, to determine the audio priority of the target service on the second device by comparing the audio level of the second current service on the second device with the audio level of the target service, or, when the second service status is unoccupied, to determine that the audio priority of the target service on the second device is high priority; and to receive the audio priority of the target service on the second device sent by the second device.

[0312] In one possible implementation, the acquisition unit 1801 is further configured to determine the audio priority of the target service on the first device and the second device by querying the device management module. The device management module is configured to store and synchronize the audio service information of the first device and the second device. The audio service information includes the first service status and audio level of the first device, and the second service status and audio level of the second device. Correspondingly, the control unit 1803 is further configured to update the audio service information of the first device in the device management module, and synchronize the updated audio service information in the device management module to the second device.

[0313] In one possible implementation, the acquisition unit 1801 is further configured to send an initialization command to the second device, the initialization command being used to instruct the second device to update the audio service information in the device management module.

[0314] In one possible implementation, the display unit 1802 is further configured to display a prompt message indicating that the target service is occupied and a selection control for whether to preempt the target service on the display interface when the audio priority of the first device is low and the audio priority of the second device is high; correspondingly, the control unit 1803 is further configured to end the first current service and enable the target service to be initiated to the second device in response to the preemption command input by the user clicking the selection control.

[0315] In one possible implementation, the display unit 1802 is further configured to display a prompt message indicating that the target service is occupied by the other end and a selection control for whether to preempt the service on the display interface when the audio priority of the first device is high and the audio priority of the second device is low; correspondingly, the control unit 1803 is further configured to end the second current service and complete the enabling of the target service to be initiated to the second device in response to the preemption command input by the user clicking the selection control.

[0316] In one possible implementation, the display unit 1802 is further configured to display a prompt message indicating dual-end occupancy and a selection control for whether to preempt the target service on the display interface when the audio priority of the first device is low and the audio priority of the second device is low; correspondingly, the control unit 1803 is further configured to respond to the preemption command input by the user clicking the selection control, terminate the first current service and the second current service, and complete the enabling of the target service to be initiated to the second device.

[0317] In one possible implementation, the control unit 1803 is further configured to maintain the first current service of the first device and / or the second current service of the second device in response to a non-preemptive instruction input by the user clicking the selection control.

[0318] In one possible implementation, the request instruction includes the target capability resource name of the target service; the acquisition unit 1801 is further configured to query the target audio level corresponding to the capability resource name in the audio level configuration list based on the target capability resource name; and determine the audio priority of the target service on the first device and the second device based on the target audio level.

[0319] In one possible implementation, the request instruction includes the target capability resource name and the target audio level of the target service; the acquisition unit 1801 is further configured to pass the target capability resource name and the target audio level to the capability resource level key-value pair in the first device and the second device; and determine the audio priority of the target service in the first device and the second device by querying the capability resource level key-value pair.

[0320] In one possible implementation, the acquisition unit 1801 is further configured to determine the service type of the target service according to the request instruction; and based on the service type, query the audio priority of the target service on the first device and the second device respectively.

[0321] This application embodiment provides a query for the status of capability resource occupancy and manages the corresponding audio priority of services. When calling the enable interface, it dynamically schedules audio streams based on user selection, business needs, and device capabilities. This can flexibly address and handle audio conflicts that occur when multiple services are running concurrently. It can be applied to more complex, changeable, and emergency application scenarios, improving the user experience.

[0322] Figure 19 A hardware system for an electronic device applicable to this application is shown.

[0323] Electronic device 100 can be a mobile phone, smart screen, tablet computer, wearable electronic device, in-vehicle electronic device, augmented reality (AR) device, virtual reality (VR) device, laptop computer, ultra-mobile personal computer (UMPC), netbook, personal digital assistant (PDA), projector, and other electronic devices. This application embodiment does not limit the specific type of electronic device 100.

[0324] Electronic device 100 may include processor 110, external memory interface 120, internal memory 121, universal serial bus (USB) interface 130, charging management module 140, power management module 141, battery 142, antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, sensor module 180, button 190, motor 191, indicator 192, camera 193, display screen 194, and subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0325] It should be noted that, Figure 19 The structure shown does not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include... Figure 19 The components shown may include more or fewer components, or the electronic device 100 may include... Figure 19 The components shown may be a combination of certain components, or the electronic device 100 may include... Figure 19 Sub-components of some of the components shown. Figure 19 The components shown can be implemented in hardware, software, or a combination of both.

[0326] The software system of electronic device 100 is described below. The software system can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This application embodiment takes a layered architecture as an example to exemplarily describe the software system of electronic device 100.

[0327] like Figure 20 As shown, the interaction flow between modules between the first device (local end) and the second device (peer end) when running cross-device services is illustrated. The first device can be the local device that initiates service enable, such as a mobile phone or tablet computer, and the second device can be the peer device that responds to the service enable, such as a smart screen, a laptop computer, or an in-vehicle terminal. This is only an example and is not specifically limited.

[0328] In the process of enabling business:

[0329] 1.1 The first device receives user input and determines the virtual audio device to be used for the enabled service. For example, based on user-triggered collaborative applications, HiCar (an in-vehicle terminal interconnection application), and HiCall (a super caller ID service), it determines the required virtual audio device.

[0330] 1.2. Through application layer business triggers, send an instruction to enable the virtual audio device to the device management module in the DMSDP service unit.

[0331] 1.3.1 The device management module of the first device sends an initialization command to the audio processing and transmission protocol module to determine the transmission protocol of the audio signal, such as sampling rate, bit width or number of channels.

[0332] 1.3.2 The audio processing and transmission protocol module of the first device registers its transmission interface with the Virtual Audio device in the Hardware Abstraction Layer (HAL). The Audio HIDL Service in the HAL defines the interaction interface between the audio hardware and the Android framework, reducing the coupling between the application framework layer and the HAL. During the Virtual Audio device registration process, a shared object (SO) file can be added to the virtual audio device to start the Audio HIDL Service, defining the HIDL interface to describe the functionality and behavior of the virtual audio device.

[0333] 1.4 After completing the registration of the transmission interface, the activation status of the virtual audio is synchronized to the audio policy service module of the audio subsystem of the first device.

[0334] During the process of enabling business operations and running across devices:

[0335] 2.1 The first device receives a user-triggered call to the audio component's service. For example, selecting the HiCall service.

[0336] 2.2 The first device starts the corresponding audio components based on the user-triggered service. The Audio subsystem includes MediaPlayer, MediaRecorder, AudioTrack, AudioRecord, and AudioFlinger.

[0337] 2.3 The first device switches to the virtual audio device according to preset conditions through the audio policy service module.

[0338] For example, the audio policy service module is configured with a policy that selects whether the audio is played from the local hardware peripheral (such as the local speaker) or the virtual device when a virtual device is present. Currently, the audio policy corresponding to the preset conditions of the audio policy service module can be that when there is a Bluetooth peripheral (a virtual device), the virtual device has the highest priority and the audio is played from the virtual device by default.

[0339] 2.4 Select the virtual audio device to work according to the audio policy service module.

[0340] 2.5. The audio signal of the Audio subsystem is resampled and encoded / decoded using the audio processing and transmission protocol module to obtain the audio signal to be transmitted.

[0341] 2.6. Transmit the audio signal to be transferred to the data transmission module.

[0342] 2.7 The first device outputs the processed audio signal to be transferred to the data transmission module of the second device through the data transmission module.

[0343] 2.8 The data transmission module of the second device transmits the received audio signal to the audio processing / audio transmission module for processing.

[0344] 2.9 The second device transmits the further processed audio signal to the Audio subsystem of the Android device or the Audio module of the Linux device (or liteOS device) through different interfaces to complete the audio signal transfer.

[0345] Correspondingly, when audio conflicts occur during concurrent multi-service operation, the DMSDP module can compare the priorities of virtual audio devices to report the service occupancy status of the devices to the application layer. Based on the user's choice, it can then terminate the original service and re-enable it. For example, it can re-register the transmission interface for a new service and synchronously re-register active virtual audio devices with the audio policy service module, which then determines the virtual audio device to switch to. For instance, if the later-initiated service is a collaborative audio playback service, the audio signal to be played will be transferred to the second device via the data transmission module for playback.

[0346] For example, when the second device is in the incoming call service state as the peer, based on the user's preemption instruction, another local device initiates a collaborative service to the second device again. Then, the second device no longer receives data transmission from the first device, transfers the audio signal back to the first device, ends the running incoming call service, responds to the collaborative service initiated by the other local device, and completes the enabling.

[0347] It should be understood that the modules in the software architecture shown in the diagram above are merely illustrative examples illustrating the process of flexibly transferring and terminating audio signals based on user selection when audio conflicts occur due to multiple concurrent services on an electronic device. This does not limit the applicable scenarios. Different transmission interfaces can be registered, different audio components can be activated, and different virtual audio devices can be selected for different services and preemptive application scenarios.

[0348] Corresponding to the audio conflict handling method provided in the above embodiments, the audio conflict handling system provided in this application embodiment may include a first device and a second device, and implement the methods of the above embodiments based on the first device and the second device.

[0349] This application also provides a chip system applied to an electronic device. The chip system includes one or more processors, which are used to invoke computer instructions to cause the electronic device to perform the methods described in the above embodiments.

[0350] This application also provides a computer-readable storage medium including instructions that, when executed on an electronic device, cause the electronic device to perform the method as described in the above embodiments.

[0351] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially as a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, optical fiber, Digital Subscriber Line, DSL) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access, or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., Digital Versatile Discs (DVDs)), or semiconductor media (e.g., Solid State Disks (SSDs)).

[0352] The above-described embodiments are optional embodiments provided by this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the technical scope disclosed in this application should be included within the protection scope of this application.

Claims

1. An audio conflict resolution method, characterized in that, Applied to a first device, the method includes: When a user initiates a request for a target service to the second device, the audio priority of the target service on the first device and the second device is obtained, and the audio priority includes high priority and low priority; wherein, the second device is the peer device; When the audio priority of the target service corresponding to at least one of the first device and the second device is the low priority, a prompt message indicating service occupancy and a selection control for whether to preempt the service are displayed on the display interface. When the method detects a user's request instruction to the second device for a target service, it further includes: Obtain the first audio priority of the target service on the first device; When the first audio priority is the low priority, a prompt message indicating that the service is occupied and a selection control for whether to preempt the service are displayed on the display interface. In response to the preemption command input by the user clicking the selection control, the second audio priority of the target service on the second device is obtained; When the second audio priority is the high priority, enable the initiation of the target service to the second device is completed; When the second audio priority is the low priority, a prompt message indicating service occupancy and a selection control for whether to preempt the service are displayed on the display interface; in response to the preemption command entered by the user by clicking the selection control, the target service is enabled by initiating the process to the second device.

2. The method according to claim 1, characterized in that, The method further includes: When the first audio priority is the high priority, obtain the second audio priority of the target service on the second device; When the second audio priority is the high priority, enable the initiation of the target service to the second device; or, When the second audio priority is the low priority, a prompt message indicating service occupancy and a selection control for whether to preempt the service are displayed on the display interface; in response to the preemption command entered by the user by clicking the selection control, the target service is enabled by initiating the process to the second device.

3. The method according to any one of claims 1 to 2, characterized in that, Obtaining the audio priority of the target service on the first device further includes: Query the first service status of the first device; When the first service status is occupied, the audio level of the first current service on the first device is compared with the audio level of the target service to determine the audio priority of the target service on the first device; or... When the first service status is unoccupied, the audio priority of the target service on the first device is determined to be the high priority.

4. The method according to claim 3, characterized in that, Obtaining the audio priority of the target service on the second device includes: Send a query instruction to the second device; the query instruction is used to instruct the second device to query the status of the second service, and when the second service status is occupied, determine the audio priority of the target service on the second device by comparing the audio level of the second current service on the second device with the audio level of the target service, or, when the second service status is unoccupied, determine that the audio priority of the target service on the second device is high priority. The target service sent by the second device is received in the audio priority of the second device.

5. The method according to any one of claims 1 to 2, characterized in that, The request instruction includes the target capability resource name of the target service; obtaining the audio priority of the target service on the first device and the second device respectively includes: Based on the target capability resource name, query the target audio level corresponding to the target capability resource name in the audio level configuration list; Based on the target audio level, the audio priority of the target service on the first device and the second device is determined.

6. The method according to any one of claims 1 to 2, characterized in that, The request instruction includes the target capability resource name and target audio level of the target service; obtaining the audio priority of the target service on the first device and the second device respectively includes: The target capability resource name and the target audio level are passed into the capability resource level key-value pair in the first device and the second device; By querying the capability resource level key-value pairs, the audio priority of the target service on the first device and the second device is determined.

7. The method according to any one of claims 1 to 2, characterized in that, The step of obtaining the audio priority of the target service on the first device and the second device respectively further includes: Based on the request instruction, determine the service type of the target service; Based on the service type, query the audio priority of the target service on the first device and the second device respectively.

8. An audio conflict resolution method, characterized in that, Applied to a first device, the method includes: When a user initiates a request for a target service to the second device, the audio priority of the target service on the first device and the second device is obtained, and the audio priority includes high priority and low priority; wherein, the second device is the peer device; When the audio priority of the target service corresponding to at least one of the first device and the second device is the low priority, a prompt message indicating service occupancy and a selection control for whether to preempt the service are displayed on the display interface, including: When the audio priority of the target service is low on the first device and low on the second device, a prompt message indicating dual-end occupancy and a selection control for whether to preempt the service are displayed on the display interface. In response to the preemption command input by the user clicking the selection control, the first current service of the first device and the second current service of the second device are terminated, and the enabling of the target service to be initiated to the second device is completed.

9. The method according to claim 8, characterized in that, When the audio priority of the target service corresponding to at least one of the first device and the second device is the low priority, a prompt message indicating service occupancy and a selection control for whether to preempt the service are displayed on the display interface, including: When the target service has a low audio priority on the first device and a high audio priority on the second device, a prompt message indicating that the local device is occupying the service and a selection control for whether to preempt the service are displayed on the display interface. In response to the preemption command input by the user clicking the selection control, the first current service is terminated, and the enabling of the target service is completed for the second device.

10. The method according to claim 8, characterized in that, When the audio priority of the target service corresponding to at least one of the first device and the second device is the low priority, a prompt message indicating service occupancy and a selection control for whether to preempt the service are displayed on the display interface, including: When the target service has a high audio priority on the first device and a low audio priority on the second device, a prompt message indicating that the other end is occupying the service and a selection control for whether to preempt the service are displayed on the display interface. In response to the preemption command input by the user clicking the selection control, the second current service is terminated, and the enabling of the target service is completed for the second device.

11. The method according to claim 8, characterized in that, After displaying the service occupancy notification and a preemption option on the display interface, the method further includes: In response to a non-preemption instruction input by the user clicking the selection control, the first current service of the first device and / or the second current service of the second device are maintained.

12. The method according to claim 8, characterized in that, The step of obtaining the audio priority of the target service on the first device and the second device respectively includes: By querying the device management module corresponding to the first device, the audio priority of the target service on the first device and the second device is determined. The device management module is used to store and synchronize the audio service information of the first device and the second device. The audio service information includes the audio level corresponding to the first service status and capability resources of the first device, and the audio level corresponding to the second service status and capability resources of the second device. Accordingly, after enabling the target service to the second device, the method further includes: Update the audio service information of the first device in the device management module corresponding to the first device, and synchronize the updated audio service information in the device management module corresponding to the first device to the second device.

13. The method according to claim 12, characterized in that, Before determining the audio priority of the target service on the first device and the second device respectively by querying the device management module corresponding to the first device, the method further includes: An initialization command is sent to the second device, which instructs the second device to update the audio service information in the device management module corresponding to the second device.

14. An audio conflict processing device, characterized in that, Applied to a first device, the device includes: The acquisition unit is configured to acquire the audio priority of the target service on the first device and the second device respectively when a user initiates a request instruction for the target service to the second device, wherein the audio priority includes high priority and low priority; wherein the second device is the peer device; The display unit is configured to display a prompt message indicating whether the service is occupied and a selection control for whether to preempt the service on the display interface when the audio priority of the target service corresponding to at least one of the first device and the second device is the low priority. The acquisition unit is further configured to acquire the first audio priority of the target service on the first device; The display unit is also used to display a prompt message about service occupancy and a selection control for whether to preempt the service on the display interface when the first audio priority is the low priority. The control unit is configured to respond to a preemption command input by the user clicking the selection control, obtain the second audio priority of the target service on the second device, and enable the target service to the second device when the second audio priority is the high priority. The display unit is also used to display a prompt message about service occupancy and a selection control for whether to preempt the service on the display interface when the second audio priority is the low priority. The control unit is also configured to enable the target service to be initiated to the second device in response to a preemption command input by the user clicking the selection control.

15. An electronic device, characterized in that, The electronic device includes: one or more processors, and memory; The memory is coupled to the one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, the one or more processors invoking the computer instructions to cause the electronic device to perform the method as described in any one of claims 1 to 13.

16. An audio conflict handling system, characterized in that, The system includes a first device and a second device, the second device being communicatively connected to the first device, and the first device being used to execute the audio conflict processing method as described in any one of claims 1 to 7; The first device is configured to, when detecting a user's request instruction to the second device for a target service, obtain the audio priority of the target service on the first device and the second device respectively, wherein the audio priority includes high priority and low priority; wherein the second device is the peer device; The first device is further configured to display a prompt message indicating service occupancy and a selection control for whether to preempt the service on the display interface when the audio priority of the target service corresponding to at least one of the first device and the second device is the low priority. The first device is further configured to obtain the first audio priority of the target service on the first device; The first device is further configured to display a prompt message indicating service occupancy and a selection control for whether to preempt the service on the display interface when the first audio priority is the low priority. The first device is further configured to respond to a preemption command input by the user clicking the selection control, obtain the second audio priority of the target service on the second device; and when the second audio priority is the high priority, complete the enabling of the target service to the second device; The first device is further configured to display a prompt message indicating service occupancy and a selection control for whether to preempt service on the display interface when the second audio priority is the low priority, and to enable the target service to the second device in response to the preemption command input by the user clicking the selection control.

17. The system according to claim 16, characterized in that, The first device is also used to send a query command to the second device; The second device is further configured to query the second service status based on the query instruction, and when the second service status is occupied, determine the audio priority of the target service on the second device by comparing the audio level of the second current service on the second device with the audio level of the target service; or, when the second service status is unoccupied, determine that the audio priority of the target service on the second device is high priority, and feed back the audio priority of the target service on the second device to the first device. The first device is also used to receive the audio priority of the target service on the second device.

18. The system according to claim 16, characterized in that, The first device is also configured to send a service termination instruction to the second device in response to a preemption instruction input by the user clicking the selection control when displaying a prompt message indicating that the peer device is occupying the service; The second device is further configured to receive the service termination instruction and, based on the service termination instruction, terminate the second current service of the second device.

19. An audio conflict handling system, characterized in that, The system includes a first device and a second device; The first device is configured to, when detecting a user's request instruction to the second device for a target service, obtain the audio priority of the target service on the first device and the second device respectively, wherein the audio priority includes high priority and low priority; wherein the second device is the peer device; The first device is further configured to display a prompt message indicating service occupancy and a selection control for whether to preempt the service on the display interface when the audio priority of the target service corresponding to at least one of the first device and the second device is the low priority. The first device is also configured to, in response to a preemption command input by the user clicking the selection control, enable the initiation of the target service to the second device; The first device is further configured to display a prompt message indicating dual-end occupancy and a selection control for whether to preempt the target service on the display interface when the audio priority of the target service on the first device is the low priority and the audio priority of the second device is the low priority. The first device is further configured to, in response to a preemption command input by the user clicking the selection control, terminate the first current service of the first device and the second current service of the second device, and enable the initiation of the target service to the second device.

20. The system according to claim 19, characterized in that, The first device is also configured to send a service termination instruction to the second device in response to a preemption instruction input by the user clicking the selection control when displaying a prompt message indicating dual-end occupancy; The second device is further configured to receive the service termination instruction and stop the second current service based on the service termination instruction.

21. The system according to claim 20, characterized in that, The first device is further configured to send an initialization command to the second device before obtaining the audio priority of the target service on the second device; The second device is further configured to receive the initialization instruction and update the audio service information in the device management module corresponding to the second device based on the initialization instruction; the audio service information includes the audio level corresponding to the first service status and capability resources of the first device, and the audio level corresponding to the second service status and capability resources of the second device; Accordingly, the first device is further configured to, after enabling the target service to be initiated to the second device, update the audio service information of the first device in the device management module corresponding to the first device, and send a first synchronization command to the second device; The second device is further configured to receive the first synchronization instruction and, based on the first synchronization instruction, update the audio service information in the device management module corresponding to the second device; The device management module is used to store and synchronize audio service information of the first device and the second device.

22. The system according to claim 21, characterized in that, The second device is also configured to update the audio service information in the device management module corresponding to the second device after stopping the second current service, and to send a second synchronization command to the first device; The first device is further configured to receive the second synchronization instruction and, based on the second synchronization instruction, update the audio service information in the device management module corresponding to the first device.

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

24. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes instructions that, when executed on an electronic device, cause the electronic device to perform the method as described in any one of claims 1 to 13.

Images