Vehicle control method and vehicle

Abstract

The present disclosure relates to the technical field of intelligent cockpit, and provides a vehicle control method and a vehicle. A current vehicle screen state is acquired. In response to the current vehicle screen state satisfying a preset change condition, a vehicle screen corresponding to the preset change condition is taken as a target screen, and a change request is sent to a state manager. The state manager receives the change request, determines that the state of the target screen is an active state and the state of other screens except the target screen is a silent state. The state manager determines that a preset broadcast condition is satisfied, and broadcasts a session event. The session event contains a target screen identifier of the target screen. A control component receives the session event and controls the target screen. The present disclosure sets a unique active screen, ensures that only one player instance has control at the same time, eliminates control center information jump, and realizes unified echo and conflict-free control of media state in a multi-screen scenario.

Description

Technical Field

[0001] This disclosure relates to the field of intelligent cockpit technology, and more particularly to a vehicle control method and a vehicle. Background Technology

[0002] In a multi-screen in-vehicle cockpit system, multiple screens can independently run media playback applications. Each player instance publishes its playback status and metadata to the system control center via Android MediaSession.

[0003] When multiple active player instances exist on multiple screens simultaneously, these instances continuously report their status to the system. However, because the system cannot determine which of the multiple players should be the sole data source and control target for the control center, the playback information displayed in the control center frequently jumps between multiple instances, affecting the user's driving experience. Summary of the Invention

[0004] In view of this, the purpose of this disclosure is to propose a vehicle control method and a vehicle, which ensures that only one player instance has control at any given time by setting a unique active screen, thereby eliminating information jumps in the control center and realizing unified display and conflict-free control of media status in multi-screen scenarios.

[0005] To achieve the above objectives, a first aspect of this disclosure provides a vehicle control method, the method comprising:

[0006] Get the current vehicle screen status. In response to the current vehicle screen status meeting the preset change conditions, take the vehicle screen that meets the preset change conditions as the target screen and send a change request to the status manager. Upon receiving the change request, the state manager determines that the target screen is in an active state and that all other screens are in a silent state. The state manager determines that the preset broadcast conditions are met and broadcasts a session event, wherein the session event includes the target screen identifier of the target screen; The control component receives the session event and controls the target screen.

[0007] Based on the same inventive concept, a second aspect of this disclosure provides a vehicle control device, comprising: The data acquisition module is configured to acquire the current vehicle screen status, and in response to the current vehicle screen status meeting the preset change conditions, to take the vehicle screen that meets the preset change conditions as the target screen and send a change request to the status manager. The status setting module is configured such that when the status manager receives a change request, it determines that the status of the target screen is active and the status of other screens besides the target screen is silent. The broadcast module is configured to broadcast a session event when the state manager determines that preset broadcast conditions are met, wherein the session event includes the target screen identifier of the target screen; The screen control module is configured to control the target screen when the control component receives the session event.

[0008] Based on the same inventive concept, a third aspect of this disclosure proposes an electronic device including a memory, a processor, and a computer program stored in the memory and executable by the processor, wherein the processor implements the vehicle control method as described above when executing the computer program.

[0009] Based on the same inventive concept, a fourth aspect of this disclosure provides a non-transitory computer-readable storage medium that stores computer instructions for causing a computer to perform the vehicle control method as described above.

[0010] Based on the same inventive concept, the fifth aspect of this disclosure provides a vehicle including the vehicle control device described in the second aspect, the electronic device described in the third aspect, or the storage medium described in the fourth aspect.

[0011] As can be seen from the above, this disclosure proposes a vehicle control method and a vehicle. It obtains the current vehicle screen state, and in response to the current vehicle screen state meeting preset change conditions, designates the vehicle screen meeting the preset change conditions as the target screen and sends a change request to the state manager. When it is determined that a certain screen of the vehicle meets the preset change conditions, it indicates that the player instance on that screen is an active instance that is interacting, and thus that vehicle screen is designated as the target screen. The system automatically determines control ownership based on the vehicle screen state, eliminating the need for manual selection or confirmation by the user, thereby improving the system's intelligence. Upon receiving the change request, the state manager determines that the target screen is in an active state and that all other screens are in a silent state. The state manager also determines that preset broadcast conditions are met and broadcasts a session event, wherein the session event contains the target screen identifier of the target screen. The control component receives the session event and controls the target screen. By setting the state of the vehicle screen meeting the preset change conditions to an active state and setting the states of the remaining screens to a silent state, it ensures that only one player instance on a screen has control at any given time, eliminating the problem of information jumps in the control center. Furthermore, the target screen is broadcast to the control component, which then confirms the target screen from multiple players as the sole data source and control target of the control center, achieving unified status display and conflict-free control in multi-screen playback scenarios. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in this disclosure or related technologies, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a schematic diagram of a scenario according to an embodiment of the present disclosure; Figure 2 This is a flowchart of a vehicle control method according to an embodiment of the present disclosure; Figure 3 This is a flowchart of a vehicle control method according to another embodiment of the present disclosure; Figure 4 This is a structural block diagram of a vehicle control device according to an embodiment of the present disclosure; Figure 5 This is a schematic diagram of the structure of an electronic device according to an embodiment of the present disclosure. Detailed Implementation

[0014] To make the objectives, technical solutions, and advantages of this disclosure clearer, the following detailed description is provided in conjunction with specific embodiments and the accompanying drawings.

[0015] It should be noted that, unless otherwise defined, the technical or scientific terms used in the embodiments of this disclosure should have the ordinary meaning understood by one of ordinary skill in the art to which this disclosure pertains. The terms "first," "second," and similar terms used in the embodiments of this disclosure do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed following the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are used only to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0016] In a multi-screen cockpit system, multiple screens (such as the driver's screen, passenger's screen, and rear screens) can each run media playback applications independently. Each player instance publishes its playback status (such as playing, paused, and buffering) and metadata (such as song title and album art) to the system control center (such as the notification bar, steering wheel buttons, and Bluetooth headset) via Android MediaSession.

[0017] When multiple active player instances exist on multiple screens simultaneously, these instances continuously report their status to the system. However, because the system's MediaSession framework itself does not have the ability to identify the active instance that the user is currently interacting with, it cannot determine from multiple players which one should be the sole data source and control target of the control center.

[0018] To display current playback information, the control center frequently switches between different instances, such as by the time of the last reported status or by the order in which the instances were created. This causes the song titles, album art, and other information displayed to the user to constantly change, making it impossible to consistently focus on the media stream the user actually wants to control. Furthermore, the play / pause buttons on the steering wheel also lack a clear target instance. When a button is pressed, the system doesn't know which player to send the command to, potentially incorrectly controlling an instance other than the one the user intended, resulting in uncertainty in operation.

[0019] To make the objectives, technical solutions, and advantages of the present invention clearer, specific embodiments will be described below in conjunction with the accompanying drawings.

[0020] refer to Figure 1 , Figure 1 The illustration shows a scenario provided according to an embodiment of this application, in which the devices involved include a media manager 101, a status manager 102, a control component 103, and a vehicle screen 104.

[0021] The media manager 101 acquires the current vehicle screen status. In response to the current vehicle screen status meeting preset change conditions, it designates the vehicle screen 104 corresponding to the preset change conditions as the target screen and sends a change request to the status manager 102. Upon receiving the change request, the status manager 102 determines that the target screen is active and all other screens are silent. The status manager 102 then determines that preset broadcast conditions are met and broadcasts a session event, wherein the session event includes the target screen identifier. The control component 103 receives the session event and controls the target screen.

[0022] refer to Figure 2 , Figure 2 A flowchart illustrating the vehicle control method in this embodiment is shown. The method includes: Step 101: Obtain the current vehicle screen status. In response to the current vehicle screen status meeting the preset change conditions, take the vehicle screen that meets the preset change conditions as the target screen and send a change request to the status manager.

[0023] In practice, the current vehicle screen status is obtained, where the current vehicle screen status represents the current operating status of the vehicle screen, specifically including the screen interaction status and audio focus value.

[0024] In this embodiment, the screen interaction state describes whether the media playback interface on the screen is under direct user interaction, that is, whether the media playback interface on the screen is directly operated by the user. Specifically, the screen interaction state includes an interactive state or a non-interactive state. If the screen interaction state of screen A is interactive, it means that the media playback interface corresponding to screen A is in the foreground. If the screen interaction state of screen B is non-interactive, it means that the media playback interface corresponding to screen B is in the background. It can be understood that whether the media playback interface is in the foreground or background belongs to the lifecycle state of the application or interface.

[0025] In this embodiment, the audio focus value is used to determine the focus state of the screen, and the focus state describes whether the player of the media playback interface corresponding to the screen holds audio focus. The audio focus is used to coordinate multiple players or applications that may emit sound simultaneously, ensuring that only one player can hold audio focus at any given time. At this time, the player holding audio focus has control, meaning the foreground interaction object is the player holding audio focus.

[0026] For example, if player A' holds audio focus, it indicates that the user has an intention to interact with player A', meaning that player A' is the object the user wants to control. If the user clicks play, it means controlling player A' to play.

[0027] Based on the obtained current vehicle screen state, it is determined whether a preset change condition is met. If a vehicle screen meets the preset change condition, it indicates that the player instance on that vehicle screen is an active instance that is currently interacting with the user. The vehicle screen that meets the preset change condition is selected as the target screen, and a change request is sent to the state manager. The change request is a request to change the state of the vehicle screen in the vehicle.

[0028] Step 102: The state manager receives the change request and determines that the target screen is in an active state and the other screens are in a silent state.

[0029] In practice, after receiving a change request, the state manager sets the state of the target screen and the states of other screens. Specifically, it sets the target screen to the active state and sets the other screens to the silent state.

[0030] For example, the vehicle screens include a central control screen, a passenger-side screen, and a passenger-side ceiling-mounted screen. If the current state of the central control screen meets preset change conditions, the media manager sends a change request to the state manager, using the central control screen as the target screen. Upon receiving the change request, the state manager sets the central control screen to an active state and sets the passenger-side screen and the passenger-side ceiling-mounted screen to a silent state.

[0031] In this embodiment, if a screen is in an active state, it indicates that it has session control. Therefore, by setting the target screen to an active state and setting other screens to a silent state, it is ensured that only one playback instance on a screen has session control at any given time, eliminating the problems of control center information jumps and uncertain button control targets.

[0032] Step 103: The state manager determines that the preset broadcast conditions are met and broadcasts a session event, wherein the session event includes the target screen identifier of the target screen.

[0033] In practice, the state manager determines whether the preset broadcast conditions are met. If the preset broadcast conditions are met, the control component needs to be notified that the target screen has changed. The state manager then broadcasts the session event.

[0034] In this embodiment, the session event includes the target screen identifier of the target screen, so that the subsequent control components know that the target screen should be controlled at this time, rather than other vehicle screens, thereby improving the accuracy of control and avoiding the problem of the playback information displayed in the control center frequently changing between multiple instances.

[0035] Step 104: The control component receives the session event and controls the target screen.

[0036] In practice, after receiving a broadcast session event in the channel, the control component obtains the target screen identifier contained in the session event, and then controls the target screen corresponding to the target screen identifier.

[0037] The above scheme obtains the current vehicle screen status. In response to the current vehicle screen status meeting preset change conditions, the vehicle screen meeting the preset change conditions is designated as the target screen, and a change request is sent to the status manager. When a vehicle screen meets the preset change conditions, it indicates that the player instance on that screen is an active instance interacting with the user, thus designating that screen as the target screen. Automatically deciding control ownership based on vehicle screen status eliminates the need for manual user selection or confirmation, improving system intelligence. Upon receiving the change request, the status manager determines that the target screen is active and all other screens are silent. The status manager then determines that preset broadcast conditions are met and broadcasts a session event, which includes the target screen's identifier. The control component receives the session event and controls the target screen. By setting the vehicle screen meeting the preset change conditions to active and the remaining screens to silent, only one screen's player instance has control at any given time, eliminating the problem of control center information jumps. Furthermore, the target screen is broadcast to the control component, which then confirms the target screen from multiple players as the sole data source and control target of the control center, achieving unified status display and conflict-free control in multi-screen playback scenarios.

[0038] In some embodiments, the current vehicle screen state includes the current screen interaction state and the current audio focus value, that is, whether the preset change conditions are met is determined based on the current screen interaction state and the current audio focus value. Specifically, in step 101, obtaining the current vehicle screen state and responding to the current vehicle screen state meeting the preset change conditions involves sending a change request to the state manager, with the vehicle screen meeting the preset change conditions as the target screen. This specifically includes: Step 1011: Obtain the current vehicle screen state and the historical vehicle screen state before the current time, wherein the current vehicle screen state includes the current screen interaction state and the current audio focus value, and the historical vehicle screen state includes the historical screen interaction state and the historical audio focus value. Step 1012: Determine the focus state of the target screen based on the current audio focus value and the historical audio focus value; Step 1013: In response to a change in the screen interaction state or the focus state being held focus, it is determined that the preset change conditions are met, and the vehicle screen corresponding to the preset change conditions is taken as the target screen. The media manager sends a change request to the state manager. The change in screen interaction state indicates that the historical screen interaction state was a non-interactive state and the current screen interaction state is an interactive state.

[0039] In specific implementation, the current vehicle screen state and the historical vehicle screen state before the current time are obtained. The current vehicle screen state includes the current screen interaction state and the current audio focus value, and the historical vehicle screen state includes the historical screen interaction state and the historical audio focus value.

[0040] In this embodiment, the audio focus value is used to determine the focus state of the screen, and the focus state describes whether the player corresponding to the screen holds audio focus. In this embodiment, the Android audio system returns states such as AUDIOFOCUS_GAIN, AUDIOFOCUS_LOSS, and AUDIOFOCUS_LOSS_TRANSIENT through audio focus callbacks.

[0041] Here, AUDIOFOCUS_GAIN indicates that the player has gained audio focus and can start or continue playing audio normally. AUDIOFOCUS_LOSS indicates that the player has permanently lost audio focus, and another application (such as another music player or a long voice call) has already gained focus, making it unlikely that focus will be regained in the short term. AUDIOFOCUS_LOSS_TRANSIENT indicates that the player has temporarily lost audio focus, usually caused by a brief, high-priority audio interruption, and focus will be regained quickly.

[0042] Specifically, different audio focus values ​​correspond to different states. For example, if the audio focus value is 1, the state is determined to be AUDIOFOCUS_GAIN. If the audio focus value is 2, the state is determined to be AUDIOFOCUS_LOSS. If the audio focus value is 3, the state is determined to be AUDIOFOCUS_LOSS_TRANSIENT.

[0043] The focus state of the target screen is determined based on the current audio focus value at the current moment and the historical audio focus value at a previous moment. The focus state includes whether the screen holds focus or not.

[0044] Based on the aforementioned example, if the current audio focus value is 1 at the current moment and the historical audio focus value is 3 at a previous moment, it means that the audio focus of the player on the target screen has changed from being lost to being gained, that is, the focus state of the target screen at this moment is holding focus.

[0045] In another example, if the current audio focus value is 2 and the historical audio focus value is 1, it means that the audio focus of the player on the target screen has gone from being acquired to being lost, that is, the focus state of the target screen at this time is not holding focus.

[0046] In another example, if the current audio focus value is 2 and the historical audio focus value is 3, it means that the audio focus of the player on the target screen has changed from temporary loss to permanent loss, that is, the focus state of the target screen at this time is no focus.

[0047] The screen interaction state is determined based on the current screen interaction state and the historical screen interaction state. In this embodiment, since the target screen needs to be set to an active state when the preset change conditions are met, the screen interaction state changes here. Specifically, it means that the screen changes from a non-interactive state to an interactive state, that is, the historical screen interaction state is a non-interactive state and the current screen interaction state is an interactive state.

[0048] In this embodiment, if the screen interaction state changes, it indicates that the screen where the player is located has returned to the foreground from the background, meaning a new screen has been added to the foreground. At this time, the user has a new intention to interact with the player on that screen, so this screen needs to be set to an active state and given control. If the focus state is "holding focus," it means the audio focus has changed from lost to gained, which also reflects a new intention to interact with the player on that screen. Therefore, this screen also needs to be set to an active state and given control.

[0049] Understandably, if multiple screens are playing content within the vehicle, and a user interacts with one of them, the audio focus value of that screen will change, while the audio focus values ​​of the other screens will remain unchanged. This change in audio focus can then be used to determine the object the user is most likely to want to control.

[0050] In this embodiment, within the multi-screen cockpit of the vehicle, when a user switches a screen to the foreground—for example, by clicking the driver's or passenger's screen to make it the current operating interface—it usually means that the user is about to interact with the content on that screen. At this time, the player instance on that screen becomes the object that the user is most likely to want to control, and therefore should be given control.

[0051] In this embodiment, the Android audio focus mechanism is used to manage the priority of multiple audio sources. When a player instance regains audio focus, such as when the user actively clicks to play or switches back from other media, it indicates that the player instance is the active media source currently being monitored by the user and should be handed over to the control center for unified control.

[0052] Therefore, if the screen interaction state changes, or the focus state is "holding focus," it indicates that the screen where the player is located has returned to the foreground from the background, or that the audio focus has changed from lost to gained. This reflects that the user has a new interactive intention with the player on that screen, so the screen needs to be set to an active state and given control. Therefore, if the preset change conditions are met, the vehicle screen corresponding to the preset change conditions is selected as the target screen, and the media manager sends a change request to the state manager.

[0053] In this embodiment, when a user switches the screen to the foreground, they will most likely continue to control the player on that screen, even if it is not yet playing and the audio focus may not yet be obtained. Therefore, control should be updated simply by switching the screen to the foreground. Furthermore, when a user triggers playback via steering wheel buttons or Bluetooth headphones, the system usually first requests audio focus for the corresponding player. Even if the player with focus is not on the foreground (e.g., the rear screen is in the background but the user instructs it to play via voice command), it should still become the control target.

[0054] Therefore, the two conditions—the player's screen returning to the foreground and the audio focus changing from lost to gained—identify the user's current intent from two independent and sufficient dimensions: visual interaction (screen foreground) and auditory interaction (audio focus). Thus, determining whether either condition is met—the player's screen returning to the foreground or the audio focus changing from lost to gained—is sufficient to confirm that the preset change condition has been met, avoiding response delays or control misalignments caused by relying on a single signal.

[0055] By setting two conditions—a change in screen interaction state and the focus state being the condition for holding focus—the system ensures that regardless of whether the user switches the focus object by operating the screen or the audio control component, the system can promptly and completely transfer control to the correct player instance, thereby avoiding response delays or control misalignments caused by relying on a single signal (such as relying solely on the foreground screen).

[0056] In some embodiments, the state manager maintains a state graph containing state information for at least one vehicle screen. Therefore, when setting the screen state after receiving a change request, the state manager can refer to its maintained state graph. Specifically, step 102, where the state manager receives a change request and determines that the target screen is in an active state and all other screens are in a silent state, includes: Step 1021: The state manager receives a change request and traverses a preset state graph, wherein the state graph contains screen identifiers and state data of at least one vehicle screen. Step 1022: Set the states of all screens in the state graph except the target screen to a silent state; Step 1023: Determine whether the target screen identifier exists in the state graph, and set the state of the target screen to active state based on the first determination result.

[0057] In practice, the state manager maintains a state graph, which contains screen identifiers and state data for at least one vehicle screen. Therefore, upon receiving a change request, the state manager traverses the state graph and sets the states of all screens in the state graph except the target screen to a silent state.

[0058] The state manager determines whether a target screen identifier for the target screen exists in the state graph, that is, whether the screen identifiers contained in the state graph contain a target screen identifier, and obtains a first determination result. The first determination result includes either the screen identifiers contained in the state graph containing a target screen identifier, or the screen identifiers contained in the state graph not containing a target screen identifier.

[0059] After obtaining the first judgment result, the state of the target screen is set to active state based on the first judgment result.

[0060] The above scheme sets the screen state by traversing the state graph. Based on a unified data source, it processes all recorded screens in one go without omission, ensuring that all screens except the target screen are accurately set to a silent state, thereby avoiding multi-active conflicts caused by omissions or scattered control.

[0061] In some embodiments, when setting the state of the target screen to an active state based on the first determination result, if the target screen identifier already exists in the state graph of the state manager, then the state of the target screen can be directly set to an active state. That is, setting the state of the target screen to an active state based on the first determination result in step 1023 specifically includes: Step 10231: In response to the first determination result that the target screen identifier of the target screen exists in the state map, set the state of the target screen to active state; or, Step 10232: In response to the first determination result that the target screen identifier of the target screen does not exist in the state graph, the screen identifier of the target screen and the first state data are added to the state graph, wherein the first state data is an active state.

[0062] In specific implementation, if the first determination result indicates that the target screen identifier exists in the state graph, its state is directly updated to active state. This avoids multiple records for the same screen in the state graph, ensuring that each screen has only one authoritative state and preventing duplicate additions. Simultaneously, for existing screens, their states are directly modified without losing other original attributes, ensuring that the old state is correctly overwritten. That is, if the first determination result indicates that the target screen identifier exists in the state graph, the state of the target screen is directly set to active state.

[0063] If the first determination result is that the target screen identifier of the target screen does not exist in the state graph, a record is created in the state graph and the state is set to active state, that is, the screen identifier of the target screen and the first state data are added to the state graph, wherein the first state data is active state.

[0064] The above scheme ensures the integrity and robustness of the state graph, avoids the abnormality of repeatedly adding or covering existing screens, and can dynamically accept new screens and automatically assign them active states, thereby ensuring the uniqueness and scalability of active states in a multi-screen environment and making the state management logic simple and reliable.

[0065] In some embodiments, when determining whether preset broadcast conditions are met, the state manager may make this determination based on historical states, historical audio region identifiers, and target audio region identifiers. Specifically, step 103, where the state manager determines that the preset broadcast conditions are met and broadcasts a session event, includes: Step 1031: The state manager obtains the historical state and historical audio zone identifier corresponding to the target screen before the current time, and determines the target audio zone identifier corresponding to the target screen; Step 1032: In response to the historical state being silent or the historical audio region identifier being different from the target audio region identifier, determine that the preset broadcast conditions are met and broadcast the session event.

[0066] In specific implementation, the state manager obtains the historical state and historical audio zone identifier corresponding to the target screen before the current time, and determines the target audio zone identifier corresponding to the target screen. The target audio zone identifier is the audio zone identifier determined when the current vehicle screen state meets the preset change conditions.

[0067] In this embodiment, the audio zone identifier indicates the identifier of the audio playback device required when the vehicle screen plays audio. Specifically, the audio playback device includes a speaker, a Bluetooth device connected to the passenger-side screen, a Bluetooth device connected to the ceiling-mounted screen, a Bluetooth device connected to the seatback screen, etc. It can be understood that if the screen supports connecting to Bluetooth devices, then the audio playback device corresponding to the screen includes a speaker and a Bluetooth device connected to it.

[0068] Different audio playback devices have different sound zone identifiers. For example, the sound zone identifier for a speaker is 1, that for a Bluetooth device connected to the passenger-side screen is 4, and that for a Bluetooth device connected to a ceiling-mounted screen is 8, etc.

[0069] The historical audio zone identifier is compared with the target audio zone identifier. If the historical state is silent, or the historical audio zone identifier is different from the target audio zone identifier, it indicates that the state of the target screen has changed or the audio zone identifier has changed. At this time, it is determined that the preset broadcast conditions are met, and a session event is broadcast. The session event includes the target screen identifier of the target screen.

[0070] For example, if the user selects to switch the playback from the speaker to the Bluetooth device on the passenger screen, the historical audio zone identifier is the audio zone identifier corresponding to the speaker, and the target audio zone identifier is the audio zone identifier corresponding to the Bluetooth device. That is, the audio zone identifier changes, which meets the preset broadcast conditions and broadcasts the session event.

[0071] Understandably, if the target screen's historical state is active and the historical audio zone identifier is the same as the target audio zone identifier, the preset broadcast conditions are not met, and the session event is not broadcast.

[0072] In this embodiment, a broadcast path needs to be established before broadcasting a session event. If the preset broadcast conditions are met but the broadcast path has not yet been established, the session event is stored and a corresponding compensation flag is set. Therefore, before broadcasting the session event, the state manager determines whether there is a previously unnotified compensation flag. If so, the historical session event corresponding to the compensation flag is broadcast first, and then the current session event is broadcast.

[0073] With the above scheme, the preset broadcast conditions are met and a broadcast notification is triggered only when the historical state is silent or the historical audio region identifier is different from the target audio region identifier, thus avoiding repeated broadcasts.

[0074] In some embodiments, when determining the target audio region identifier, in addition to determining it based on the audio playback device, it is also necessary to consider whether the user manually adjusts the audio region. That is, determining the target audio region identifier corresponding to the target screen in step 1031 specifically includes: Step 10311: Obtain the audio playback device corresponding to the target screen, and determine the initial sound zone identifier based on the audio playback device; Step 10312: In response to detecting a register adjustment command, the identifier of the target register corresponding to the register adjustment command is used as the target register identifier; or, Step 10313: In response to the absence of a registered pitch adjustment command, the initial pitch identifier is used as the target pitch identifier.

[0075] In specific implementation, the audio playback device corresponding to the target screen is obtained, and an initial sound zone identifier is determined based on the audio playback device. Specifically, the audio playback device includes a speaker, a Bluetooth device connected to the passenger-side screen, a Bluetooth device connected to the ceiling-mounted screen, and a Bluetooth device connected to the seatback screen, etc. It is understood that if the screen supports connecting to Bluetooth devices, then the audio playback device corresponding to that screen includes a speaker and a Bluetooth device connected to it.

[0076] Different audio playback devices have different zone identifiers, and the zone identifier determined by the audio playback device is used as the initial zone identifier. For example, the zone identifier corresponding to the speaker is 1, the Bluetooth device connected to the passenger screen is 4, and the Bluetooth device connected to the ceiling screen is 8, etc.

[0077] Determine whether a sound zone adjustment command is detected, wherein the sound zone adjustment command is a command for the user to manually adjust the sound zone. For example, the initial sound zone identifier corresponding to the target screen is 1, and the user may select an independent sound field mode. The sound zone identifier of the target sound zone corresponding to the independent sound field mode is 3, then the target sound zone identifier is 3 at this time.

[0078] If a register adjustment command is detected, the identifier corresponding to the target register of the register adjustment command is used as the target register identifier. If no register adjustment command is detected, the initial register identifier is used as the target register identifier.

[0079] The above solution uses the identifier corresponding to the target audio zone selected by the user as the target audio zone identifier when a volume zone adjustment command is received, in order to meet user needs and improve the user's driving experience.

[0080] In some embodiments, when a preset broadcast condition is met and a session event is broadcast, the state manager first sends a broadcast notification to the session component, then the session component sends the session event, and finally the session connector broadcasts the session event. Specifically, step 1032, where the state manager determines that the preset broadcast condition is met and broadcasts the session event, includes: Step 10321: The state manager determines that the preset broadcast conditions are met and sends a broadcast notification to the session component; Step 10322: The session component receives the broadcast notification, sends a session event to the session connector, and the session connector receives the session event and broadcasts it. The session event includes at least one of the following: the target screen identifier, the target audio zone identifier, the media type of the target screen, and the current time stamp.

[0081] In specific implementation, when the state manager determines that the preset broadcast conditions are met, it sends a broadcast notification to the session component. Upon receiving the broadcast notification, the session component sends a session event to the session connector, wherein the session event includes at least one of the following: the target screen identifier, the target audio region identifier, the media type of the target screen, and the current timestamp.

[0082] In this embodiment, in a multi-screen cockpit, the same system control center may simultaneously receive events from different media sources such as video, audio, broadcast, and Bluetooth music. Therefore, the session event includes the media type so that the control component can clearly identify which type of media application or media service the session event belongs to, avoiding the inability to distinguish the service source.

[0083] Specifically, the control component differentiates between video and audio applications based on media type, employing different UI display or control strategies. Furthermore, when multiple media applications coexist, it avoids mistaking video playback events for audio playback events.

[0084] The session connector receives the session event and broadcasts it so that the control component can receive the broadcast and obtain the session event.

[0085] By injecting the target screen identifier, target audio zone identifier, target screen media type, and current timestamp into the session event, a context-rich session event broadcast is constructed, enabling the control component to have complete judgment criteria in multi-screen scenarios.

[0086] In some embodiments, if a user triggers a screen change and performs screen migration, such as migrating the video from the central control screen to the passenger-side screen for playback, the central control screen should be set to a silent state to prevent both the central control screen and the passenger-side screen from having control. That is, the method further includes: Step 10A: In response to receiving a screen migration command, determine the migration screen corresponding to the screen migration command; Step 10B: The state manager sets the state of the target screen to a silent state, determines whether the migrated screen has focus, and determines the second state data corresponding to the migrated screen based on the second determination result.

[0087] In practice, if a screen migration command is received, it means that the user is performing a screen migration, whereby the user chooses to change the audio and video playing on the current screen to be played on another screen.

[0088] The migration screen corresponding to the screen migration command is determined. The migration screen is the screen where audio and video will continue to play after the migration. For example, the video on the central control screen is migrated to the passenger-side screen for playback, and in this case, the passenger-side screen is the migration screen.

[0089] If screen migration is performed, the content will no longer be played on the target screen. As a result, the state manager will set the target screen to a silent state to prevent the old screen from continuing to have control.

[0090] Determining whether the migrated screen holds focus, and determining the second state data corresponding to the migrated screen based on the second determination result, specifically includes: Step A: In response to the second determination result that the migrated screen holds focus, determine that the second state data corresponding to the migrated screen is in an active state; or, Step B: In response to the second judgment result that the migration screen does not hold focus, the second state data corresponding to the migration screen is determined to be a silent state.

[0091] In specific implementation, if the second judgment result is that the migration screen holds focus, that is, the migration screen can have control at this time, then the second state data corresponding to the migration screen is determined to be active.

[0092] If the second determination result indicates that the migrated screen does not hold focus, the player on the migrated screen may be in a paused, background, interrupted by other audio sources, or lack control. To avoid preempting control of other currently playing instances, the second state data corresponding to the migrated screen is determined to be in a silent state, meaning that control is not forcibly seized due to screen migration.

[0093] When the second state data of the migrated screen is determined to be active, the session event will carry the screen identifier and audio zone identifier corresponding to the migrated screen, so that the control component can switch the control center display, steering wheel button control target, etc. from the target screen to the migrated screen.

[0094] The above scheme sets the target screen to a silent state during screen migration. The migrating screen gains control when it holds audio focus, and the broadcast context is updated synchronously. This avoids control vacuum, dual holding, or incorrect control target, and ensures the continuity and consistency of the state during the control transfer process.

[0095] Based on the same inventive concept, another embodiment of this disclosure provides a vehicle control method, such as... Figure 3 As shown, Figure 3 A flowchart illustrating the vehicle control method is shown, comprising a screen, a media manager, a state manager, a session component, a session connector, and a control component. If the vehicle has screen A and screen B, the control component serves as the system control center, and the method specifically includes: When screen A moves from the background to the foreground, meaning that screen A's historical screen interaction state is non-interactive and its current screen interaction state is interactive, the preset change conditions are met. At this point, notifyActiveChanged(true) is triggered, and then the media manager VideoManager sends a change request to the status manager ActiveStatusManager, specifically notifyActive(displayId_A), where displayId is the screen identifier of screen A.

[0096] The ActiveStatusManager iterates through its maintained state graph mActiveStatusMap, setting the state of all screens in the graph except screen A to a silent state (i.e., marking them as inactive with isActive), triggering notifyInactive(displayId_B), which degrades screen B, triggering notifyActiveChanged(false, displayId_B), and sending the notification to the MediaSessionKit session component. To set screen A to an active state, it creates / updates ActiveStatus(displayId_A), marking it as active with isActive, triggering notifyActiveChanged(true, displayId_A), and sending the notification to the MediaSessionKit session component.

[0097] The state manager determines that the preset broadcast conditions are met, i.e. the isActive flag or the zone identifier zoneId changes. The session component MediaSessionKit constructs a session event SessionEvent based on the target screen identifier displayId, the target zone identifier zoneId, the media type, and the current timestamp of screen A, and sends the session event to the session connector MediaSessionConnector, i.e., triggers sendSessionEvent(event, data).

[0098] The MediaSessionConnector receives the session event and broadcasts it. The system control center receives the session event and controls screen A, such as updating the playback information of screen A.

[0099] It should be noted that the method of this disclosure embodiment can be executed by a single device, such as a computer or server. The method of this embodiment can also be applied to a distributed scenario, where multiple devices cooperate to complete the task. In such a distributed scenario, one of these devices may execute only one or more steps of the method of this disclosure embodiment, and the multiple devices will interact with each other to complete the method described.

[0100] It should be noted that the above description describes some embodiments of this disclosure. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in a different order than that shown in the above embodiments and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0101] Based on the same inventive concept, corresponding to any of the above-described embodiments, this disclosure also provides a vehicle control device.

[0102] refer to Figure 4 , Figure 4 The vehicle control device, as described in this embodiment, includes: The data acquisition module 401 is configured to acquire the current vehicle screen status, and in response to the current vehicle screen status meeting the preset change conditions, to take the vehicle screen that meets the preset change conditions as the target screen and send a change request to the status manager. The status setting module 402 is configured such that when the status manager receives a change request, it determines that the status of the target screen is active and the status of other screens besides the target screen is silent. The broadcast module 403 is configured to broadcast a session event when the state manager determines that the preset broadcast conditions are met, wherein the session event includes the target screen identifier of the target screen; The screen control module 404 is configured to control the target screen when the control component receives the session event.

[0103] In some embodiments, the data acquisition module 401 is specifically configured as follows: Obtain the current vehicle screen state and the historical vehicle screen state before the current time, wherein the current vehicle screen state includes the current screen interaction state and the current audio focus value, and the historical vehicle screen state includes the historical screen interaction state and the historical audio focus value. The focus state of the target screen is determined based on the current audio focus value and the historical audio focus value. In response to a change in the screen interaction state or the focus state being held focus, if a preset change condition is met, the vehicle screen corresponding to the preset change condition is taken as the target screen, and the media manager sends a change request to the state manager. The change in screen interaction state indicates that the historical screen interaction state was a non-interactive state and the current screen interaction state is an interactive state.

[0104] In some embodiments, the status setting module 402 is specifically configured as follows: When the state manager receives a change request, it traverses a preset state graph, wherein the state graph contains screen identifiers and state data of at least one vehicle screen. Set the states of all screens in the state graph, except for the target screen, to a silent state; Determine whether the target screen identifier exists in the state graph, and set the state of the target screen to active state based on the first determination result.

[0105] In some embodiments, the status setting module 402 is specifically configured as follows: In response to the first determination result indicating that a target screen identifier for the target screen exists in the state map, the state of the target screen is set to active; or... In response to the first determination result that the target screen identifier of the target screen does not exist in the state graph, the screen identifier of the target screen and the first state data are added to the state graph, wherein the first state data is an active state.

[0106] In some embodiments, the broadcast module 403 is specifically configured as follows: The state manager obtains the historical state and historical audio zone identifier of the target screen before the current time, and determines the target audio zone identifier of the target screen. In response to the historical state being silent or the historical audio region identifier being different from the target audio region identifier, if the preset broadcast conditions are met, a broadcast session event is broadcast.

[0107] In some embodiments, the broadcast module 403 is specifically configured as follows: Obtain the audio playback device corresponding to the target screen, and determine the initial sound zone identifier based on the audio playback device; In response to detecting a register adjustment command, the identifier of the target register corresponding to the register adjustment command is used as the target register identifier; or, In response to the absence of a registered pitch adjustment command, the initial pitch identifier is used as the target pitch identifier.

[0108] In some embodiments, the broadcast module 403 is specifically configured as follows: The state manager determines that the preset broadcast conditions are met and sends a broadcast notification to the session component; The session component receives the broadcast notification, sends a session event to the session connector, and the session connector receives the session event and broadcasts it. The session event includes at least one of the following: the target screen identifier, the target audio zone identifier, the media type of the target screen, and the current time stamp.

[0109] In some embodiments, the device further includes a screen migration module, which is specifically configured to: In response to receiving a screen migration command, determine the migration screen corresponding to the screen migration command; The state manager sets the target screen to a silent state, determines whether the migrated screen has focus, and determines the second state data corresponding to the migrated screen based on the second determination result.

[0110] In some embodiments, the screen migration module is specifically configured as follows: In response to the second determination result that the migrated screen holds focus, the second state data corresponding to the migrated screen is determined to be in an active state; or, In response to the second determination result that the migrated screen does not hold focus, the second state data corresponding to the migrated screen is determined to be a silent state.

[0111] For ease of description, the above apparatus is described in terms of its functions, divided into various modules. Of course, in implementing this disclosure, the functions of each module can be implemented in one or more software and / or hardware.

[0112] The apparatus of the above embodiments is used to implement the corresponding vehicle control method in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0113] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this disclosure also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the vehicle control method described in any of the above embodiments.

[0114] Figure 5 This embodiment illustrates a more specific hardware structure of an electronic device. The device may include a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. The processor 1010, memory 1020, input / output interface 1030, and communication interface 1040 are interconnected internally via the bus 1050.

[0115] The processor 1010 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this specification.

[0116] The memory 1020 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 1020 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented by software or firmware, the relevant program code is stored in the memory 1020 and is called and executed by the processor 1010.

[0117] The input / output interface 1030 is used to connect input / output modules to realize information input and output. Input / output modules can be configured as components within the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Input devices may include keyboards, mice, touchscreens, microphones, various sensors, etc., while output devices may include displays, speakers, vibrators, indicator lights, etc.

[0118] The communication interface 1040 is used to connect a communication module (not shown in the figure) to enable communication between this device and other devices. The communication module can communicate via wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0119] Bus 1050 includes a pathway for transmitting information between various components of the device, such as processor 1010, memory 1020, input / output interface 1030, and communication interface 1040.

[0120] It should be noted that although the above-described device only shows the processor 1010, memory 1020, input / output interface 1030, communication interface 1040, and bus 1050, in specific implementations, the device may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the above-described device may only include the components necessary for implementing the embodiments of this specification, and not necessarily all the components shown in the figures.

[0121] The electronic devices described above are used to implement the corresponding vehicle control methods in any of the foregoing embodiments and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0122] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this disclosure also provides a non-transitory computer-readable storage medium storing computer instructions for causing the computer to execute the vehicle control method as described in any of the above embodiments.

[0123] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0124] The computer instructions stored in the storage medium of the above embodiments are used to cause the computer to execute the vehicle control method as described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0125] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this application also provides a vehicle, including the vehicle control device, the electronic device, and the computer-readable storage medium in the above embodiments, wherein the vehicle device implements the vehicle control method described in any of the above embodiments.

[0126] The vehicles described in the above embodiments are used to implement the vehicle control method described in any of the foregoing embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0127] It is understood that before using the technical solutions of the various embodiments in this disclosure, users will be informed of the type, scope of use, and usage scenarios of the personal information involved in an appropriate manner, and user authorization will be obtained.

[0128] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose, based on the prompt message, whether to provide personal information to the software or hardware such as electronic devices, applications, servers, or storage media performing the operations of this disclosed technical solution.

[0129] As an optional but not limited implementation, in response to a user's active request, sending a prompt message to the user can be done via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0130] It is understood that the above notification and user authorization process are merely illustrative and do not constitute a limitation on the implementation of this disclosure. Other methods that comply with relevant laws and regulations may also be applied to the implementation of this disclosure.

[0131] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of this disclosure (including the claims) is limited to these examples; within the framework of this disclosure, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of the embodiments of this disclosure as described above, which are not provided in detail for the sake of brevity.

[0132] Additionally, to simplify the description and discussion, and to avoid obscuring the embodiments of this disclosure, the provided drawings may or may not show well-known power / ground connections to integrated circuit (IC) chips and other components. Furthermore, the apparatus may be shown in block diagram form to avoid obscuring the embodiments of this disclosure, and this also takes into account the fact that the details of implementation of these block diagram apparatuses are highly dependent on the platform on which the embodiments of this disclosure will be implemented (i.e., these details should be fully understood by those skilled in the art). While specific details (e.g., circuits) have been set forth to describe exemplary embodiments of this disclosure, it will be apparent to those skilled in the art that the embodiments of this disclosure can be implemented without these specific details or with variations thereof. Therefore, these descriptions should be considered illustrative rather than restrictive.

[0133] Although this disclosure has been described in conjunction with specific embodiments thereof, many substitutions, modifications, and variations of these embodiments will be apparent to those skilled in the art from the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may be used with the embodiments discussed.

[0134] This disclosure is intended to cover all such substitutions, modifications, and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A vehicle control method, characterized in that, include: Get the current vehicle screen status. In response to the current vehicle screen status meeting the preset change conditions, take the vehicle screen that meets the preset change conditions as the target screen and send a change request to the status manager. Upon receiving the change request, the state manager determines that the target screen is in an active state and that all other screens are in a silent state. The state manager determines that the preset broadcast conditions are met and broadcasts a session event, wherein the session event includes the target screen identifier of the target screen; The control component receives the session event and controls the target screen.

2. The method according to claim 1, characterized in that, The step of obtaining the current vehicle screen state, in response to the current vehicle screen state meeting preset change conditions, taking the vehicle screen corresponding to the preset change conditions as the target screen, and sending a change request to the state manager includes: Obtain the current vehicle screen state and the historical vehicle screen state before the current time, wherein the current vehicle screen state includes the current screen interaction state and the current audio focus value, and the historical vehicle screen state includes the historical screen interaction state and the historical audio focus value. The focus state of the target screen is determined based on the current audio focus value and the historical audio focus value. In response to a change in the screen interaction state or the focus state being held focus, if a preset change condition is met, the vehicle screen corresponding to the preset change condition is taken as the target screen, and the media manager sends a change request to the state manager. The change in screen interaction state indicates that the historical screen interaction state was a non-interactive state and the current screen interaction state is an interactive state.

3. The method according to claim 1, characterized in that, The state manager receives a change request and determines that the target screen is in an active state and all other screens are in a silent state, including: When the state manager receives a change request, it traverses a preset state graph, wherein the state graph contains screen identifiers and state data of at least one vehicle screen. Set the states of all screens in the state graph, except for the target screen, to a silent state; Determine whether the target screen identifier exists in the state graph, and set the state of the target screen to active state based on the first determination result.

4. The method according to claim 3, characterized in that, Setting the target screen to an active state based on the first judgment result includes: In response to the first determination result indicating that a target screen identifier for the target screen exists in the state map, the state of the target screen is set to active; or... In response to the first determination result that the target screen identifier of the target screen does not exist in the state graph, the screen identifier of the target screen and the first state data are added to the state graph, wherein the first state data is an active state.

5. The method according to claim 1, characterized in that, The state manager determines that preset broadcast conditions are met and broadcasts session events, including: The state manager obtains the historical state and historical audio zone identifier of the target screen before the current time, and determines the target audio zone identifier of the target screen. In response to the historical state being silent or the historical audio region identifier being different from the target audio region identifier, if the preset broadcast conditions are met, a broadcast session event is broadcast.

6. The method according to claim 5, characterized in that, Determining the target audio region identifier corresponding to the target screen includes: Obtain the audio playback device corresponding to the target screen, and determine the initial sound zone identifier based on the audio playback device; In response to detecting a register adjustment command, the identifier of the target register corresponding to the register adjustment command is used as the target register identifier; or, In response to the absence of a registered pitch adjustment command, the initial pitch identifier is used as the target pitch identifier.

7. The method according to claim 5, characterized in that, The state manager determines that preset broadcast conditions are met and broadcasts session events, including: The state manager determines that the preset broadcast conditions are met and sends a broadcast notification to the session component; The session component receives the broadcast notification, sends a session event to the session connector, and the session connector receives the session event and broadcasts it. The session event includes at least one of the following: the target screen identifier, the target audio zone identifier, the media type of the target screen, and the current time stamp.

8. The method according to claim 1, characterized in that, Also includes: In response to receiving a screen migration command, determine the migration screen corresponding to the screen migration command; The state manager sets the target screen to a silent state, determines whether the migrated screen has focus, and determines the second state data corresponding to the migrated screen based on the second determination result.

9. The method according to claim 8, characterized in that, The step of determining the second state data corresponding to the migration screen based on the second judgment result includes: In response to the second determination result that the migrated screen holds focus, the second state data corresponding to the migrated screen is determined to be in an active state; or, In response to the second determination result that the migrated screen does not hold focus, the second state data corresponding to the migrated screen is determined to be a silent state.

10. A vehicle, characterized in that, include: Memory, used to store executable programs; processor; When the executable program is executed by the processor, the method as described in any one of claims 1-9 is implemented.

Images