Multi-screen interaction control method and system based on different operating systems of cockpit

Abstract

The invention relates to the technical field of vehicle-mounted systems, screen operation control and the like, provides a multi-screen interaction control method and system based on different operating systems of a cabin, and aims to dynamically adjust window attributes by using window management services supported by different operating systems so as to adapt to different use scenes and improve the user experience. When a user pushes a current application from a current screen to a target screen in a one-way mode through a first operation between different screens, whether the current application supports the first operation or not is judged, when the current application does not support the first operation, the window management service is prompted to not support one-way pushing of the current application, and when the current application supports the first operation, the window management service is prompted to be in one-way pushing. And the current application is pushed to the target screen from the current screen in a one-way manner, so that richness, flexibility and intuition of multi-screen use experience can be improved, and driving and riding convenience is improved.

Description

Technical Field

[0001] This invention relates to the technical fields of vehicle systems and screen operation control, and more specifically, to a multi-screen interactive control method and system based on different operating systems in the cockpit. Background Technology

[0002] In recent years, with the rapid development of connected and intelligent vehicles, technology and human-machine interaction have gradually emerged in the automotive field, and the trends of large screens and multi-screen displays have become increasingly prominent. Against this backdrop, the richness of cockpit display content and the interaction between screens have become particularly important. Large screens and multi-screen designs allow for the display of more information within the cockpit. Multiple screens, such as the central control screen, instrument panel, and passenger entertainment screen, each perform their own function, presenting different information such as navigation, entertainment, and vehicle status, providing a more comprehensive and convenient interactive experience for drivers and passengers. However, simply having multiple screens and rich display content is insufficient to meet the needs of modern users. Interaction between screens has become crucial for improving the user experience. However, current technologies do not provide multi-screen interaction technologies such as one-way application push and dual-screen switching, preventing users from enjoying a richer, more flexible, and intuitive multi-screen experience, resulting in lower convenience for driving and riding.

[0003] In summary, existing multi-screen interaction technologies have technical issues such as the need to improve the richness, flexibility, and intuitiveness of the multi-screen user experience, as well as the need to improve the convenience of driving and riding in vehicles. Summary of the Invention

[0004] The technical problem to be solved by the present invention is to provide a multi-screen interactive control method and related equipment based on different cockpit operating systems, in order to improve the richness, flexibility and intuitiveness of the multi-screen user experience and improve the convenience of driving and riding in a vehicle, in order to address the shortcomings of the above-mentioned technical solutions.

[0005] In a first aspect, the present invention provides a multi-screen interactive control method based on different cockpit operating systems, applied to a cockpit control unit, wherein the cockpit control unit runs different operating systems, and the multi-screen interactive control method based on different cockpit operating systems includes the following steps:

[0006] The window properties are dynamically adjusted using the window management services supported by the different operating systems to adapt to different usage scenarios;

[0007] When a user pushes the current application unidirectionally from the current screen to the target screen through a first operation between different screens, it is determined whether the current application supports the first operation.

[0008] If the current application does not support the first operation, the window management service is prompted that it does not support one-way push of the current application; if the current application supports the first operation, the current application is pushed one-way from the current screen to the target screen.

[0009] Furthermore, the window attributes include a name attribute for identifying the window, size and position attributes for determining the display area of ​​the window on the screen, and a hierarchy attribute for determining the stacking order between windows.

[0010] Furthermore, the different operating systems include Android and QNX; the windows displayed on the screens in the vehicle cockpit are jointly drawn by the Android and QNX systems; the windows drawn by the QNX system include the instrument panel window and the central control screen window, and the windows drawn by the Android system include the driver's entertainment screen window and the passenger's entertainment screen window.

[0011] Furthermore, the Qnx Domain of the QNX system implements the window management service, specifically including: managing the core business processing of windows created on the QNX side, maintaining message queues and window lists, and executing window animations; listening to screen events to realize window creation, destruction, and attribute changes; and communicating with the Android Domain of the Android system through interactive services to coordinate window pushing and screen shifting.

[0012] Furthermore, the Android Domain of the Android system implements the window management service, specifically including: creating, updating, deleting, and adjusting the size and position of windows; managing the display and hiding of windows, as well as the hierarchical relationship between windows; receiving and processing input events from hardware devices, and distributing the input events to the corresponding windows for processing; providing animation and transition functions to make the display, hiding, and movement of windows smooth and natural; and adjusting the size and position of windows according to different screen sizes and resolutions.

[0013] Furthermore, the first operation includes any one of the following: swipe operation, gesture operation, and voice operation; when the first operation is a swipe operation, the swipe operation includes any one of the following: single-finger swipe operation, two-finger swipe operation, and three-finger swipe operation.

[0014] Furthermore, when the first operation is a swipe operation and the current application is pushed in one direction, the same current application is only allowed to be opened on one side of the screen interface at the same time.

[0015] Furthermore, when the current application is pushed to the target screen via a swipe operation, the state of the current application remains unchanged after the swipe operation, and the home screen overlay function remains synchronized with its application interface operation and content.

[0016] Furthermore, devices with different screens are equipped with dual-screen switching buttons. When a user clicks the dual-screen switching button on any device to initiate a bidirectional screen switching request, it is determined whether the current dual-screen application supports switching. If the current dual-screen application does not support switching, the window management service is prompted that the current dual-screen application does not support switching. If the current dual-screen application supports switching, the current dual-screen application is switched between the screens of the different screen devices.

[0017] Secondly, the present invention provides a multi-screen interactive control system based on different cockpit operating systems, including:

[0018] Multiple screens are installed in the vehicle's cabin;

[0019] The cockpit control unit is connected to the multiple screens and controls the interaction of the multiple screens to realize the multi-screen interactive control method based on different cockpit operating systems described above.

[0020] Compared with the prior art, the beneficial effects of this invention are as follows:

[0021] This invention provides a multi-screen interactive control method and system based on different operating systems in the cockpit. By utilizing the window management services supported by the different operating systems, window attributes are dynamically adjusted to adapt to different usage scenarios. When a user pushes the current application unidirectionally from the current screen to the target screen through a first operation, it is determined whether the current application supports the first operation. If the current application does not support the first operation, the window management service is prompted that it does not support the unidirectional push of the current application. If the current application supports the first operation, the current application is pushed unidirectionally from the current screen to the target screen. This can improve the richness, flexibility, and intuitiveness of the multi-screen user experience, and enhance the convenience of driving and riding. Attached Figure Description

[0022] Figure 1 This is a flowchart illustrating a multi-screen interactive control method based on different cockpit operating systems according to an embodiment of the present invention.

[0023] Figure 2 This is a schematic diagram of an architecture of the cockpit control unit of the present invention;

[0024] Figure 3 This is a schematic diagram of an architecture of a multi-screen interactive control system based on different operating systems in the cockpit, according to an embodiment of the present invention.

[0025] Figure 4 This is a schematic diagram of a process for applying one-way push in an embodiment of the present invention;

[0026] Figure 5 This is a schematic diagram of the interface state of a one-way push application according to an embodiment of the present invention;

[0027] Figure 6 This is a schematic diagram of another interface state of the one-way push application according to an embodiment of the present invention;

[0028] Figure 7 This is a flowchart illustrating a dual-screen switching application in an embodiment of the present invention;

[0029] Figure 8 This is a schematic diagram of an interface state for dual-screen switching in an embodiment of the present invention. Detailed Implementation

[0030] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0031] It should be noted that the terms "first," "second," etc., appearing in the specification, claims, and accompanying drawings of this invention are intended to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in sequences other than those illustrated or described herein.

[0032] Example 1

[0033] See Figures 1-8 This embodiment provides a multi-screen interactive control method based on different operating systems in the cockpit, including steps S101, S102, and S103. By utilizing the window management services supported by the different operating systems, the window attributes are dynamically adjusted to adapt to different usage scenarios. When a user pushes the current application unidirectionally from the current screen to the target screen through a first operation, it is determined whether the current application supports the first operation. If the current application does not support the first operation, the window management service is prompted that it does not support the unidirectional push of the current application. If the current application supports the first operation, the current application is pushed unidirectionally from the current screen to the target screen. This can improve the richness, flexibility, and intuitiveness of the multi-screen user experience and enhance the convenience of driving and riding.

[0034] It should be noted that in the multi-screen interactive control method based on different cockpit operating systems, steps S101, S102, and S103 can be executed in the cockpit control unit. The cockpit control unit, as the executing entity for all or part of the steps in the multi-screen interactive control method based on different cockpit operating systems, can execute steps S101, S102, and S103 in this embodiment, as well as some or all of the steps of the method described below. The cockpit control unit may include a memory, processor, and network interface interconnected via a system bus. Those skilled in the art will understand that the cockpit control unit here can be a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions. Its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc. The cockpit control unit can be a smartphone, smart wearable device, or other computing device. The cockpit control unit can interact with the user via a keyboard, mouse, remote control, touchpad, or voice control device. The memory includes at least one type of readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory may be an internal storage unit of the cockpit control unit, such as the hard disk or RAM of the cockpit control unit. In other embodiments, the memory may also be an external storage device of the cockpit control unit, such as a plug-in hard disk, smart media card (SMC), secure digital card (SD), flash card, etc., equipped on the cockpit control unit. Of course, the memory may also include both internal storage units and external storage devices of the cockpit control unit.

[0035] Step S101: Dynamically adjust window attributes using window management services supported by different operating systems to adapt to different usage scenarios. The window attributes include a name attribute to identify the window, size and position attributes to determine the window's display area on the screen, and a hierarchy attribute to determine the stacking order of windows. The different operating systems run on the cockpit control unit. These operating systems include Android and QNX; windows displayed on the vehicle cockpit screens are jointly drawn by the Android and QNX systems. Windows drawn by the QNX system include the instrument panel window and the central control screen window, while windows drawn by the Android system include the driver's entertainment screen window and the passenger's entertainment screen window. The QNX system's QNX Domain implements the window management service, specifically including: managing the core business processing of windows created on the QNX side, maintaining message queues and window lists, and executing window animations; listening to screen events to realize window creation, destruction, and attribute changes; and communicating with the Android Domain of the Android system through interactive services to coordinate window pushing and screen shifting. The Android Domain of the Android system implements the window management service, specifically including: creating, updating, deleting, and adjusting the size and position of windows; managing the display and hiding of windows, as well as the hierarchical relationship between windows; receiving and processing input events from hardware devices, and distributing the input events to the corresponding windows for processing; providing animation and transition functions to make the display, hiding, and movement of windows smooth and natural; and adjusting the size and position of windows according to different screen sizes and resolutions.

[0036] Step S102: When a user pushes the current application unidirectionally from the current screen to the target screen via the first operation, it is determined whether the current application supports the first operation. Step S103: If the current application does not support the first operation, the window management service is prompted that it does not support unidirectional push of the current application; if the current application supports the first operation, the current application is pushed unidirectionally from the current screen to the target screen. In some preferred embodiments, the first operation may include any one of swipe operation, gesture operation, and voice operation; when the first operation is a swipe operation, the swipe operation includes any one of single-finger swipe operation, two-finger swipe operation, and three-finger swipe operation. When the first operation is a swipe operation and the current application is pushed unidirectionally, the same current application is only allowed to be opened on one side of the screen interface at the same time. When the current application is pushed to the target screen via a swipe operation, the state of the current application after the swipe operation remains unchanged, and the home screen overlay function is synchronized with its application interface operation and content.

[0037] See Figures 3-6For example, the vehicle's cabin is equipped with multiple different screens. For instance, the instrument panel screen (Screen A) is mainly used for displaying driving information and driving safety data, and participates in multi-screen interaction. The driver's entertainment screen (Screen B) is mainly used for displaying information from the vehicle's entertainment system and participates in multi-screen interaction. The passenger's entertainment screen (Screen C) is mainly used for displaying information from the passenger's entertainment system and participates in multi-screen interaction. The central control screen (Screen D) is mainly used for quick control of vehicle-related functions and does not participate in multi-screen interaction. It should be noted that in this embodiment, the current application can be swiped from the central control screen to the passenger's entertainment screen, or vice versa. Taking Screens B and C as examples, Screens B and C provide a one-way swiping interaction method for dual-screen applications. Users can push applications from one screen to another between Screens B and C using specific swiping operations (such as three-finger swipes), achieving two-way application operation. This interaction method provides users with the convenience of flexibly operating applications in a multi-screen environment, making application use no longer limited to a single screen. Additionally, taking screens A and B as an example, screens A and B provide a one-way swipe interaction method for dual-screen applications. Users can push the current application from screen A to screen B, but it is not supported to push it from screen B to screen A, thus enabling one-sided application operation. The system interaction follows the principle of "one application, multiple entry points," meaning that the same application is only allowed to be open on one screen at a time, avoiding confusion and conflicts between applications on different screens. Based on the latest request side, when an application is pushed to another screen via swipe, the application state remains unchanged after the swipe push, and the home screen card overlay function and its application interface operation and content must remain synchronized. The system applications involved in one-way push can be broadly divided into two categories: dual-screen functionality that supports swipe push and single-screen exclusive functionality that also supports swipe push. Users can push apps to other screens one-way using methods such as three-finger swipes, gestures, or voice commands. Regardless of the push or return scenario, the original interface will display the original lower-level app interface after the app is pushed or returned; if no app interface is displayed, the homepage will be shown. If the scene displayed on the central control screen is parking or reversing camera footage, to ensure driving safety and avoid interfering with the driver, the passenger entertainment screen cannot be swiped to the central control screen. After a user pushes an app from their own screen to another screen, if they wish to actively recall the app, they only need to tap the entry point on the original screen or use voice commands to open the app. This recall method is consistent with the interaction logic of one-way swiping, meaning that users do not need to perform complex operations; simple taps or voice commands are sufficient. The user of the pushed app screen can actively use a reverse swipe gesture to return the app to its original screen. This design allows for interaction and collaboration between multiple users, making it easy to transfer apps between different screens. For shared apps that do not support push sharing (such as system apps or certain specific apps), swipe gestures will not work.When a user attempts to swipe through these applications, a message will appear on the screen: "Swiping is not supported in the current application scenario," informing the user that the operation is not possible. Applications exclusive to the central control screen and the passenger-side entertainment screen do not support push notifications or sharing; swipe gestures are ineffective, and the screen will display the message "Swiping is not supported in the current application scenario."

[0038] In a further preferred embodiment, when the current application is a music application and appears on the central control screen or the passenger entertainment screen, it is not supported to slide the music application originally appearing on the central control screen or the passenger entertainment screen to the instrument panel screen, but it is supported to slide the music application originally appearing on the passenger entertainment screen to the central control screen, and it is also supported to slide the music application originally appearing on the central control screen to the passenger entertainment screen; when the current application is a video application and appears on the central control screen or the passenger entertainment screen, it is not supported to slide the video application originally appearing on the central control screen or the passenger entertainment screen to the instrument panel screen, but it is supported to slide the video application originally appearing on the passenger entertainment screen to the central control screen, and it is also supported to slide the video application originally appearing on the central control screen to the passenger entertainment screen; when the current application is a radio application... When the current application is a photo app and appears on either the central control screen or the passenger entertainment screen, it is not supported to slide the radio app originally on the central control screen or the passenger entertainment screen to the instrument panel screen, but it is supported to slide the radio app originally on the passenger entertainment screen to the central control screen, and vice versa. Camera apps appearing on the central control screen or passenger entertainment screen can be swiped to the instrument cluster screen. This also applies to camera apps originally appearing on the passenger entertainment screen. However, when the current app is a Bluetooth phone app and appears on either the central control screen or passenger entertainment screen, swiping from the instrument cluster screen to the central control screen is not supported. Similarly, when the current app is a calendar app and appears on either the central control screen or passenger entertainment screen, swiping from the instrument cluster screen to the central control screen is not supported. The calendar app can be swiped from the screen to the instrument cluster screen. Similarly, the calendar app originally on the passenger side entertainment screen can be swiped from the center console screen to the instrument cluster screen. When the current app is a smartphone connectivity app and appears on either the center console screen or the passenger side entertainment screen, swiping from the smartphone connectivity app originally on the center console screen or the passenger side entertainment screen to the instrument cluster screen is not supported, but swiping from the smartphone connectivity app originally on the passenger side entertainment screen to the center console screen is supported. When the current app is a navigation app and appears on either the center console screen or the passenger side entertainment screen, swiping from the navigation app originally on the center console screen or the passenger side entertainment screen to the instrument cluster screen is supported.When the current application is a system settings application and appears on the central control screen or the passenger entertainment screen, it is not supported to slide the system settings application originally appearing on the central control screen or the passenger entertainment screen to the instrument panel screen, but it is supported to slide the system settings application originally appearing on the passenger entertainment screen to the central control screen, and it is also supported to slide the system settings application originally appearing on the central control screen to the passenger entertainment screen; when the current application is a vehicle center application and appears on the central control screen, it is not supported to slide the vehicle center application originally appearing on the central control screen to the instrument panel screen, and it is also not supported to slide the vehicle center application originally appearing on the central control screen to the passenger entertainment screen.

[0039] In some preferred embodiments, when pushing or returning the current application to another screen using methods such as three-finger swipe, gesture, or voice, regardless of the push or return scenario, the original interface will always display the original lower-level application interface after the current application is pushed or returned; if no application interface is displayed, the homepage will be shown. If the scenario displayed on the central control screen is a parking or reversing camera view, to ensure safety during driving and avoid interfering with the driver, the passenger entertainment screen cannot swipe the application to the central control screen. After pushing an application from this screen to another screen, if the pushed application is actively recalled, it can be opened again by clicking the entry on this screen or using voice commands. This recall method is consistent with the interaction logic of one-way swiping, meaning that users do not need to perform complex operations; simple clicks or voice commands are sufficient. The user of the pushed application screen can actively use a reverse swipe gesture to return the application to the original screen. This design allows for interaction and collaboration between multiple users, making it easy to transfer applications between different screens. For shared applications that do not support push sharing (which may be system applications or certain specific applications), swipe gesture operations will be ineffective. When a user attempts to swipe through these applications, a message will appear on the screen: "Swiping is not supported in the current application scenario," informing the user that the operation is not possible.

[0040] See Figure 7 and Figure 8In some preferred embodiments, devices with different screens are equipped with a dual-screen switching button. When a user clicks the dual-screen switching button on either device to initiate a bidirectional screen switching request, it is determined whether the current dual-screen application supports switching. If the current dual-screen application does not support switching, the window management service is prompted that switching of the current dual-screen application is not supported. If the current dual-screen application supports switching, the current dual-screen application is switched between the screens of the different devices. It should be noted that screen B displays the application originally displayed on screen C, and screen C originally displays the application on screen B. When a user initiates an interaction request through device C, the request is sent to device B through device C's communication module. After processing the request, device B's control module decides to accept the interaction and sends the currently displayed content to device C via a one-way push. After receiving the content, device C displays the received content through its display module. During the interaction, the user can initiate a bidirectional screen switching request on either device. This embodiment follows the principle of "one application, multiple entry points." Application switching can only be completed when a specific category of application is open and both screens are active; otherwise, dual-screen switching is not supported. Dual-screen switching uses a touch-sensitive button between the central control screen and the passenger entertainment screen. Clicking this button swaps the currently open applications on both screens. Dual-screen switching is supported only for functions shared by both screens and those unique to a single screen and supporting swipe-to-swipe functionality. Clicking the switch button executes this action. The switch button triggers a single operation; each click performs only one switching action. After a swipe-to-swipe, the application's state (such as the currently open page or settings) remains unchanged. If the central control screen displays a parking or reversing camera view, the passenger entertainment screen cannot switch applications to the central control screen. Preferably, the homepage, navigation, smartphone connectivity, Bluetooth phone, system settings, smartphone connectivity, calendar, camera, photo album, radio, video, music, and vehicle center applications on the driver's entertainment screen do not support switching between screens of different devices; the homepage, navigation, smartphone connectivity, Bluetooth phone, system settings, smartphone connectivity, calendar, camera, photo album, radio, video, music, and vehicle center applications on the passenger's entertainment screen do not support switching between screens of different devices.

[0041] Example 2

[0042] See Figures 1-8 This embodiment provides a multi-screen interactive control system based on different cockpit operating systems, including:

[0043] Multiple screens are installed in the vehicle's cabin;

[0044] The cockpit control unit, connected to the multiple screens, controls the interaction of the multiple screens to realize the multi-screen interaction control method based on different cockpit operating systems described in any of the above embodiments. This method dynamically adjusts window attributes by utilizing the window management services supported by the different operating systems to adapt to different usage scenarios. When a user pushes the current application unidirectionally from the current screen to the target screen via a first operation, it determines whether the current application supports the first operation. If the current application does not support the first operation, it prompts the window management service that it does not support unidirectional push of the current application. If the current application supports the first operation, it pushes the current application unidirectionally from the current screen to the target screen. This enhances the richness, flexibility, and intuitiveness of the multi-screen user experience, improving the convenience of driving and riding.

[0045] It should be noted that the above embodiments are merely preferred embodiments of the present invention, and the scope of protection of the present invention 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 the present invention should be included within the scope of protection of the present invention, and the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A multi-screen interactive control method based on different cockpit operating systems, applied to a cockpit control unit, wherein the cockpit control unit runs different operating systems, characterized in that, The multi-screen interactive control method based on different cockpit operating systems includes the following steps: The window properties are dynamically adjusted using the window management services supported by the different operating systems to adapt to different usage scenarios; When a user pushes the current application unidirectionally from the current screen to the target screen through a first operation between different screens, it is determined whether the current application supports the first operation. If the current application does not support the first operation, the window management service is prompted that it does not support one-way push of the current application; if the current application supports the first operation, the current application is pushed one-way from the current screen to the target screen.

2. The multi-screen interactive control method based on different cockpit operating systems as described in claim 1, characterized in that, The window attributes include a name attribute for identifying the window, size and position attributes for determining the display area of ​​the window on the screen, and a hierarchy attribute for determining the stacking order of windows.

3. The multi-screen interactive control method based on different cockpit operating systems as described in claim 1, characterized in that, The different operating systems include Android and QNX; the windows displayed on the screens in the vehicle cockpit are jointly drawn by the Android and QNX systems; the windows drawn by the QNX system include the instrument panel window and the central control screen window, and the windows drawn by the Android system include the driver's entertainment screen window and the passenger's entertainment screen window.

4. The multi-screen interactive control method based on different cockpit operating systems as described in claim 3, characterized in that, The QNX Domain of the QNX system implements the window management service, which specifically includes: managing the core business processing of windows created on the QNX side, maintaining message queues and window lists, and executing window animations; listening to screen events to realize window creation, destruction, and attribute changes; and communicating with the Android Domain of the Android system through interactive services to coordinate window pushing and screen shifting.

5. The multi-screen interactive control method based on different cockpit operating systems as described in claim 3, characterized in that, The Android Domain of the Android system implements the window management service, specifically including: creating, updating, deleting, and adjusting the size and position of windows; managing the display and hiding of windows, as well as the hierarchical relationship between windows; receiving and processing input events from hardware devices, and distributing the input events to the corresponding windows for processing; providing animation and transition functions to make the display, hiding, and movement of windows smooth and natural; and adjusting the size and position of windows according to different screen sizes and resolutions.

6. The multi-screen interactive control method based on different cockpit operating systems as described in claim 1, characterized in that, The first operation includes any one of the following: swipe operation, gesture operation, and voice operation; when the first operation is a swipe operation, the swipe operation includes any one of the following: single-finger swipe operation, two-finger swipe operation, and three-finger swipe operation.

7. The multi-screen interactive control method based on different cockpit operating systems as described in claim 6, characterized in that, When the first operation is a swipe operation and the current application is pushed in one direction, the same current application is only allowed to be opened on one side of the screen interface at the same time.

8. The multi-screen interactive control method based on different cockpit operating systems as described in claim 7, characterized in that, When the current application is pushed to the target screen via a swipe operation, the state of the current application remains unchanged after the swipe operation, and the home screen overlay function remains synchronized with its application interface operation and content.

9. The multi-screen interactive control method based on different cockpit operating systems as described in any one of claims 1-8, characterized in that, Devices with different screens are equipped with dual-screen switching buttons. When a user clicks the dual-screen switching button on any device to initiate a bidirectional screen switching request, it is determined whether the current dual-screen application supports switching. If the current dual-screen application does not support switching, the window management service is prompted that the current dual-screen application does not support switching. When the current dual-screen application supports switching, the current dual-screen application can be switched between the screens of devices with different screens.

10. A multi-screen interactive control system based on different cockpit operating systems, characterized in that, include: Multiple screens are installed in the vehicle's cabin; The cockpit control unit is connected to the multiple screens and controls the interaction of the multiple screens to realize the multi-screen interactive control method based on different cockpit operating systems as described in any one of claims 1-9.

Images