Vehicle-mounted screen account management method and device and vehicle-mounted machine system

Abstract

The embodiment of the invention relates to a vehicle-mounted screen account management method and device and a vehicle-mounted infotainment system. After a first account is started, an account switching event is monitored, a second account is obtained, the first account is switched to be in a background state, the second account is started, and the second account is switched to be in a foreground state of a vehicle-mounted screen; and according to the display state of the account to which the associated window of the vehicle-mounted screen belongs, synthesizing and displaying all the associated windows in the foreground state. Therefore, the account of the vehicle-mounted screen can be quickly switched, and after the account is switched, the original account associated window is invisible, so that the privacy disclosure risk is greatly reduced, and the data security is improved.

Description

Technical Field

[0001] This invention relates to the field of automotive electronics technology, specifically to a method, device, and vehicle infotainment system for managing in-vehicle screen accounts. Background Technology

[0002] With the continuous improvement of automotive intelligence, the intelligent cockpit has become a core area for enhancing user experience. Modern intelligent cockpits are generally equipped with multiple displays (such as the driver's screen, passenger screen, and rear left and right screens), providing drivers and passengers with rich infotainment services and convenient interactive experiences. Currently, mainstream in-vehicle infotainment systems (IVI) are mainly built on the Android operating system. To achieve independent display, personalized customization, and application data isolation for multiple screens in the vehicle, existing technologies generally adopt Android multi-user technology. Under this solution, each screen in the vehicle (or multiple screens in a specific combination) is assigned and bound to an independent Android user account.

[0003] However, this management model, which centers on individual Android users around a single screen (or screen group), has significant shortcomings and user drawbacks when faced with the need to manage all in-vehicle screens uniformly using accounts as the management unit: (1) Inconvenient switching and privacy leakage risk: When the vehicle needs to be temporarily used by a non-owner, the current solution cannot easily hide all the original occupants' personalized settings and application data. Unauthorized users may be able to directly see all applications, shortcuts, and even application content that may contain personal data associated with the Android user bound to each screen, posing a serious privacy leakage risk. If all personal information needs to be temporarily hidden, the administrator must log in to the Android user account bound to each screen one by one to log out or switch to a preset "public" account, which is extremely cumbersome and time-consuming. Similarly, when restoring, it is also necessary to switch back to the original user one by one.

[0004] (2) Lack of a unified account perspective: The management unit of the existing solution is the “screen” and its associated “Android user”, rather than the “personal account” for the end user.

[0005] (3) Unable to switch “vehicle account”: Users cannot instantly switch the display status of all screens in the vehicle to a preset public or visitor status without personal privacy information with a single operation. Furthermore, after the visitor finishes using the vehicle, it is not possible to restore all screens to their previous personalized status with one click in the same convenient way.

[0006] Therefore, there is an urgent need for a multi-screen collaborative management solution centered on natural person accounts to solve the key issues of unified cross-screen control and privacy protection. Summary of the Invention

[0007] In view of the above problems, this invention provides a method, device and vehicle system for managing in-vehicle screen accounts, which solves the problems of inconvenience in switching between multiple screens and the risk of privacy leakage, lack of a unified account perspective and inability to switch between "whole vehicle accounts" in the prior art.

[0008] According to one aspect of the present invention, a method for managing in-vehicle screen accounts is provided, applied to an in-vehicle infotainment system with an in-vehicle screen, comprising: Activate the first account and switch it to the foreground mode on the vehicle screen; Listen for account switching events and obtain the second account. Switch the first account to the background state, start the second account, and switch the second account to the foreground state of the vehicle screen. Based on the display status of the account to which the associated window on the vehicle screen belongs, all associated windows in the foreground status are combined and displayed. When there are multiple in-vehicle screens, both the first account and the second account are set up with multiple target users to control different in-vehicle screens.

[0009] In some optional embodiments, after the first account is started, it is determined whether the first account is started for the first time. If so, the first account is created and the account information is configured; otherwise, the configuration signal of the first account is loaded, and the first account is switched to the foreground state on the vehicle screen according to the configuration signal.

[0010] In some optional embodiments, the creation of the first account and configuration of account information specifically includes: Create a first account, wherein the first account has at least one target user, and each target user has a user ID; According to the account configuration policy, the user ID of the target user is bound to the in-vehicle screen.

[0011] In some optional embodiments, the user ID of the target user is bound to the in-vehicle screen according to the account configuration policy, specifically including: The account configuration policy is loaded, and the user associations under the first account are parsed and saved through the first hash mapping table; The target user of the first account and the in-vehicle screen are parsed and saved through the second hash mapping table; By constructing an account configuration object to store a first hash mapping table, a second hash mapping table, and a third hash mapping table, the user ID of the target user is bound to the in-vehicle screen.

[0012] In some optional embodiments, when a target user runs an application on an in-vehicle screen, the user ID of the application's executable file is used to obtain the in-vehicle screen ID corresponding to the target user through a second hash mapping table. By modifying the specified screen in the intent pointing function of the launcher, the application run by the target user can be displayed on the corresponding in-vehicle screen.

[0013] In some optional embodiments, based on the display status of the account to which the associated window on the vehicle screen belongs, all associated windows in the foreground are combined and displayed, specifically including: Iterate through all associated windows of the vehicle screen and determine whether the account to which the associated window belongs is in the foreground. If so, mark the associated window as visible; otherwise, mark the associated window as invisible. All visible associated windows are rendered and composited, and then displayed on the vehicle screen.

[0014] In some optional embodiments, all associated windows of the vehicle screen are traversed, and it is determined whether the account to which the associated window belongs is in the foreground state. If so, the associated window is marked as visible; otherwise, the associated window is marked as invisible. Specifically, this includes: Iterate through all associated windows on the vehicle screen; Get the window properties of each associated window, and then get the user ID through the window properties; Based on the user ID, determine whether the account to which the associated window belongs is in the foreground state. If so, mark the associated window as visible; otherwise, mark the associated window as invisible.

[0015] In some optional embodiments, rendering and compositing all visible associated windows and displaying them on the vehicle screen specifically includes: The associated windows in the visible state are submitted to the display compositing system for rendering and merging, and then displayed on the in-vehicle screen.

[0016] According to another aspect of the present invention, a screen account management device is provided, the device comprising: The first screen display module is used to start the first account and switch the first account to the foreground state on the vehicle screen. When there are multiple vehicle screens, the first account is set to allow multiple target users to control different vehicle screens. The account switching module is used to listen for account switching events and obtain the second account, switch the first account to the background state, start the second account, and switch the second account to the foreground state of the vehicle screen. And a second screen display module, used to synthesize and display all associated windows in the foreground state according to the display status of the account to which the associated window of the vehicle screen belongs. When there are multiple vehicle screens, the second account is set with multiple target users to control different vehicle screens.

[0017] According to another aspect of the present invention, a vehicle infotainment system is provided, including: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other through the communication bus; The memory is used to store at least one executable instruction that causes the processor to perform operations such as the in-vehicle screen account management method described above.

[0018] This invention provides a method, device, and vehicle system for managing in-vehicle screen accounts. Its advantages include: after activating the first account, the invention listens for account switching events and acquires the second account, switches the first account to the background, activates the second account, and switches the second account to the foreground state of the in-vehicle screen; based on the display state of the accounts to which the associated windows of the in-vehicle screen belong, all associated windows in the foreground state are combined and displayed. This enables rapid switching of accounts on the in-vehicle screen, and after switching accounts, the associated windows of the original account are invisible, greatly reducing the risk of privacy leakage and improving data security. Furthermore, when there are multiple in-vehicle screens, both the first and second accounts have multiple sub-accounts to control different in-vehicle screens, flexibly customizing the multi-screen relationships and screen display content for the target user, meeting the personalized usage needs of users in multi-screen scenarios.

[0019] The above description is merely an overview of the technical solutions of this invention. In order to better understand the technical means of the embodiments of this invention, it can be implemented in accordance with the contents of the specification. Furthermore, in order to make the above and other objects, features and advantages of the embodiments of this invention more apparent and understandable, specific embodiments of this invention are described below. Attached Figure Description

[0020] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 A schematic flowchart of the vehicle thermal management method according to Embodiment 1 of the present invention is shown; Figure 2 A detailed schematic diagram of step 120 in Embodiment 1 of the present invention is shown; Figure 3 A detailed schematic diagram of step 130 in Embodiment 1 of the present invention is shown; Figure 4 This invention provides a schematic diagram of the vehicle thermal management device according to Embodiment 2. Figure 5 A schematic diagram of the vehicle infotainment system according to Embodiment 3 of the present invention is shown. Detailed Implementation

[0021] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be limited to the embodiments set forth herein.

[0022] Example 1: Figure 1 This invention illustrates a vehicle screen account management method applied to a vehicle infotainment system with a vehicle screen, to solve the problems of user switching and content display on multiple vehicle screens. The method includes: 110. Start the first account and switch the first account to the foreground state on the vehicle screen. In step 110, after starting the first account, determine whether the first account is being started for the first time. If so, create the first account and configure the account information. Otherwise, load the configuration signal of the first account and switch the first account to the foreground state on the vehicle screen according to the configuration signal.

[0023] Step 120 involves listening for account switching events and obtaining the second account. The first account is then switched to a background state, and the second account is started and switched to the foreground state on the vehicle screen. In step 120, when a user initiates an account switch, the system first retrieves the corresponding account configuration object based on the target second account, and then obtains all target users of the second account. All target users of the second account are then switched to the foreground state on the vehicle screen. This process completes the switching of parent users among the target users to the foreground state, and simultaneously switches all child users of those target users to the foreground state. After completing the account login or switch, a custom broadcast event notification is sent, and the broadcast includes the current account ID information.

[0024] 130. Based on the display status of the account to which the associated window on the vehicle screen belongs, composite all associated windows in the foreground state for display. In step 130, composite all associated windows in the foreground state for display based on the display status of the account to which the associated window on the vehicle screen belongs specifically includes: traversing all associated windows on the vehicle screen and determining whether the account to which the associated window belongs is in the foreground state. If so, the associated window is marked as visible; otherwise, the associated window is marked as invisible. Render and composite all visible associated windows and display them on the vehicle screen.

[0025] This invention, after activating the first account, listens for account switching events and acquires the second account. It then switches the first account to a background state, activates the second account, and switches it to the foreground state of the in-vehicle screen. Based on the display state of the accounts to which the associated windows of the in-vehicle screen belong, it synthesizes and displays all associated windows in the foreground state. This enables rapid switching of accounts on the in-vehicle screen, and after switching accounts, the original account's associated windows become invisible, significantly reducing the risk of privacy leaks and improving data security. Furthermore, when there are multiple in-vehicle screens, both the first and second accounts can be configured with multiple sub-accounts to control different in-vehicle screens, flexibly customizing the multi-screen relationships and screen display content for the target user, thus meeting the personalized usage needs of users in multi-screen scenarios.

[0026] In step 110, the first account is launched and switched to the foreground state on the in-vehicle screen. In a specific example, the first account can be account 1, associated with three target users: user 0, user 0-1, and user 0-2. User 0 is the parent user, and user 0-1 and user 0-2 are child users of user 0, meaning they will switch between foreground and background states following the parent user. Furthermore, the first account, account 1, is configured with three screens: the driver's side screen, the passenger side screen, and the rear screen. The driver's side screen is bound to user 0, the passenger side screen to user 0-1, and the rear screen to user 0-2. Similarly, the second account, account 2, also has relevant screen and user configuration definitions. Simultaneously, the parent user is launched to the foreground using the standard Android foreground launcher, and all its child users are also switched to the foreground state during the launch process.

[0027] After activating the first account, see Figure 2 It also includes determining whether the first account is being started for the first time through the following steps: determining whether the first account is being started for the first time; if so, creating the first account and configuring the account information; otherwise, loading the configuration signal of the first account and switching the first account to the foreground state on the vehicle screen according to the configuration signal.

[0028] In this embodiment, when starting an account, the configuration information of the target user associated with the currently started account is first retrieved. It is then determined whether the account is being started for the first time. If it is, the parent user configured for the account is created, all child users of the parent user are created, and the association relationships between the parent user and each child user are set. If the first account is not being started for the first time, all currently created target users in the system are retrieved, and the parent user and all its child users are found. The parent user corresponding to the account is started and switched to the system foreground running state, and all child users associated with the parent user are also simultaneously switched to the foreground state.

[0029] exist Figure 2 In the example shown, the creation of the first account and the configuration of account information specifically include: 210. Create a first account, wherein the first account has at least one target user, and each target user has a user ID; in step 210, when there is one in-vehicle screen, the first account has one target user, and the target user also has a user ID; when there are multiple in-vehicle screens, the first account has multiple target users, and each target user has a user ID. Specifically, when a user initiates account creation, it is done through the account creation application programming interface. First, the system obtains the corresponding account configuration object based on the account ID of the first account to be created, and then obtains the parent user and its corresponding child user list of the account.

[0030] 220. According to the account configuration policy, the target user's user ID is bound to the vehicle screen. Step 220, binding the target user's user ID to the vehicle screen according to the account configuration policy, specifically includes: loading the account configuration policy through the account configuration parsing function, parsing the user association under the first account through the parsing account and associated user interface, and saving it through a first hash mapping table; parsing the target user of the first account and the vehicle screen through the parsing account and vehicle screen interface, and saving it through a second hash mapping table; constructing an account configuration object to save the first hash mapping table and the second hash mapping table, and saving them as a third hash mapping table, thereby binding the target user's user ID to the vehicle screen.

[0031] In steps 210-220, the system account interface is called during system startup to initialize account-related configuration policies. The system account loads and parses the policy configuration file by calling the account configuration parsing function. The user association relationships under an account are resolved by calling the account and associated user parsing interface, and the results are displayed in a HashMap. <Integerparent, List<Integer child> This process involves saving the data and mapping it from parent user IDs to a list of child user IDs. By parsing the account and in-vehicle screen interface, the relationship between the relevant screen display under the account and the target user is resolved. After parsing, a first hash map (HashMap) is used as the mapping table.<Integer displayID, Integer userID> This process involves saving the data to map the vehicle screen's display ID to the target screen's user ID. Finally, an account configuration object is created and stored in a HashMap. <Integer parent, List<Integer child> > and the second hash map HashMap<Integer displayID, Integer userID> And other relevant information, and use a third hash map HashMap<Integer accountID, AccountConfig config> Record this information carefully, so that you can retrieve all configuration policy information for the corresponding account based on the account ID (accountID) later. When a user initiates account creation, it is done through the account creation application programming interface. The account creation process first retrieves the corresponding account configuration from the system based on the account ID to be created, and then obtains the parent user ID and its corresponding list of child user IDs for that account.

[0032] In some optional embodiments, when a target user runs an application on the in-vehicle screen, the user ID of the running file of the application is obtained through the context user acquisition interface, the in-vehicle screen ID corresponding to the target user is obtained through the second hash mapping table, and the target user's running application can be displayed on the corresponding in-vehicle screen by modifying the specified screen in the intent pointing function of the launcher. In this embodiment, when a user initiates the launch Activity behavior under a certain user space, the user ID corresponding to the context of the behavior can be obtained through the context user acquisition interface, and then the HashMap of the account can be used to...<Integer displayID, Integer userID> By recording information, we can obtain the display ID corresponding to the user. By modifying the intent function that launches the activity and setting the launch screen function to specify the target display, we can achieve the function of launching the Activity in the corresponding user space to the corresponding screen display.

[0033] In step 130, based on the display status of the associated window on the vehicle screen and the account to which it belongs, all associated windows in the foreground are combined and displayed. See [link to relevant documentation]. Figure 3 Specifically, it includes: 310. Traverse all associated windows of the vehicle screen and determine whether the account to which the associated window belongs is in the foreground state. If so, mark the associated window as visible; otherwise, mark the associated window as invisible. In step 310, all associated windows of the vehicle screen are traversed through the window traversal function. The window attributes of each associated window are obtained through the window update function, and the user ID is obtained through the window attributes. Based on the user ID, it is determined whether the account to which the associated window belongs is in the foreground state. If so, the associated window is marked as visible; otherwise, the associated window is marked as invisible.

[0034] 320. Render and composite all visible associated windows and display them on the vehicle screen. Step 320, rendering and compositing all visible associated windows and displaying them on the vehicle screen, specifically includes: submitting the visible associated windows to the display compositing system for rendering and merging via the WMS service's display processing application, and then displaying them on the vehicle screen.

[0035] Specifically, in steps 310-320, after receiving a system broadcast notification of a successful account switch, a display refresh process is initiated. Each vehicle screen initiates a window traversal function to process associated windows. The specified screen parameters in the window traversal function retrieve the window state of each associated window, and the user ID to which the associated window belongs is obtained through the window state-display user ID function. Then, the foreground / background state of the associated window is determined based on the current configuration file interface, and finally... The function to set the window state updates the visible / invisible state of the window. The Android Window Management Service (WMS) then sends a request to the display compositing system through the display processing application for subsequent compositing and display processes. Layers marked as invisible will not participate in compositing and will ultimately not be output and displayed on the screen, thus achieving the effect of display isolation for user spaces under different accounts.

[0036] This invention, after activating the first account, listens for account switching events and acquires the second account. It then switches the first account to a background state, activates the second account, and switches it to the foreground state on the vehicle screen. Based on the display state of the accounts to which the associated windows on the vehicle screen belong, it composites and displays all associated windows in the foreground state. This allows for rapid switching of accounts on the vehicle screen, and after switching accounts, the original account's associated windows become invisible, significantly reducing the risk of privacy leaks and improving data security.

[0037] Example 2: Figure 4 An embodiment of a screen account management device of the present invention is shown. The screen account management device 400 includes a first screen display module 410, an account switching module 420, and a second screen display module 430. Specifically, this device includes: The first screen display module 410 is used to execute step 110 in embodiment 1, specifically including: after starting the first account, determining whether the first account is being started for the first time; if so, creating the first account and configuring account information; otherwise, loading the configuration signal of the first account, and switching the first account to the foreground state on the vehicle screen according to the configuration signal.

[0038] The account switching module 420 is used to execute step 110 in embodiment 1, specifically including: when a user initiates an account switching, firstly, based on the second account to be switched, the system obtains the corresponding account configuration object, and further obtains all target users of the second account; and switches all target users of the second account to the foreground of the vehicle screen.

[0039] The second screen display module 430 is used to execute step 110 in embodiment 1, specifically including: according to the display status of the account to which the associated window of the vehicle screen belongs, to composite and display all associated windows in the foreground state, specifically including: traversing all associated windows of the vehicle screen and determining whether the account to which the associated window belongs is in the foreground state. If so, the associated window is marked as visible; otherwise, the associated window is marked as invisible. Render and composite all the associated windows in the visible state and display them on the vehicle screen.

[0040] This invention, after activating the first account, listens for account switching events and acquires the second account. It then switches the first account to a background state, activates the second account, and switches it to the foreground state of the in-vehicle screen. Based on the display state of the accounts to which the associated windows of the in-vehicle screen belong, it synthesizes and displays all associated windows in the foreground state. This enables rapid switching of accounts on the in-vehicle screen, and after switching accounts, the original account's associated windows become invisible, significantly reducing the risk of privacy leaks and improving data security. Furthermore, when there are multiple in-vehicle screens, both the first and second accounts can be configured with multiple sub-accounts to control different in-vehicle screens, flexibly customizing the multi-screen relationships and screen display content for the target user, thus meeting the personalized usage needs of users in multi-screen scenarios.

[0041] Example 3: Figure 5 The diagram shows a structural schematic of an embodiment of the vehicle infotainment system. The specific embodiments of the present invention do not limit the specific implementation of the vehicle infotainment system.

[0042] like Figure 5 As shown, the device for automatically generating PCB etching drawings may include: a processor 502, a communications interface 504, a memory 506, and a communication bus 508.

[0043] The processor 502, communication interface 504, and memory 506 communicate with each other via communication bus 508. Communication interface 504 is used to communicate with other network elements, such as clients or other servers. Processor 502 executes program 510, specifically performing the relevant steps described above in the vehicle thermal management method embodiment.

[0044] Specifically, program 510 may include program code, which includes computer-executable instructions.

[0045] Processor 502 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention. The vehicle infotainment system includes one or more processors, which may be of the same type, such as one or more CPUs; or they may be of different types, such as one or more CPUs and one or more ASICs.

[0046] Memory 506 is used to store program 510. Memory 506 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0047] Specifically, program 510 can be called by processor 502 to cause the vehicle system to execute steps 110-130 of embodiment 1.

[0048] The algorithms or displays provided herein are not inherently related to any particular computer, virtual system, or other device. Furthermore, the embodiments of this invention are not directed to any particular programming language.

[0049] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of the invention may be practiced without these specific details. Similarly, for the sake of brevity and to aid in understanding one or more aspects of the invention, in the description of exemplary embodiments of the invention above, various features of the embodiments are sometimes grouped together in a single embodiment, figure, or description thereof. The claims, which follow the detailed description, are hereby expressly incorporated into that detailed description, wherein each claim itself is a separate embodiment of the invention.

[0050] Those skilled in the art will understand that the modules in the device of the embodiment can be adaptively changed and placed in one or more devices different from that embodiment. Modules, units, or components in the embodiment can be combined into a single module, unit, or component, and further, they can be divided into multiple sub-modules, sub-units, or sub-components, except that at least some of such features and / or processes or units are mutually exclusive.

[0051] It should be noted that the above embodiments are illustrative of the invention and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names. The steps in the above embodiments, unless otherwise specified, should not be construed as limiting the order of execution.

Claims

1. A method for managing in-vehicle screen accounts, characterized in that, Applications include in-vehicle infotainment systems with in-vehicle screens, including: Activate the first account and switch it to the foreground mode on the vehicle screen; Listen for account switching events and obtain the second account. Switch the first account to the background state, start the second account, and switch the second account to the foreground state of the vehicle screen. Based on the display status of the account to which the associated window on the vehicle screen belongs, all associated windows in the foreground status are combined and displayed. When there are multiple in-vehicle screens, both the first account and the second account are set up with multiple target users to control different in-vehicle screens.

2. The in-vehicle screen account management method according to claim 1, characterized in that, After the first account is started, it is determined whether the first account is started for the first time. If so, the first account is created and the account information is configured; otherwise, the configuration signal of the first account is loaded and the first account is switched to the foreground state on the vehicle screen according to the configuration signal.

3. The in-vehicle screen account management method according to claim 2, characterized in that, The creation of the first account and configuration of account information specifically includes: Create a first account, wherein the first account has at least one target user, and each target user has a user ID; According to the account configuration policy, the user ID of the target user is bound to the in-vehicle screen.

4. The in-vehicle screen account management method according to claim 3, characterized in that, According to the account configuration policy, the user ID of the target user is bound to the in-vehicle screen, specifically including: The account configuration policy is loaded, the user associations under the first account are parsed, and the data is saved through the first hash mapping table; The target user of the first account and the in-vehicle screen are parsed and saved through the second hash mapping table; By constructing an account configuration object to store a first hash mapping table, a second hash mapping table, and a third hash mapping table, the user ID of the target user is bound to the in-vehicle screen.

5. The in-vehicle screen account management method according to claim 4, characterized in that, When a target user runs an application on the vehicle screen, the user ID of the application's executable file is used to obtain the vehicle screen ID corresponding to the target user through a second hash mapping table. By modifying the specified screen in the intent pointing function of the launcher, the application run by the target user can be displayed on the corresponding vehicle screen.

6. The in-vehicle screen account management method according to claim 1, characterized in that, Based on the display status of the account to which the associated window on the vehicle screen belongs, all associated windows in the foreground are combined and displayed, specifically including: Iterate through all associated windows of the vehicle screen and determine whether the account to which the associated window belongs is in the foreground. If so, mark the associated window as visible; otherwise, mark the associated window as invisible. All visible associated windows are rendered and composited, and then displayed on the vehicle screen.

7. The in-vehicle screen account management method according to claim 6, characterized in that, Iterate through all associated windows on the vehicle screen and determine whether the account to which the associated window belongs is in the foreground. If so, mark the associated window as visible; otherwise, mark the associated window as invisible. Specifically, this includes: Iterate through all associated windows on the vehicle screen; Get the window properties of each associated window, and then get the user ID through the window properties; Based on the user ID, determine whether the account to which the associated window belongs is in the foreground state. If so, mark the associated window as visible; otherwise, mark the associated window as invisible.

8. The in-vehicle screen account management method according to claim 7, characterized in that, The step of rendering and compositing all visible associated windows and displaying them on the vehicle screen specifically includes: The associated windows in the visible state are submitted to the display compositing system for rendering and merging, and then displayed on the in-vehicle screen.

9. A screen account management device, characterized in that, The device includes: The first screen display module is used to start the first account and switch the first account to the foreground state on the vehicle screen. When there are multiple vehicle screens, the first account is set with multiple target users to control different vehicle screens. The account switching module is used to listen for account switching events and obtain the second account, switch the first account to the background state, start the second account, and switch the second account to the foreground state of the vehicle screen. And a second screen display module, used to synthesize and display all foreground associated windows according to the display status of the account to which the associated window of the vehicle screen belongs. When there are multiple vehicle screens, the second account is set with multiple target users to control different vehicle screens.

10. A vehicle infotainment system, characterized in that, include: The processor, memory, communication interface, and communication bus are provided, wherein the processor, memory, and communication interface communicate with each other via the communication bus. The memory is used to store at least one executable instruction that causes the processor to perform the operation of the in-vehicle screen account management method as described in any one of claims 1-8.

Images