A method, device and vehicle for controlling in-vehicle music

Abstract

This application relates to a method, apparatus, and vehicle for controlling in-vehicle music. The method includes: in response to a control command from a target application, sending a control command to a terminal device; updating the target application's target state to a waiting state corresponding to the control command based on the control command; upon receiving a status response information sent by the terminal device, updating the target state from the waiting state to an ended waiting state corresponding to the waiting state based on the status response information; and controlling the target application to perform an audio operation corresponding to the control command based on the ended waiting state. This application can improve the user experience of playing Bluetooth music in an in-vehicle system.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, specifically to an in-vehicle music control method, device, and vehicle. Background Technology

[0002] Currently, most existing in-vehicle Bluetooth music playback systems transmit data via the Bluetooth standard protocol. However, due to the wide variety of mobile phone brands and models on the market, as well as the diverse range of music players available on mobile phones, issues such as abnormal user interface (UI) display or audio logic confusion may occur when interacting with the in-vehicle system, thus affecting the user experience. Summary of the Invention

[0003] This application provides a method, device, and vehicle for controlling in-vehicle music, which can improve the user experience of playing Bluetooth music in the vehicle.

[0004] This application provides a method for controlling in-vehicle music, the method including: In response to control commands from the target application, control commands are sent to the terminal device; wherein, the control commands are used to control the target application to perform playback or pause operations; Based on the control command, the target state of the target application is updated to the waiting state corresponding to the control command; the waiting state includes the waiting to play state and the waiting to pause state. Upon receiving status response information from the terminal device, the target status is updated from the waiting state to the end-of-wait state corresponding to the waiting state based on the status response information. Based on the end-wait state, the control target application executes the audio operation corresponding to the control command; the end-wait state includes the end-wait playback state and the end-wait pause state.

[0005] Based on the aforementioned technical methods, by adding a corresponding target state (also known as an intermediate state) to the target application, the vehicle system can clearly identify the current transition phase of command execution during the delay period before the terminal device returns status response information. This avoids blindly updating the UI or executing subsequent audio operations due to missing status information. Upon receiving the status response information from the terminal device, the target state is updated from the waiting state to the corresponding "End Waiting for Playback" or "End Waiting for Pause" state, and this is used as the basis to control the target application to execute the corresponding audio operations. This effectively solves the problem of abnormal display on the vehicle system interface caused by the response delay on the mobile device, ensuring accurate correspondence between the play / pause button state and the actual audio state; it prevents logical confusion such as audio aliasing or playback freezes caused by state contention, significantly improving the stability and user experience of in-vehicle Bluetooth music control.

[0006] In some embodiments, updating the target state from a waiting state to an ended waiting state corresponding to the waiting state, based on state response information, includes: Based on the matching relationship between the status response information and the waiting status, determine whether to respond to the status response information; Once the response status and response information are determined, the target status is updated from the waiting state to the end-of-wait state corresponding to the waiting state.

[0007] According to the above technical means, after receiving the status response information, the target status is not updated unconditionally. Instead, it is verified based on the matching relationship between the information and the current waiting status (waiting for playback or waiting for pause). Only when a match is confirmed is the target status updated to the corresponding end-waiting status. This effectively filters out mismatched response information caused by terminal device abnormalities, communication delays, or status inconsistencies, preventing the vehicle-mounted system from performing subsequent audio operations based on erroneous feedback, thus preventing abnormal phenomena such as playback status jumps and interface display misalignments. In some embodiments, the status response information includes playback status information and pause status information; determining whether to respond to the status response information based on the matching relationship between the status response information and the waiting status includes: If the status response information matches the waiting status, determine the response status response information; If the status response information does not match the waiting status, the status response information is discarded.

[0008] Based on the aforementioned technical means, after receiving the status response information returned by the terminal device, a matching judgment can be made. When the status response information matches the current waiting state, the system determines to respond to the information and update the target state; when the two do not match, the status response information is directly discarded. By promptly discarding mismatched status responses, problems such as interface display errors and playback status jumps caused by the vehicle's infotainment system performing subsequent audio operations based on erroneous information are avoided. This ensures the orderly and accurate updating of the target state, significantly improving the stability of in-vehicle Bluetooth music control and the consistency of the user experience.

[0009] In some embodiments, the method further includes: after updating the target state of the target application to a waiting state corresponding to the control command, starting a timer; If no status response information matching the waiting state is received after the timer expires, the target state is updated from the waiting state to the end waiting state corresponding to the waiting state according to the control command, and the target application is controlled to perform the audio operation corresponding to the control command.

[0010] Based on the above technical means, after updating the target application's target state to the waiting state corresponding to the control command, a timer can be started. When the timer expires and no state response information matching the current waiting state is received, the system no longer passively waits for feedback from the terminal device, but actively updates the target state from the waiting state to the corresponding end-waiting state according to the original control command, and controls the target application to perform the corresponding audio operation. This can prevent the vehicle system from falling into a state of logical stagnation or interface freeze due to indefinite waiting.

[0011] In some embodiments, the control instruction includes a playback instruction; the target state includes a pause waiting state and a playback waiting state; based on the end of the pause state, the control target application performs an audio operation corresponding to the control instruction, including: When the control command is a playback command and the waiting playback status is the end of waiting playback status, the first status information of the waiting pause status within a preset duration is determined; the first status information includes the waiting pause status and the end of waiting pause status. If the first status information is "waiting for pause", it is determined to discard the status response information sent by the terminal device. If the first state information is the end of the waiting pause state, the audio focus of the target application is detected to obtain the focus detection result; Based on the focus detection results, the target application is controlled to perform audio operations corresponding to the control commands, and the audio playback status of the target application's interface is updated.

[0012] Based on the aforementioned technical means, when executing a playback command and entering a state of waiting for playback to end, the system first determines the first state information of the waiting pause state within a preset time. Differential processing is then performed based on this first state information. When the first state information is detected as "waiting for pause," it indicates that the system is currently processing a pause command. In this case, the state response information sent by the terminal device is directly discarded, preventing the ongoing pause process from being interfered with by a newly arrived playback command. When the first state information is detected as "ending waiting for pause," the audio focus of the target application is further detected. Based on the focus detection result, audio operations are controlled and the playback state of the application interface is updated. This effectively solves the state conflict problem that may occur during continuous and rapid operations. Furthermore, combined with the secondary confirmation mechanism of audio focus detection, playback failure or audio aliasing caused by focus contention is avoided, significantly improving the response accuracy of in-vehicle Bluetooth music control in complex operating scenarios and the smoothness of the user experience.

[0013] In some embodiments, based on the focus detection result, the target application is controlled to perform audio operations corresponding to the control command, and the audio playback state corresponding to the application interface of the target application is updated, including: If the focus detection result indicates that the target application has focus, control the target application to perform the audio operation corresponding to the control command, and update the audio playback status of the target application's interface to the playback status. If the focus detection result indicates that the target application does not have a focus, a focus request is sent. In response to receiving the focus request result, control the target application to perform the audio operation corresponding to the control command, and update the audio playback status of the target application's interface.

[0014] Based on the aforementioned technical means, the audio focus of the target application is detected, and differentiated operations are performed according to the detection results. When the focus detection result indicates that the target application has focus, the target application is directly controlled to execute the audio operation corresponding to the playback command and update the interface playback state, realizing rapid reuse of focus and instant audio response. When the focus detection result indicates that the target application does not have focus, a focus request is actively sent, and after receiving the focus request result, the target application is controlled to execute audio operations and update the interface state. This effectively solves the focus competition problem in multi-audio application concurrent scenarios. Through the mechanism of actively detecting and requesting focus, it is ensured that the target application has obtained the necessary system audio resources before executing the playback operation, avoiding problems such as playback failure, audio being preempted, or sound mixing with other applications due to lack of focus.

[0015] In some embodiments, in response to receiving a focus request result, the target application is controlled to perform an audio operation corresponding to the control instruction, and the audio playback state corresponding to the application interface of the target application is updated, including: If the focus application result indicates that the focus application was successful, control the target application to perform the audio operation corresponding to the control command, and update the audio playback status of the target application's application interface to the playback status. If the focus request result indicates that the focus request has failed, a pause command is sent to the terminal device, and the audio playback status of the target application's interface is updated to paused.

[0016] Based on the aforementioned technical means, after sending a focus request, differentiated operations are performed according to the returned focus request result. When the focus request is successful, the target application is normally controlled to perform audio operations and the interface is updated to a playback state, ensuring that the user's command is fully executed. When the focus request fails, a pause command is proactively sent to the terminal device, and the target application's interface is updated to a paused state. This effectively addresses playback failure scenarios caused by high-priority audio applications preempting focus. Through proactive pausing and state synchronization in failure cases, issues such as audio aliasing, playback abnormalities, or discrepancies between the displayed interface and the actual state caused by the target application forcibly playing without focus are avoided. Simultaneously, the mechanism of sending a pause command to the terminal device ensures consistency between the mobile and in-vehicle systems, preventing state asynchrony between the two ends due to focus contention failure.

[0017] In some embodiments, the control command includes a pause command; the target state further includes a waiting playback state and a waiting pause state; based on the end of the waiting state, the control target application performs an audio operation corresponding to the control command, including: When the control command is a pause command and the waiting pause status is the end of waiting pause status, determine the second status information of the waiting playback status within a preset duration; the second status information includes the current waiting playback status and the end of waiting playback status. If the second status information is "waiting to play", then the status response information sent by the terminal device is discarded. If the second state information is "End of waiting for playback", release the audio focus of the target application and update the audio playback status of the target application's interface to "paused".

[0018] According to the above technical solution, when a pause command is executed and the system is in a state of waiting for playback to end, a second state information for the waiting playback state within a preset time is determined, and differentiated processing is performed based on this information. When the second state information is detected as a state of waiting for playback, it indicates that the system is currently processing a playback command. At this time, the state response information sent by the terminal device is directly discarded, avoiding interruption or interference of the ongoing playback process by a newly arrived pause command. When the second state information is detected as a state of waiting for playback to end, the audio focus of the target application is released normally and the interface is updated to a paused state. This effectively solves the problem of playback and pause command conflicts that may occur during continuous and rapid switching operations. By judging the rationality of the pause command execution based on the playback state information, audio state jumps, playback abnormalities, or interface display errors caused by command competition are prevented.

[0019] This application provides an in-vehicle music control device, the device comprising: The sending unit is used to send control commands to the terminal device in response to control commands from the target application; wherein the control commands are used to control the playback or pause of the target application. The first update unit is used to update the target state of the target application to a waiting state corresponding to the control command based on the control command; wherein the waiting state includes a waiting to play state and a waiting to pause state; The second update unit is used to update the target state from the waiting state to the end waiting state corresponding to the waiting state based on the status response information sent by the terminal device when it receives the status response information sent by the terminal device. The control unit is used to control the target application to perform audio operations corresponding to the control commands based on the end-wait state; wherein the end-wait state includes the end-wait playback state and the end-wait pause state.

[0020] This application provides a vehicle including a processor and a memory. The memory stores a computer program that can run on the processor. When the processor executes the computer program, it implements the steps in any of the above methods.

[0021] This application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps in any of the above methods.

[0022] This application provides a computer program product, including a computer program or instructions, which, when executed by a processor, implement the steps of any of the above methods.

[0023] The beneficial effects of this application are: (1) By adding a corresponding target state (also known as an intermediate state) to the target application, the vehicle system can clearly identify the current transition phase of instruction execution during the delay period before the terminal device returns the status response information, thereby avoiding blindly updating the UI or executing subsequent audio operations due to missing status information. After receiving the status response information returned by the terminal device, the target state is updated from the waiting state to the corresponding "end waiting for playback state" or "end waiting for pause state" based on the status response information, and the target application is controlled to perform the corresponding audio operation based on this. This can effectively solve the problem of abnormal display of the vehicle interface caused by the response delay of the mobile terminal, ensure the accurate correspondence between the play / pause button state and the actual audio state; prevent logical confusion such as audio aliasing or playback freezing caused by state competition, and significantly improve the stability and user experience of vehicle Bluetooth music control.

[0024] (2) After receiving the status response information, the target status is not updated unconditionally. Instead, the information is checked against the current waiting status (waiting for playback or waiting for pause). The target status is updated to the corresponding end waiting status only if the match is confirmed. This effectively filters out mismatched response information caused by terminal device abnormalities, communication delays or status errors, and avoids the vehicle terminal from performing subsequent audio operations based on incorrect feedback. This prevents abnormal phenomena such as playback status jumps and interface display misalignment.

[0025] (3) After receiving the status response information returned by the terminal device, a matching judgment can be made on it. When the status response information matches the current waiting state, the system determines to respond to the information and update the target state; when the two do not match, the status response information is discarded directly. By discarding the mismatched status response in a timely manner, problems such as interface display disorder and playback status jump caused by the vehicle terminal performing subsequent audio operations based on the error information are avoided. This ensures the orderliness and accuracy of the target state update and significantly improves the stability of the vehicle Bluetooth music control and the consistency of the user experience.

[0026] (4) After updating the target state of the target application to the waiting state corresponding to the control command, a timer can be started. When the timer expires and no state response information matching the current waiting state is received, the system will no longer passively wait for feedback from the terminal device, but will actively update the target state from the waiting state to the corresponding end waiting state according to the original control command, and control the target application to perform the corresponding audio operation. This can prevent the vehicle system from falling into a state of logical stagnation or interface freeze due to indefinite waiting.

[0027] (5) When executing a playback command and in the state of waiting for playback to end, the first state information of the waiting pause state within the preset time is first determined, and differentiated processing is performed according to the first state information. When the first state information is detected as waiting for pause, it indicates that the system is currently in the process of processing the pause command. At this time, the state response information sent by the terminal device is directly discarded to avoid the pause process being interfered with by the newly arrived playback command. When the first state information is detected as waiting for pause to end, the audio focus of the target application is further detected. Based on the focus detection result, the audio operation is controlled and the playback state of the application interface is updated, thereby effectively solving the state conflict problem that may occur in continuous and rapid operation. At the same time, combined with the secondary confirmation mechanism of audio focus detection, playback failure or audio aliasing caused by focus contention is avoided, which significantly improves the response accuracy of the in-vehicle Bluetooth music control in complex operation scenarios and the smoothness of the user experience.

[0028] (6) By detecting the audio focus of the target application and performing differentiated operations based on the detection results, when the focus detection result indicates that the target application has focus, the target application is directly controlled to perform the audio operation corresponding to the playback command and update the interface playback state, thus realizing the rapid reuse of focus and the instant response of audio; when the focus detection result indicates that the target application does not have focus, a focus request is actively sent, and after receiving the focus request result, the target application is controlled to perform audio operations and update the interface state, which effectively solves the focus competition problem in the concurrent scenario of multiple audio applications. By actively detecting and requesting focus, the target application can obtain audio resources before performing playback operations, avoiding problems such as playback failure, audio being preempted, or sound mixing with other applications due to lack of focus.

[0029] (7) After sending a focus request, perform differentiated operations based on the returned focus request result. When the focus request is successful, the target application is normally controlled to perform audio operations and the interface is updated to the playback state to ensure that the user's instructions are fully executed. When the focus request fails, a pause command is actively sent to the terminal device, and the application interface of the target application is updated to the paused state. This effectively addresses the playback failure scenario caused by a high-priority audio application preempting focus. Through active pausing and state synchronization in the event of failure, problems such as audio aliasing, playback abnormalities, or inconsistencies between the interface display and the actual state caused by the target application forcibly playing without focus are avoided. At the same time, the mechanism of sending a pause command to the terminal device ensures the consistency of the state between the mobile phone and the vehicle system, preventing the state asynchrony between the two ends caused by the failure of focus contention.

[0030] (8) When executing a pause command and being in the end-waiting pause state, determine the second status information of the waiting playback state within a preset time, and perform differentiated processing based on this information. When the second status information is detected as the waiting playback state, it indicates that the system is currently in the process of processing the playback command. At this time, the status response information sent by the terminal device is directly discarded to avoid the playback process being interrupted or interfered with by the newly arrived pause command. When the second status information is detected as the end-waiting playback state, the audio focus of the target application is released normally and the interface is updated to the pause state. This effectively solves the problem of playback and pause command conflicts that may occur in continuous and rapid switching operations. By judging the rationality of the pause command execution based on the playback status information, it prevents audio status jumps, playback abnormalities, or interface display errors caused by command competition. Attached Figure Description

[0031] Figure 1 A flowchart illustrating an in-vehicle music control method provided in this application embodiment. Figure 1 ; Figure 2A flowchart illustrating an in-vehicle music control method provided in this application embodiment. Figure 2 ; Figure 3 A flowchart illustrating an in-vehicle music control method provided in this application embodiment. Figure 3 ; Figure 4 This application provides a schematic diagram of the composition structure of an in-vehicle music control device according to an embodiment of the present application. Figure 5 This is a schematic diagram of the hardware entity of a vehicle provided in an embodiment of this application.

[0032] It should be noted that the terms "first" and "second" mentioned above are only used to distinguish between different options and do not represent the degree of superiority or inferiority of the options or their priority in the implementation process. Detailed Implementation

[0033] The embodiments of this application will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be understood that the preferred embodiments are only for illustrating this application and are not intended to limit the scope of protection of this application.

[0034] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. Therefore, the drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0035] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0036] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0037] In this embodiment, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, object A and / or object B can represent three situations: object A exists alone, object A and object B exist simultaneously, and object B exists alone.

[0038] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0039] First, the basic logic of Bluetooth music control is introduced in the embodiments of this application.

[0040] Bluetooth music control logic typically involves multiple layers. In native Android, the upper-layer application sends Bluetooth music control commands to the Framework layer, which then communicates with the local Bluetooth chip. Upon receiving the command, the remote device executes the corresponding operation, such as play, pause, or adjust volume. The execution result may be returned to the Bluetooth chip via Bluetooth, and then passed to the upper-layer application through the Framework layer for updating the relevant UI or performing other processing.

[0041] Currently, most in-car Bluetooth music playback systems transmit data via the standard Bluetooth protocol. However, due to the wide variety of mobile phone brands and models on the market, and the diverse range of music players available on mobile phones, the following issues may arise when interacting with the in-car system: Some mobile phones and music players, upon receiving a playback command from the in-car system, will first return to a pause state on the mobile phone, then delay for about one second before returning to playback mode. Similarly, upon receiving a pause command, they will first return to playback mode, then delay for about one second before returning to pause mode. Furthermore, some in-car systems have specific requirements: switching to Bluetooth music after playing local or online music, and resuming local or online music playback when the mobile phone pauses or disconnects Bluetooth music.

[0042] This delayed return of status may cause UI display abnormalities (for example, the user clicks to pause playback, but the UI will first show playback for 1 second before changing to pause) or audio logic confusion, thus affecting the user experience.

[0043] Based on this, embodiments of this application provide an in-vehicle music control method, the method comprising: responding to a control command of a target application, sending a control command to a terminal device; updating the target state of the target application to a waiting state corresponding to the control command based on the control command; wherein the waiting state includes a waiting to play state and a waiting to pause state; upon receiving a status response information sent by the terminal device, updating the target state from the waiting state to an end-of-wait state corresponding to the waiting state based on the status response information; and controlling the target application to perform an audio operation corresponding to the control command based on the end-of-wait state; wherein the end-of-wait state includes an end-of-play state and an end-of-pause state.

[0044] In this way, by responding to the control commands of the target application and sending them to the terminal device, and immediately updating the target application's target state to "waiting to play" or "waiting to pause" corresponding to the control command after sending the command, a corresponding target state (also known as an intermediate state) is added to the target application. This allows the vehicle system to clearly identify the current transition phase of command execution during the delay period before the terminal device returns status response information, thereby avoiding blindly updating the UI or performing subsequent audio operations due to missing status information. Upon receiving the status response information returned by the terminal device, the target state is updated from the "waiting" state to the corresponding "end waiting to play" or "end waiting to pause" state based on the status response information, and this serves as a reliable basis for controlling the target application to perform the corresponding audio operations. This complete state transition loop effectively solves the problem of abnormal display on the vehicle's interface caused by mobile phone response delay, ensuring accurate correspondence between the play / pause button state and the actual audio state. At the same time, clear waiting state indicators provide precise decision-making basis for the vehicle's audio management in multi-source switching scenarios, preventing logical confusion such as audio aliasing or playback freeze caused by state competition, and significantly improving the stability of in-vehicle Bluetooth music control and user experience.

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

[0046] It should be noted that the in-vehicle music control method provided in the embodiments of this application can be executed by the electronic control unit in the vehicle.

[0047] Figure 1 A flowchart illustrating an in-vehicle music control method provided in this application embodiment. Figure 1 ,like Figure 1 As shown, it may include S101 to S104, wherein: S101, in response to the control command of the target application, sends the control command to the terminal device.

[0048] The control commands can be used to control the target application to play or pause Bluetooth music. For example, the control commands may include, but are not limited to, play commands, pause commands, volume adjustment commands (increase or decrease volume), and music switching commands.

[0049] Here, the target application refers to any application that can play audio installed on the vehicle's central control screen; for example, the target application may include, but is not limited to, vehicle navigation applications, music playback applications, video playback applications, etc.

[0050] Here, terminal equipment refers to handheld terminal devices, which may include, but are not limited to, mobile phones, tablets, etc.

[0051] In this embodiment of the application, responding to the control command of the target application can be understood as the vehicle terminal receiving the control command sent by the target application.

[0052] It should be noted that the control commands can be generated in at least one of the following ways: when the user manually clicks the Bluetooth music play button on the vehicle's infotainment system, the target application generates the control command; when the target application actively obtains audio focus, the control command is automatically generated.

[0053] For example, a user can click the "play" button in the target application on the home screen of the vehicle's central control screen; the target application (Bluetooth music service) listens for the click event and can generate a control command. Furthermore, the vehicle's central control screen encapsulates the command and sends it to the connected mobile device through the Bluetooth protocol stack (such as the Pass Through command in the AVRCP protocol or a custom UUID channel).

[0054] In another example, a user is using the car's navigation system (with voice prompts) and wants to listen to music. They say "play Bluetooth music" through the voice assistant. At this point, the navigation app occupies the car's audio channel. The car's system interprets the user's intent through the voice assistant, thus launching the Bluetooth music app (the target app). The Bluetooth music app then requests audio focus from the car's audio management service. The audio management service pauses or lowers the navigation volume, granting audio focus to the Bluetooth music app. Further, in the callback function of successfully acquiring focus, the Bluetooth music app determines that this is an "active focus acquisition," automatically generates a control command, encapsulates the control command, and sends it to the connected mobile device.

[0055] S102, based on the control command, update the target state of the target application to the waiting state corresponding to the control command.

[0056] Here, the target state refers to a newly added intermediate state for the playback and pause states of the target application; the target state may include, but is not limited to, the waiting-to-play state (WaitingToPlay) and the waiting-to-pause state (WaitingForPause). For example, an intermediate state can be added for playback and pause respectively in the framework layer or app layer of the vehicle-mounted system.

[0057] The "waiting to play" state can represent an intermediate state where the vehicle's infotainment system has issued a playback command and is waiting for the mobile device (terminal device) to return a playback status. The waiting to play state can include, but is not limited to, the "currently waiting to play" state and the "end of waiting to play" state. The "currently waiting to play" state means that the vehicle's infotainment system has sent a playback command and is waiting for the mobile device to return a playback status. The "end of waiting to play" state means that the vehicle's infotainment system has received the playback status sent by the mobile device and can play audio normally.

[0058] For example, the waiting playback state can be represented by a Boolean value; for instance, if WaitingToPlay=false, it indicates that the waiting playback state is in progress; if WaitingToPlay=true, it indicates that the waiting playback state has ended. Of course, the waiting playback state can also be represented in other ways, for example, WaitingToPlay=0 indicates that the waiting playback state is in progress; WaitingToPlay=1 indicates that the waiting playback state has ended. This embodiment of the application does not impose any limitations on this.

[0059] The "waiting for pause" state can indicate that the vehicle's infotainment system has issued a pause command and is waiting for the mobile device to return a pause status. The waiting for pause state can include, but is not limited to, the "currently waiting for pause" state and the "end of waiting for pause" state. The "currently waiting for pause" state means that the vehicle's infotainment system has sent a pause command and is waiting for the mobile device to return a pause status. The "end of waiting for pause" state means that the vehicle's infotainment system has received the pause status sent by the mobile device and can pause the audio that is playing.

[0060] For example, the waiting pause state can also be represented by a Boolean value; for instance, if WaitingForPause=false, it indicates that the waiting pause state is in the process of waiting for a pause; if WaitingForPause=true, it indicates that the waiting pause state has ended. Of course, the waiting pause state can also be represented in other ways, for example, WaitingForPause=0 indicates that the waiting pause state is in the process of waiting for a pause; WaitingForPause=1 indicates that the waiting pause state has ended. This application embodiment does not impose any restrictions on this.

[0061] The waiting state can include the waiting to play state within the waiting to play state and the waiting to pause state within the waiting to pause state.

[0062] In some embodiments, after the target application generates a control command and sends the control command to the terminal device, the target state of the target application can be updated to a waiting state corresponding to the control command.

[0063] In other words, if the control command is a play command, after the target application generates the play command and sends it to the terminal device, the target application's waiting-to-play state can be updated to the "waiting to play" state corresponding to the play command. If the control command is a pause command, after the target application generates a pause command and sends it to the terminal device, the target application's waiting-to-pause state can be updated to the "waiting-to-pause" state corresponding to the pause command.

[0064] As an example, in an implementation of playing Bluetooth music on a car infotainment system, the user can manually click the Bluetooth music play button on the system. After sending the play command to the mobile phone, a waiting-to-play state (WaitingToPlay) can be added to the interface that sends the play command (e.g., btMusicPlay), and WaitingToPlay can be set to false, indicating that the current target application is in a waiting-to-play state. Alternatively, when the Bluetooth music actively gains focus, a play command can be sent to the mobile phone, and the WaitingToPlay state can be set to false, indicating that the current target application is in a waiting-to-play state.

[0065] As another example, for an implementation of pausing Bluetooth music on the in-vehicle infotainment system, the user can manually click the Bluetooth music pause button on the in-vehicle system. After sending the pause command to the mobile phone, a waiting-for-pause state can be added to the interface that sends the pause command (e.g., btMusicPause), and the WaitingForPause state can be set to false, indicating that the current target application is in a waiting-for-pause state. Yet another example is that when Bluetooth music actively loses focus, a pause command can be sent to the mobile phone, and the WaitingForPause state can be set to false, indicating that the current target application is in a waiting-for-pause state.

[0066] S103, upon receiving status response information sent by the terminal device, the target status is updated from the waiting state to the end-waiting state corresponding to the waiting state based on the status response information.

[0067] Here, status response information refers to the response information generated by the terminal device based on the control command after receiving the control command sent by the vehicle terminal.

[0068] For example, status response information may include, but is not limited to, playback status, pause status, etc.

[0069] In some embodiments, upon receiving status response information sent by the terminal device, the target status can be updated from the waiting state to the end-of-wait state corresponding to the waiting state.

[0070] For example, upon receiving a playback status message from the terminal device, the waiting playback status can be updated from "Waiting to Play" to "Ended Waiting to Play". For instance, the Boolean value of WaitingToPlay can be set to true, indicating that the vehicle's infotainment system has received the playback status message from the mobile device and can play audio normally.

[0071] Another example is that, upon receiving a pause status from the terminal device, the waiting-for-pause status can be updated from "waiting for pause" to "end waiting for pause". For instance, the boolean value of WaitingForPause can be set to true, indicating that the vehicle's infotainment system has received the pause status from the mobile device and can pause the audio being played.

[0072] S104, based on the end of the waiting state, control the target application to perform the audio operation corresponding to the control command.

[0073] The "End Waiting" state includes both the "End Waiting Playback" state and the "End Waiting Pause" state.

[0074] In some embodiments, after determining that the target application is in an end-waiting state, the target application can be controlled to perform audio operations corresponding to the control instructions based on the end-waiting state.

[0075] For example, when the control command is a playback command and the end-wait state is an end-wait-play state, the target application is controlled to perform normal audio playback.

[0076] As another example, when the control command is a pause command and the end-wait state is an end-wait pause state, the control target application pauses the audio that is being played.

[0077] In this embodiment, by responding to the control command of the target application and sending it to the terminal device, and immediately updating the target application's target state to "waiting to play" or "waiting to pause" corresponding to the control command after sending the command, a corresponding target state (also known as an intermediate state) is added to the target application. This allows the vehicle system to clearly identify the current transition phase of command execution during the delay period before the terminal device returns status response information, thereby avoiding blindly updating the UI or performing subsequent audio operations due to missing status information. Upon receiving the status response information returned by the terminal device, the target state is updated from the "waiting" state to the corresponding "end waiting to play" or "end waiting to pause" state based on the status response information, and this serves as a reliable basis for controlling the target application to perform corresponding audio operations. This complete state transition loop effectively solves the problem of abnormal display on the vehicle's interface caused by mobile phone response delay, ensuring accurate correspondence between the play / pause button state and the actual audio state. At the same time, clear waiting state indicators provide precise decision-making basis for the vehicle's audio management in multi-source switching scenarios, preventing logical confusion such as audio aliasing or playback freeze caused by state competition, and significantly improving the stability of in-vehicle Bluetooth music control and user experience.

[0078] In some embodiments, the above-mentioned S103 "updating the target state from the waiting state to the end waiting state corresponding to the waiting state based on the state response information" may further include the following steps S1031 and S1032: S1031, determine whether to respond to the status response information based on the matching relationship between the status response information and the waiting status.

[0079] In this embodiment of the application, after receiving the status response information sent by the terminal device, the matching relationship between the status response information and the waiting state can be determined, and the response to the status response information can be determined based on the matching relationship.

[0080] In some embodiments, the status response information may include, but is not limited to, playback status information and pause status information; determining whether to respond to the status response information based on the matching relationship between the status response information and the waiting status may further include the following steps S201 and S202: S201, if the status response information matches the waiting status, determine the response status response information.

[0081] The matching of status response information with waiting status can include: status response information being playback status information and waiting status being waiting to play, or status response information being paused status information and waiting status being waiting to pause.

[0082] As an example, when playing Bluetooth music on the car's infotainment system, after setting WaitingToPlay to false (i.e., the waiting state is "waiting to play"), the system determines the status response information sent by the terminal device. If the status response information is the playback status information, which is the onBluetoothMusicStart callback on the mobile phone, then the car's infotainment system will respond to the status response information.

[0083] As another example, when Bluetooth music is paused on the vehicle's infotainment system, after setting WaitingForPause to false (meaning the waiting state is now waiting for pause), the status response information sent by the terminal device can be determined. If the status response information is a pause status information, which is the mobile phone's callback onBluetoothMusicStop, then the vehicle's infotainment system will respond to this status response information.

[0084] S202, if the status response information does not match the waiting status, determine to discard the status response information.

[0085] The mismatch between the status response information and the waiting status can include: the status response information is playback status information and the waiting status is waiting for pause, or the status response information is pause status information and the waiting status is waiting for playback.

[0086] As an example, when playing Bluetooth music on the car's infotainment system, after setting WaitingToPlay to false (i.e., the waiting state is "waiting to play"), the system determines the status response information sent by the terminal device. If the status response information is a paused status information, i.e., the mobile phone calls back onBluetoothMusicStop, the car's infotainment system decides to discard this status response information (onBluetoothMusicStop).

[0087] As another example, when Bluetooth music is paused on the vehicle's infotainment system, after setting WaitingForPause to false (i.e., the waiting state is the waiting pause state), the status response information sent by the terminal device can be determined. If the status response information is the playback status information, which is the onBluetoothMusicStart callback on the mobile phone, the vehicle's infotainment system will discard the status response information (onBluetoothMusicStart).

[0088] In this embodiment, after receiving the status response information returned by the terminal device, a matching judgment can be made: when the status response information matches the current waiting state (waiting for playback or waiting for pause), the information is responded to and the target state is updated; when the two do not match, the status response information is discarded directly. By promptly discarding mismatched status responses, problems such as interface display errors and playback status jumps caused by the vehicle's infotainment system performing subsequent audio operations based on erroneous information are avoided. This ensures the orderliness and accuracy of target state updates, significantly improving the stability of in-vehicle Bluetooth music control and the consistency of user experience.

[0089] S1032, if the response status information is determined, the target status is updated from the waiting state to the end-waiting state corresponding to the waiting state.

[0090] It is understandable that the end-wait state can include the end-wait playback state and the end-wait pause state.

[0091] In some embodiments, if the status response information matches the waiting status, after determining the response status response information, the target status can be updated from the waiting status to the end-of-wait status.

[0092] For example, if the waiting state is a waiting to play state, then the corresponding end-waiting state is an end-waiting-to-play state, meaning the car's infotainment system can play Bluetooth music. As another example, if the waiting state is a waiting to pause state, then the corresponding end-waiting state is an end-waiting-to-pause state, meaning the car's infotainment system can pause Bluetooth music.

[0093] As an example, when playing Bluetooth music on the car's infotainment system, after setting WaitingToPlay to false (i.e., changing the waiting state to the waiting playback state), if the system determines that the status response information sent by the terminal device is the playback status information, that is, the mobile phone callback onBluetoothMusicStart, then the car's infotainment system will respond to this status response information. Furthermore, WaitingToPlay can be set to true, which updates the target state to the end of the waiting playback state corresponding to the waiting playback state.

[0094] As an example, when Bluetooth music is paused on the vehicle's infotainment system, after setting WaitingForPause to false (meaning the waiting state is changed to the waiting pause state), if the terminal device sends a status response message indicating a pause state, i.e., the mobile phone callbacks onBluetoothMusicStop, the vehicle's infotainment system will respond to this status response message. Furthermore, WaitingForPause can be set to true, which updates the target state to the end-of-wait-pause state corresponding to the waiting pause state.

[0095] In this embodiment, after receiving the status response information, the target status is not updated unconditionally. Instead, the information is first verified against the current waiting status (waiting for playback or waiting for pause). Only when a match is confirmed is the target status updated to the corresponding end-waiting status. This effectively filters out mismatched response information caused by terminal device abnormalities, communication delays, or status errors, preventing the vehicle-mounted system from performing subsequent audio operations based on incorrect feedback. This prevents abnormal phenomena such as playback status jumps and interface display misalignments.

[0096] In some embodiments, after S102, the method may further include the following steps S301 and S302: S301, after updating the target state of the target application to the waiting state corresponding to the control command, start the timer; S302, if no status response information matching the waiting state is received after the timer expires, then according to the control command, the target state is updated from the waiting state to the end waiting state corresponding to the waiting state, and the target application is controlled to perform the audio operation corresponding to the control command.

[0097] In one possible embodiment, after the target state is updated to a waiting state based on the control command, a timer can be started. If the timer's duration exceeds a preset duration and no status response information is received from the terminal device, the target state can be automatically changed from a waiting state to an ended waiting state, and the target application can be controlled to perform the corresponding audio operation.

[0098] As an example, if the control command is a playback command, after the target application generates the playback command and sends it to the terminal device, the target application's waiting-to-play state can be updated to the "Waiting to Play" state corresponding to the playback command. Furthermore, a timer can be started. If the playback status information sent by the terminal device is not received after the timer's duration exceeds 2 seconds, the vehicle's infotainment system can forcibly update the target state from "Waiting to Play" to "End Waiting to Play," i.e., update "WaitingToPlay" to true, and control the target application to perform normal audio playback.

[0099] As another example, if the control command is a pause command, after the target application generates the pause command and sends it to the terminal device, the target application's waiting-for-pause state can be updated to the waiting-for-pause state corresponding to the pause command. Furthermore, a timer can be started. If the pause state information sent by the terminal device is not received after the timer's duration exceeds 2 seconds, the vehicle's infotainment system can forcibly update the target state from the waiting-for-pause state to the ended-for-pause state, i.e., update WaitingForPause to true, and control the target application to pause the audio.

[0100] In another possible embodiment, after updating the target state to a waiting state based on the control command, a handler mechanism can be added to the interface (btMusicPlay) that issues the control command (play command or pause command) to poll for a preset duration (e.g., 2 seconds) and wait for the mobile device to call back the status response information (play status information or pause status information). If no status response information is received from the terminal device after the preset duration, the target state can be changed from the waiting state to the end of waiting state, and the target application can be controlled to perform the corresponding audio operation.

[0101] In this embodiment, after updating the target state of the target application to the waiting state corresponding to the control command, a timer can be started. When the timer expires and no state response information matching the current waiting state is received, the system no longer passively waits for feedback from the terminal device, but actively updates the target state from the waiting state to the corresponding end-waiting state according to the original control command, and controls the target application to perform the corresponding audio operation. This can prevent the vehicle system from falling into a state of logical stagnation or interface freeze due to indefinite waiting.

[0102] The following embodiments of this application describe the specific implementation method of the control target application performing audio operations corresponding to the control command when the control command is a playback command.

[0103] In some embodiments, Figure 2A flowchart illustrating an in-vehicle music control method provided in this application embodiment. Figure 2 The aforementioned S104, "Based on the end of the waiting state, the control target application executes the audio operation corresponding to the control command," may further include steps S1041 to S1044: S1041, when the control command is a playback command and the waiting playback state is the end waiting playback state, determine the first state information of the waiting pause state within a preset time.

[0104] The first state information is used to characterize the waiting and paused state of the target application; for example, the first state information may include, but is not limited to, the waiting and paused state and the end of the waiting and paused state.

[0105] It is understandable that the preset duration refers to a period of time after the waiting playback state ends. The preset duration can be adaptively set according to the type of the target application.

[0106] For example, when the control command is a playback command and the waiting playback state is the end waiting playback state, the first state information of the waiting pause state can be determined within 2 seconds.

[0107] S1042, if the first status information is in a waiting pause state, determine to discard the status response information sent by the terminal device.

[0108] The first status information is "Waiting for Pause", which can be understood as "WaitingForPause=false", meaning that the vehicle's system has sent a pause command and is waiting for the mobile phone to return the pause status.

[0109] In some embodiments, when the control command is a playback command and the waiting playback state is the end of waiting playback state, the first state information is determined to be the waiting pause state, that is, the vehicle terminal has sent a pause command and is waiting for the mobile terminal to return the pause state. At this time, since the waiting playback state is the end of waiting playback state, that is, the vehicle terminal has received the playback state sent by the mobile terminal, the audio can be played normally. It can be seen that the waiting playback state and the waiting pause state conflict, that is, the vehicle terminal determines to discard the state response information sent by the terminal device.

[0110] For example, when the control command is a playback command and the waiting playback state is the end of the waiting playback state, i.e., WaitingToPlay=true, it is determined that WaitingForPause=false, that is, the first state information is the waiting pause state. Therefore, the vehicle terminal can ignore the callback of onBluetoothMusicStart on the mobile phone. In other words, the vehicle terminal can discard the playback state information sent by the terminal device and not play Bluetooth music.

[0111] S1043, if the first state information is the end of the waiting pause state, the audio focus of the target application is detected and the focus detection result is obtained.

[0112] S1044, based on the focus detection result, control the target application to perform the audio operation corresponding to the control command, and update the audio playback status corresponding to the application interface of the target application.

[0113] The first status information is the end of the waiting pause state, which can be understood as WaitingForPause=true, meaning that the vehicle's system has received the pause status sent by the mobile phone and can pause the audio that is being played.

[0114] It is understood that the focus detection result can be used to characterize whether the target application has audio focus; for example, the focus detection result can indicate whether the target application has audio focus or not.

[0115] It is also understandable that the audio playback status corresponding to the target application's interface indicates the UI display status of the target application; the audio playback status corresponding to the application interface may include, but is not limited to, a playing status and a paused status.

[0116] In some embodiments, when the control instruction is a playback instruction and the waiting playback state is the end of waiting playback state, after further determining that the first state information is the end of waiting pause state, the target application can be subjected to audio focus detection, and based on different focus detection results, the target application can be controlled to perform different audio operations; furthermore, the audio playback state corresponding to the application interface of the target application can also be updated based on different focus detection results.

[0117] In this embodiment, when executing a playback command and being in a state of waiting for playback to end, the system first determines the first state information of the waiting pause state within a preset time period and performs differentiated processing based on the first state information. When the first state information is detected as a waiting pause state, it indicates that the system is currently processing a pause command. At this time, the state response information sent by the terminal device is directly discarded, avoiding interference from the newly arrived playback command to the ongoing pause process. When the first state information is detected as a waiting pause state to end, the audio focus of the target application is further detected. Based on the focus detection result, the audio operation is controlled and the playback state of the application interface is updated. This effectively solves the state conflict problem that may occur in continuous rapid operation or command crossover scenarios. At the same time, combined with the secondary confirmation mechanism of audio focus detection, playback failure or audio aliasing caused by focus contention is avoided, significantly improving the response accuracy of in-vehicle Bluetooth music control in complex operation scenarios and the smoothness of user experience.

[0118] It is understandable that different focus detection results for the target application can lead to different audio operations and updates to different application interfaces.

[0119] In some embodiments, the above-mentioned S1044 "based on the focus detection result, controlling the target application to perform the audio operation corresponding to the control command, and updating the audio playback status corresponding to the application interface of the target application" may further include the following steps S401 to S403: S401, if the focus detection result indicates that the target application has focus, control the target application to perform the audio operation corresponding to the control command, and update the audio playback status of the target application's application interface to the playback status.

[0120] For example, when the control command is a playback command and the waiting playback state is the end of waiting playback state, after further determining that the first state information is the end of waiting pause state, the target application is tested for audio focus. If it is determined that the target application has audio focus, the target application can be controlled to play Bluetooth music directly, and the audio playback state of the application interface can be updated to the playback state.

[0121] In other words, if the control command is a playback command and WaitingToPlay is true, and WaitingForPause is true at this time, it first checks whether the target application currently has focus. If it does have focus, the UI display state can be directly updated to the playback state.

[0122] S402, if the focus detection result indicates that the target application does not have a focus, send a focus request; S403, in response to receiving the focus request result corresponding to the focus request, controls the target application to perform the audio operation corresponding to the control command, and updates the audio playback status corresponding to the application interface of the target application.

[0123] The "application for focus" refers to the request sent by the vehicle's infotainment system to the system's audio focus manager. In other words, when the vehicle's infotainment system detects that the target application does not currently have audio focus (i.e., it is not in playback mode or the focus is occupied by other applications), it can apply for audio focus from the system. Only after obtaining focus can subsequent audio playback operations be performed.

[0124] Understandably, after the audio focus manager receives a focus request, it can determine whether audio focus can be allocated to the target application, obtain the focus request result, and send the focus request result to the vehicle's infotainment system.

[0125] The focus application result indicates whether the vehicle-mounted system has successfully applied for the corresponding audio focus for the target application. For example, the focus application result can include "focus application successful" and "focus application failed".

[0126] In some embodiments, if it is determined that the target application does not have audio focus, a focus request can be sent to the audio focus manager. Furthermore, the vehicle-mounted system can receive the focus request result sent by the audio focus manager and control the target application to perform different audio operations based on different focus request results. Furthermore, the audio playback status corresponding to the application interface of the target application can also be updated based on different focus request results.

[0127] In this embodiment, by detecting the audio focus of the target application and performing differentiated operations based on the detection results, when the focus detection result indicates that the target application has focus, the target application is directly controlled to execute the audio operation corresponding to the playback command and update the interface playback state, realizing rapid reuse of focus and instant audio response. When the focus detection result indicates that the target application does not have focus, a focus request is actively sent, and upon receiving the focus request result, the target application is controlled to execute the audio operation and update the interface state. This effectively solves the focus contention problem in concurrent scenarios of multiple audio applications. Through the mechanism of actively detecting and requesting focus, it is ensured that the target application has obtained the necessary system audio resources before executing the playback operation, avoiding problems such as playback failure, audio preemption, or sound mixing with other applications due to lack of focus. At the same time, the differentiated processing based on focus state optimizes the response efficiency in normal scenarios and ensures the success rate of operation in complex scenarios, significantly improving the stable performance of in-vehicle Bluetooth music control in multi-task audio environments.

[0128] It is understandable that different audio operations and different application interface updates can be performed for different application focus results.

[0129] In some embodiments, the above-mentioned S403 "in response to receiving the focus request result corresponding to the focus request, controlling the target application to perform the audio operation corresponding to the control instruction, and updating the audio playback status corresponding to the application interface of the target application" may further include steps S4031 and S4032: S4031, if the application focus result indicates that the application focus was successfully applied for, control the target application to perform the audio operation corresponding to the control command, and update the audio playback status of the application interface of the target application to the playback status.

[0130] S4032, if the focus application result indicates that the focus application has failed, a pause command is sent to the terminal device, and the audio playback status of the target application's application interface is updated to paused.

[0131] The result of applying for focus indicates that the application was successful, which can be understood as the system has granted the audio focus to the current application, allowing it to play audio. The result of applying for focus indicates that the application failed, which can be understood as the system did not grant focus because the focus was occupied by a higher priority audio (such as a call or navigation), and the current application is temporarily unable to play audio.

[0132] In some embodiments, if it is determined that the target application does not have audio focus, a focus request can be sent to the audio focus manager. Furthermore, the vehicle's infotainment system can receive the focus request result sent by the audio focus manager. If the focus request result is successful, the target application can be controlled to directly play Bluetooth music, and the audio playback status of the application interface can be updated to playback status.

[0133] In some embodiments, if it is determined that the target application does not have audio focus, a focus request can be sent to the audio focus manager. Furthermore, the vehicle-mounted device can receive the focus request result sent by the audio focus manager. If the focus request result is that the focus request failed, the vehicle-mounted device can send a pause command to the mobile device and update the audio playback status of the application interface to a paused state.

[0134] In this embodiment, after sending a focus request, differentiated operations are performed based on the returned focus request result. When the focus request is successful, the target application is controlled to perform audio operations normally and the interface is updated to playback status, ensuring that user commands are fully executed. When the focus request fails, a pause command is proactively sent to the terminal device, and the application interface of the target application is updated to a paused state. This effectively addresses playback failure scenarios caused by high-priority audio applications preempting focus. Through proactive pausing and state synchronization in failure cases, issues such as audio aliasing, playback abnormalities, or discrepancies between the displayed interface and the actual state caused by the target application forcibly playing without focus are avoided. Simultaneously, the mechanism of sending a pause command to the terminal device ensures consistency between the mobile and in-vehicle systems, preventing asynchrony between the two ends due to focus contention failure. By establishing a complete closed loop for handling successful and failed focus requests, the fault tolerance and reliability of in-vehicle Bluetooth music control in complex multi-application audio environments are significantly improved, providing users with a more stable and reliable in-vehicle music control experience.

[0135] The following embodiments of this application describe the specific implementation method of the control target application performing the audio operation corresponding to the control command when the control command is a pause command.

[0136] In some embodiments, the above-mentioned S104 "based on the end of the waiting state, control the target application to perform the audio operation corresponding to the control command" may further include steps S501 to S503: S501, when the control command is a pause command and the waiting pause state is the end of the waiting pause state, determine the second state information of the waiting playback state within a preset time.

[0137] The second state information is used to characterize the state of the target application waiting to play; for example, the second state information may include, but is not limited to, the state of waiting to play and the state of ending waiting to play.

[0138] S502, if the second status information is "waiting to play", determine to discard the status response information sent by the terminal device.

[0139] The second status information is "Waiting to play", which can be understood as "WaitingToPlay=false", meaning that the vehicle's infotainment system has sent a playback command and is waiting for the mobile phone to return the playback status.

[0140] In some embodiments, when the control command is a pause command and the waiting-to-pause state is the end of the waiting-to-pause state, the second state information is determined to be the waiting-to-play state, that is, the vehicle terminal has sent a playback command and is waiting for the mobile terminal to return the playback state. At this time, since the waiting-to-pause state is the end of the waiting-to-pause state, that is, the vehicle terminal has received the pause state sent by the mobile terminal, the audio being played can be paused. It can be seen that the waiting-to-play state and the waiting-to-pause state conflict, that is, the vehicle terminal determines to discard the state response information sent by the terminal device.

[0141] For example, when the control command is a pause command and the waiting pause state is the end of the waiting pause state, i.e., WaitingForPause=true, WaitingToPlay=false is determined, that is, the second state information is the waiting playback state. Therefore, the vehicle terminal can ignore the callback of onBluetoothMusicStop on the mobile phone, that is, the vehicle terminal can discard the pause state information sent by the terminal device and not pause the Bluetooth music.

[0142] S503, if the second state information is "end waiting for playback", release the audio focus of the target application and update the audio playback state of the target application's interface to "pause".

[0143] The second status information is the end of the waiting playback status, which can be understood as WaitingToPlay=true, meaning that the vehicle's system has received the playback status sent by the mobile phone and can play audio normally.

[0144] In some embodiments, when the control command is a pause command and the waiting pause state is the end of waiting pause state, the second state information is determined to be the end of waiting playback state. At this time, the vehicle terminal can respond to the state response information sent by the terminal device, that is, the vehicle terminal can respond to the callback of onBluetoothMusicStop on the mobile phone, that is, release the audio focus of the target application and update the audio playback state of the application interface of the target application to the pause state.

[0145] In this embodiment, when a pause command is executed and the system is in a state of waiting for playback to end, a second state information for the waiting playback state within a preset time period is determined, and differentiated processing is performed based on this information. When the second state information is detected as a state of waiting for playback, it indicates that the system is currently processing a playback command. At this time, the state response information sent by the terminal device is directly discarded, avoiding interruption or interference of the currently executing playback process by a newly arrived pause command. When the second state information is detected as a state of waiting for playback to end, the audio focus of the target application is released normally and the interface is updated to a pause state. This effectively solves the problem of playback and pause command conflicts that may occur in continuous and rapid switching operations or command crossover scenarios. By judging the rationality of the pause command execution based on the playback state information, audio state jumps, playback abnormalities, or interface display errors caused by command competition are prevented.

[0146] The following describes the application of the in-vehicle music control method provided in the embodiments of this application in a real-world scenario.

[0147] This application provides a method for controlling in-vehicle Bluetooth music by adding a control algorithm at the framework or app layer to selectively discard or respond to mobile phone status commands, thereby solving problems such as abnormal UI display or audio corruption. Specific methods include: 1. Introduce an intermediate state mechanism. At the framework or app level, introduce two intermediate states, "WaitingToPlay" and "WaitingForPause," for playback and pause operations, respectively. These two states are used to indicate that the player is in a transitional phase, waiting for a state transition, after receiving a command.

[0148] 2. Optimized state transition logic. When Bluetooth music is paused and actively gains focus and receives a play command, the phone first returns to the paused state, then returns to the play state after approximately 1 second. During this process, it ensures that focus is not released within 2 seconds of gaining focus to maintain state consistency.

[0149] When Bluetooth music is playing and a higher-priority audio needs to be played, causing the Bluetooth music to lose focus and triggering a pause command, the phone will continuously revert to the playback state for nearly 2 seconds before reverting to the pause state. During this process, it also ensures that focus is not released within 2 seconds of losing focus to avoid state confusion.

[0150] 3. Enhanced User Experience. By introducing intermediate states and optimizing state transition logic, this invention effectively solves the problems of UI display anomalies and audio logic confusion caused by delayed state return, thereby significantly improving the user experience. Whether playing or pausing, users receive smoother and more consistent operational feedback.

[0151] In some embodiments, Figure 3 A flowchart illustrating an in-vehicle music control method provided in this application embodiment. Figure 3 ,like Figure 3 As shown, it may include S601 to S606.

[0152] S601, in response to the control command of the target application, sends the control command to the terminal device.

[0153] Among them, the control commands are used to control the target application to perform playback or pause operations; S602, based on the control command, updates the target state of the target application to the waiting state corresponding to the control command.

[0154] The waiting state includes the waiting to play state and the waiting to pause state; S603, upon receiving status response information sent by the terminal device and if the status response information matches the waiting status, determine the response status response information; S604, if the response status response information is determined, the target status is updated from the waiting status to the end waiting status corresponding to the waiting status; S605, if the status response information does not match the waiting status, determine to discard the status response information; S606, based on the end of the waiting state, controls the target application to perform the audio operation corresponding to the control command.

[0155] The "End Waiting" state includes both the "End Waiting Playback" state and the "End Waiting Pause" state.

[0156] The following embodiments of this application describe the detailed technical solution when the control command is a playback command in the above method: 1. Add an intermediate state mechanism to the framework or app, that is, add an intermediate state for playback and pause respectively in the framework or app, namely WaitingToPlay (the waiting playback state in the above embodiment) and WaitingForPause (the waiting pause state in the above embodiment).

[0157] Among them, WaitingToPlay indicates an intermediate state where the vehicle's infotainment system has issued a play order and is waiting for the mobile device to return the play status; WaitingForPause indicates an intermediate state where the vehicle's infotainment system has issued a pause order and is waiting for the mobile device to return the pause status.

[0158] 2. Car infotainment system playing Bluetooth music: Scenario 1: When the user manually clicks the Bluetooth music play button on the car infotainment system, a play command needs to be sent to the mobile phone. At this time, a WaitingToPlay state should be added to the interface for sending the play command (btMusicPlay) and set to false. Scenario 2: When the Bluetooth music actively gains focus, a play command needs to be sent to the mobile phone. At this time, the WaitingToPlay state should be set to false.

[0159] 3. Add a handler mechanism to the interface that issues the playback command (btMusicPlay) and poll for 2 seconds to wait for the mobile client to call back the playback status; 4. If the mobile device does not return to playback status within 2 seconds, actively set the WaitingToPlay status to true; 5. Set WaitingToPlay to true in onBluetoothMusicStart (the callback when playback starts on the mobile device); 6. If WaitingForPause is false at this time, the onBluetoothMusicStart callback on the mobile device will be ignored; 7. If WaitingForPause is true at this time, first check if there is focus. If there is focus, directly update the UI display status to playback status. 8. If WaitingForPause is true at this time, first check if there is focus. If there is no focus, first apply for focus. After applying for focus, update the UI display status to playback status. 9. If WaitingForPause is true at this time, first check if there is focus. If there is no focus and no focus has been acquired, send a pause command to the mobile device and update the UI status to pause. 10. During the period (that is, when WaitingToPlay=false, while waiting for playback confirmation), if the mobile device calls back onBluetoothMusicStop (the callback for pausing on the mobile device), then discard the callback instruction.

[0160] The following embodiments of this application describe the detailed technical solution for the above method when the control command is a pause command: 1. Pausing Bluetooth Music on the Car System: Scenario 1: When the user manually clicks the pause button on the car system, a pause command needs to be sent to the mobile phone. In this case, a WaitingForPause state should be added to the interface for sending the pause command (btMusicPause) and set to false. Scenario 2: When the Bluetooth music actively loses focus, a pause command needs to be sent to the mobile phone. In this case, the WaitingForPause state should be set to false. 2. Add a handler mechanism to the interface that issues the pause command (btMusicPause) and poll for 2 seconds to wait for the mobile client to call back the pause status; 3. If the mobile device does not send a pause status notification to the vehicle system within 2 seconds, actively set the WaitingForPause status to true; 4. Set WaitingForPause to true in onBluetoothMusicStop (callback when music is paused on the mobile device); 5. If WaitingToPlay is false at this time, ignore the onBluetoothMusicStop callback returned by the mobile device; 6. If WaitingToPlay is true at this time, then respond to the onBluetoothMusicStop callback returned by the mobile device; 7. Bluetooth music brings you into focus; 8. Update the UI to show a paused state; 9. If the mobile device calls back onBluetoothMusicStart (the callback for playback on the mobile device) during this period, the callback instruction will be discarded.

[0161] The technical solution described in this application achieves at least the following beneficial effects: This application adds a control algorithm at the framework or app layer to selectively discard or respond to mobile device status commands. Because sending commands from the vehicle's infotainment system to the mobile device is a time-consuming operation, involving Bluetooth services and the Bluetooth protocol stack, and is affected by the current environmental signal, there is a certain delay in both sending commands from the vehicle's infotainment system to the mobile device and the mobile device's information callback. Through the aforementioned control algorithm, most UI display and audio logic anomalies caused by untimely status responses from mobile devices and mobile media players can be resolved.

[0162] Based on the above embodiments, this application also provides an in-vehicle music control device. Figure 4 This application provides a schematic diagram of the composition of an in-vehicle music control device, as shown in the embodiments below. Figure 4 As shown, the in-vehicle music control device 400 includes a sending unit 401, a first updating unit 402, a second updating unit 403, and a control unit 404, wherein: The sending unit 401 is used to send control commands to the terminal device in response to control commands from the target application; wherein the control commands are used to control the playback or pause of the target application; The first update unit 402 is used to update the target state of the target application to a waiting state corresponding to the control command based on the control command; wherein the waiting state includes a waiting to play state and a waiting to pause state; The second update unit 403 is used to update the target state from the waiting state to the end waiting state corresponding to the waiting state based on the status response information sent by the terminal device when receiving the status response information. The control unit 404 is used to control the target application to perform audio operations corresponding to the control command based on the end-wait state; wherein the end-wait state includes the end-wait playback state and the end-wait pause state.

[0163] In some embodiments of this application, the second updating unit 403 is further configured to determine whether to respond to the status response information based on the matching relationship between the status response information and the waiting state; if it is determined that the status response information should be responded to, the target state is updated from the waiting state to the end waiting state corresponding to the waiting state.

[0164] In some embodiments of this application, the status response information includes playback status information and pause status information. The second update unit 403 is further configured to determine response status response information when the status response information matches the waiting status; and to determine discard status response information when the status response information does not match the waiting status. In some embodiments of this application, the in-vehicle music control device 400 further includes a startup unit and a third update unit; wherein: the startup unit is used to start a timer after updating the target state of the target application to a waiting state corresponding to the control command; the third update unit is used to update the target state from a waiting state to an end waiting state corresponding to the waiting state according to the control command if no state response information matching the waiting state is received after the timer expires, and control the target application to perform audio operations corresponding to the control command.

[0165] In some embodiments of this application, the control command includes a playback command; the target state includes a waiting pause state and a waiting playback state; the control unit 404 is further configured to, when the control command is a playback command and the waiting playback state is an ended waiting playback state, determine first state information of the waiting pause state within a preset time period; the first state information includes a waiting pause state and an ended waiting pause state; when the first state information is a waiting pause state, determine to discard the state response information sent by the terminal device; when the first state information is an ended waiting pause state, detect the audio focus of the target application to obtain a focus detection result; based on the focus detection result, control the target application to perform the audio operation corresponding to the control command, and update the audio playback state corresponding to the application interface of the target application.

[0166] In some embodiments of this application, the control unit 404 is further configured to: control the target application to perform an audio operation corresponding to the control command when the focus detection result indicates that the target application has focus, and update the audio playback state of the target application's application interface to a playback state; send a focus request when the focus detection result indicates that the target application does not have focus; and, in response to receiving the focus request result corresponding to the focus request, control the target application to perform an audio operation corresponding to the control command, and update the audio playback state of the target application's application interface.

[0167] In some embodiments of this application, the control unit 404 is further configured to, when the focus application result indicates that the focus application was successful, control the target application to perform the audio operation corresponding to the control command and update the audio playback status of the target application's application interface to a playback status; and when the focus application result indicates that the focus application failed, send a pause command to the terminal device and update the audio playback status of the target application's application interface to a paused status.

[0168] In some embodiments of this application, the control command includes a pause command; the target state also includes a waiting playback state and a waiting pause state; the control unit 404 is further configured to determine second state information of the waiting playback state within a preset duration when the control command is a pause command and the waiting pause state is an ended waiting pause state; the second state information includes a currently waiting playback state and an ended waiting playback state; when the second state information is a currently waiting playback state, determine to discard the state response information sent by the terminal device; when the second state information is an ended waiting playback state, release the audio focus of the target application and update the audio playback state of the target application's application interface to a pause state.

[0169] It should be noted that, in the embodiments of this application, if the above methods are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to related technologies, can be embodied in the form of software products. These software products are stored in a storage medium and include several instructions to cause an electronic device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory, magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware and software combination.

[0170] This application also provides a vehicle including a memory and a processor, the memory storing a computer program that can run on the processor, and the processor executing the computer program to implement the above-described method.

[0171] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method. The computer-readable storage medium can be transient or non-transient.

[0172] This application also provides a computer program product, including a computer program or instructions, which, when executed by a processor, implement some or all of the steps in the above-described method. This computer program product can be implemented specifically through hardware, software, or a combination thereof.

[0173] In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0174] It should be noted that, Figure 5 This is a schematic diagram of the hardware entity of a vehicle provided in an embodiment of this application, such as... Figure 5 As shown, the hardware entity of the vehicle 500 includes: a processor 501, a communication interface 502, and a memory 503, wherein: The processor 501 typically controls the overall operation of the vehicle 500.

[0175] Communication interface 502 enables vehicle 500 to communicate with other terminals or servers via a network.

[0176] The memory 503 is configured to store instructions and applications executable by the processor 501, and can also cache data to be processed or already processed by the processor 501 and various modules in the vehicle 500 (e.g., image data, audio data, voice communication data, and video communication data), and can be implemented using flash memory or RAM. Data can be transferred between the processor 501, the communication interface 502, and the memory 503 via the bus 504.

[0177] It should be noted that the descriptions of the storage medium and device embodiments above are similar to those of the method embodiments above, and have similar beneficial effects. For technical details not disclosed in the storage medium and device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0178] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above steps / processes do not imply a sequential order of execution; the execution order of each step / 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. The sequence numbers of the above embodiments of this application are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0179] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0180] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components may be combined, or integrated into another system, or some features may be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed may be through some interfaces, and the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0181] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0182] In addition, each functional unit in the various embodiments of this application can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0183] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, read-only memory, magnetic disks, or optical disks.

[0184] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence or the part that contributes to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROMs, magnetic disks, or optical disks.

[0185] The above are merely embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A method for controlling in-vehicle music, characterized in that, The method includes: In response to a control command from a target application, the control command is sent to a terminal device; wherein the control command is used to control the target application to perform a playback operation or a pause operation; Based on the control command, the target state of the target application is updated to a waiting state corresponding to the control command; wherein, the waiting state includes a waiting to play state and a waiting to pause state; Upon receiving status response information sent by the terminal device, the target status is updated from the waiting status to the end-waiting status corresponding to the waiting status based on the status response information. Based on the end-wait state, the target application is controlled to perform audio operations corresponding to the control command; wherein, the end-wait state includes an end-wait playback state and an end-wait pause state.

2. The method according to claim 1, characterized in that, The step of updating the target state from the waiting state to the ending waiting state corresponding to the waiting state based on the state response information includes: Based on the matching relationship between the status response information and the waiting state, determine whether to respond to the status response information; If the status response information is determined, the target status is updated from the waiting status to the end-of-wait status corresponding to the waiting status.

3. The method according to claim 2, characterized in that, The status response information includes playback status information and pause status information; determining whether to respond to the status response information based on the matching relationship between the status response information and the waiting status includes: If the status response information matches the waiting status, determine to respond to the status response information; If the status response information does not match the waiting status, the status response information is discarded.

4. The method according to claim 1, characterized in that, The method further includes: After updating the target state of the target application to the waiting state corresponding to the control command, start the timer; If no status response information matching the waiting state is received after the timer expires, the target state is updated from the waiting state to the end-waiting state corresponding to the waiting state according to the control instruction, and the target application is controlled to perform the audio operation corresponding to the control instruction.

5. The method according to any one of claims 1 to 4, characterized in that, The control commands include playback commands; the target states include a pause waiting state and a playback waiting state. Based on the end of the waiting state, control the target application to perform the audio operation corresponding to the control command, including: When the control command is the playback command and the waiting playback state is the ended waiting playback state, a first state information of the waiting pause state within a preset time period is determined; the first state information includes the waiting pause state and the ended waiting pause state; If the first status information is in the "waiting pause" state, it is determined to discard the status response information sent by the terminal device; When the first state information is the "end waiting paused state", the audio focus of the target application is detected to obtain the focus detection result; Based on the focus detection result, the target application is controlled to perform the audio operation corresponding to the control command, and the audio playback status corresponding to the application interface of the target application is updated.

6. The method according to claim 5, characterized in that, The step of controlling the target application to perform audio operations corresponding to the control command based on the focus detection result, and updating the audio playback status corresponding to the application interface of the target application, includes: If the focus detection result indicates that the target application has focus, control the target application to perform the audio operation corresponding to the control command, and update the audio playback status of the target application's application interface to the playback status; If the focus detection result indicates that the target application does not have focus, a focus request is sent. In response to receiving the focus request result, the system controls the target application to perform the audio operation corresponding to the control command and updates the audio playback status of the target application's interface.

7. The method according to claim 6, characterized in that, The step of responding to receiving the focus request result corresponding to the focus request, controlling the target application to perform the audio operation corresponding to the control command, and updating the audio playback status corresponding to the application interface of the target application, includes: If the focus application result indicates that the focus application was successful, the target application is controlled to perform the audio operation corresponding to the control command, and the audio playback status of the target application's application interface is updated to playback status. If the focus request result indicates that the focus request has failed, a pause command is sent to the terminal device, and the audio playback status of the target application's interface is updated to paused.

8. The method according to any one of claims 1 to 4, characterized in that, The control command includes a pause command; the target state further includes a waiting playback state and a waiting pause state; based on the end of the waiting state, the target application is controlled to perform an audio operation corresponding to the control command, including: When the control command is the pause command and the waiting pause state is the end of the waiting pause state, a second state information of the waiting playback state within a preset time period is determined; the second state information includes the waiting playback state and the end of the waiting playback state. If the second status information is the state of waiting for playback, it is determined to discard the status response information sent by the terminal device; If the second state information is the "end waiting for playback" state, release the audio focus of the target application and update the audio playback state of the target application's interface to the paused state.

9. A vehicle-mounted music control device, characterized in that, The device includes: A sending unit is configured to send a control command to a terminal device in response to a control command from a target application; wherein the control command is used to control the playback or pause of the target application; The first update unit is used to update the target state of the target application to a waiting state corresponding to the control command based on the control command; wherein the waiting state includes a waiting to play state and a waiting to pause state; The second update unit is used to update the target state from the waiting state to the end waiting state corresponding to the waiting state based on the status response information sent by the terminal device when receiving the status response information. A control unit is configured to control the target application to perform an audio operation corresponding to the control command based on the end-wait state; wherein the end-wait state includes an end-wait playback state and an end-wait pause state.

10. A vehicle comprising a processor and a memory, the memory storing a computer program executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 8.

Images