A vehicle-machine multi-user multi-screen adaptation method and system

Abstract

This application discloses a method and system for multi-user, multi-screen adaptation of in-vehicle infotainment systems, relating to the field of in-vehicle infotainment system development. The method includes: Step S1, when the in-vehicle infotainment system starts, reading the EOL configuration file stored in an independent partition and parsing it to obtain the number of screens and screen type information for the current vehicle model; Step S2, based on the parsed screen information, creating an independent profile user for each non-driver's screen to achieve user data isolation between different screens; Step S3, binding the created profile user to the corresponding screen, so that applications under the user can only be displayed on the corresponding screen; Step S4, installing corresponding applications for different profile users according to preset application installation configurations.

Description

Technical Field

[0001] This application relates to the field of vehicle infotainment system development, and in particular to vehicle infotainment multi-user multi-screen adaptation methods, vehicle infotainment multi-user multi-screen adaptation systems, electronic devices, storage media, and vehicle infotainment program development platforms. Background Technology

[0002] In the field of in-vehicle infotainment system development, different vehicle models and product forms are often equipped with varying numbers of in-vehicle screens. To ensure user data security and privacy, the industry generally adopts a multi-screen, multi-user mechanism where one screen corresponds to one user, ensuring that data on different screens is independent and does not interfere with each other. This makes multi-user, multi-screen management capability a core requirement for in-vehicle infotainment systems.

[0003] Traditional development models typically involve customizing a single set of code for a single product, resulting in poor adaptability, low reusability, and difficulty in quickly meeting the differentiated needs of multiple products and screens.

[0004] Therefore, a multi-user, multi-screen adaptation strategy for in-vehicle infotainment systems is needed. By configuring the EOL parameter, the dynamic creation and management of multiple users and multiple screens can be achieved without rewriting the core code for different products. The number of screens and user isolation strategies can be flexibly adapted according to the actual hardware configuration and product definition, which can greatly improve the universality, scalability and development efficiency of the in-vehicle infotainment system and effectively reduce the cost and cycle of parallel development of multiple projects. Summary of the Invention

[0005] The purpose of this invention is to provide a method, system, electronic device, storage medium, and vehicle infotainment system for multi-user and multi-screen adaptation of vehicle infotainment systems, and to solve at least one of several technical problems.

[0006] Core technical issues: Inability to adapt to different numbers of screens, difficulty in universally implementing data isolation for multiple screens and multiple users, poor reusability, high development costs, and long development cycles.

[0007] This invention provides the following solution:

[0008] According to a first aspect of the present invention, a method for multi-user, multi-screen adaptation of an in-vehicle infotainment system is provided, based on an end-of-life (EOL) configuration, specifically including:

[0009] When the vehicle system starts up, it reads the EOL configuration file stored in a separate partition and parses it to obtain the number of screens and screen type information of the current vehicle model;

[0010] Based on the parsed screen information, create an independent profile user for each non-driver screen to achieve user data isolation between different screens;

[0011] The created profile user is bound to the corresponding screen, so that the application under the user can only be displayed on the corresponding screen;

[0012] Based on the preset application installation configuration, install the corresponding applications for different user profiles.

[0013] Furthermore, the screen configuration information in the EOL configuration file includes: screen type;

[0014] The screen type includes at least one of the following: instrument panel screen, central control screen, passenger screen, panoramic sunroof screen, left rear side screen, right rear side screen, center armrest screen, and rear armrest screen; the screen type is identified by a 12-bit binary string.

[0015] Each digit of the string corresponds to a preset screen type.

[0016] Furthermore, this includes: after parsing the EOL configuration file, converting the parsed screen information into the system property ro.devoption.displayconfig, and storing it in the vehicle's infotainment system.

[0017] Furthermore, this includes adjusting the maximum number of profile users in the system based on the number of screens before creating users, and setting the system property persist.sys.max_profiles to support the creation of the corresponding number of independent users.

[0018] Furthermore, this includes: creating profile users; wherein, profile users are created sequentially according to the preset order of the screens; and the preset order is incremented, with different screen types corresponding to different profile user IDs.

[0019] Furthermore, this includes: achieving user-screen binding through a two-level mapping: first, mapping the corresponding occupantzoneID based on the screen type, then mapping the corresponding displayport based on the occupantzoneID, and finally binding the user to the displayport to achieve user-screen binding.

[0020] Furthermore, this includes: installing corresponding applications for different user profiles based on preset application installation configurations: applications that need to be installed for all user profiles based on the faw identifier; applications that need to be installed for the corresponding user profile based on the other identifiers; and applications that are not in the configuration file are installed according to the system's native mechanism.

[0021] Furthermore, this includes: when the vehicle system restarts, automatically launching all created profile users and rebinding them to the corresponding screens according to preset binding rules.

[0022] According to a second aspect of the present invention, a vehicle-mounted multi-user, multi-screen adaptation system is provided, based on an EOL (End of Service) configuration, comprising:

[0023] The EOL configuration storage module is used to store EOL configuration files that are independent of the core system image. The EOL configuration files include the screen configuration information of the current vehicle model.

[0024] The configuration parsing module connects to the EOL configuration storage module and is used to read and parse the EOL configuration file when the system starts up to obtain the number and type of screens for the current vehicle model.

[0025] The user creation module connects to the configuration parsing module. Based on the parsed screen information, it creates an independent profile user for each non-driver screen, thereby achieving user data isolation between different screens.

[0026] The user screen binding module connects to the user creation module and is used to bind the created profile user to the corresponding screen, so that the application under the user can only be displayed on the corresponding screen.

[0027] The application installation module connects to the user creation module and is used to install corresponding applications for different user profiles based on preset application installation configurations.

[0028] Furthermore, the screen configuration information in the EOL configuration file is identified by a 12-bit binary string, with each bit corresponding to a preset screen type. The screen types include at least one of the following: instrument panel screen, central control screen, passenger screen, panoramic sunroof screen, left rear side screen, right rear side screen, central armrest screen, and rear armrest screen.

[0029] Furthermore, the configuration parsing module is also used to convert the parsed screen information into the system property ro.devoption.displayconfig and store it in the system.

[0030] Furthermore, the user creation module is also used to adjust the maximum number of profile users in the system based on the number of screens, and to set the system property persist.sys.max_profiles to support the creation of the corresponding number of independent users.

[0031] Furthermore, the user creation module creates profile users sequentially according to the preset order of the screens, with user IDs incrementing in a preset order, and different screen types corresponding to different user IDs.

[0032] Furthermore, the user screen binding module achieves user-screen binding through a two-level mapping: first, based on the screen type, the corresponding occupantzoneID is mapped, and then based on the occupantzoneID, the corresponding displayport is mapped, thus binding the user to the displayport.

[0033] Furthermore, the application installation module is also configured with an application installation configuration file. In the configuration file, the "faw" identifier indicates the applications that all users in all profiles need to install, while the others are the applications that the corresponding user profiles need to install exclusively. Applications not in the configuration file are installed according to the system's native mechanism.

[0034] Furthermore, upon system restart, all created profile users are automatically launched, and users are re-bound to their corresponding screens according to preset binding rules.

[0035] According to a third aspect of the present invention, an electronic device is provided, comprising: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other via the communication bus;

[0036] The memory stores a computer program, which, when executed by the processor, causes the processor to perform steps such as the multi-user, multi-screen adaptation method for in-vehicle systems.

[0037] According to a fourth aspect of the present invention, a computer-readable storage medium is provided, comprising: storing a computer program executable by an electronic device, wherein when the computer program is run on the electronic device, the electronic device causes the electronic device to perform steps such as a vehicle-mounted multi-user multi-screen adaptation method.

[0038] According to a fifth aspect of the present invention, a vehicle infotainment system development platform is provided, comprising:

[0039] Electronic devices, used to implement steps for methods such as multi-user, multi-screen adaptation of in-vehicle systems;

[0040] The processor runs programs, and when the programs are running, they execute steps such as the multi-user, multi-screen adaptation method for vehicle systems based on data output from electronic devices.

[0041] Storage medium used to store programs that, when running, perform steps such as multi-user, multi-screen adaptation methods for in-vehicle systems based on data output from electronic devices.

[0042] The above solution achieves the following beneficial technical effects:

[0043] This application solves the technical problem of inconsistent identification of screen configuration information and inability to flexibly adapt to multiple screen types in traditional vehicle infotainment systems by using a 12-bit binary string to identify screen configuration information in the EOL configuration file, with each bit corresponding to a preset screen type. It achieves unified identification of 8 different screen types, supports flexible configuration of screen combinations for different vehicle models, and greatly improves the technical effect of configuration compatibility and scalability.

[0044] This application solves the technical problem that traditional vehicle infotainment screen configuration information cannot be read globally by the system and that various modules cannot uniformly obtain hardware configuration by converting the parsed screen information into the system attribute ro.devoption.displayconfig and storing it in the system. It realizes the global sharing of screen configuration information, allowing various modules of the system to uniformly obtain the hardware configuration of the current vehicle model, thus ensuring the technical effect of configuration consistency.

[0045] This application solves the technical problem that the fixed maximum number of users in the native system cannot adapt to different screen counts of different vehicle models and cannot support the creation of a corresponding number of independent users by dynamically adjusting the maximum number of profile users of the system according to the number of screens and setting the system property persist.sys.max_profiles. It realizes the dynamic adaptation of the system user capacity and can automatically adjust the maximum number of supported users according to the number of screens of the current vehicle model, thus meeting the multi-user needs of different vehicle models.

[0046] This application solves the technical problem of traditional in-vehicle systems lacking unified rules for user creation and having a chaotic correspondence between user IDs and screens across different vehicle models by creating profile users sequentially according to a preset screen order and assigning different user IDs to different screen types. It achieves a standardized correspondence between user IDs and screen types, ensuring a consistent correspondence between users and screens across different vehicle models and improving the maintainability of the system.

[0047] This application achieves user-screen binding through a two-level mapping mechanism. First, it maps the corresponding occupantzoneID based on the screen type, and then maps the corresponding display port based on the occupantzoneID. This binds the user to the display port, solving the technical problem of poor adaptability and incompatibility with different hardware port configurations in traditional in-vehicle infotainment systems where users are directly bound to the screen. This achieves indirect binding between the user and the screen, is compatible with different hardware port configurations, and significantly improves the system's adaptability to different hardware solutions.

[0048] This application achieves differentiated application installation through a preset application installation configuration file. The `faw` option is marked as the application that all users in the same profile need to install, while the others are marked as applications exclusive to their respective users. Applications not in the configuration are handled by the native mechanism. This solves the technical problem that the native Android mechanism cannot install differentiated applications for users with different profiles and cannot meet the functional requirements of different screens. It realizes differentiated application installation for users with different screens, and can flexibly configure exclusive applications for different screens, thus meeting the technical effect of meeting the differentiated functional requirements of different passengers.

[0049] This application solves the technical problem of losing the binding relationship between multiple users and the screen after a traditional vehicle system restarts by automatically starting all created profile users when the system restarts and rebinding the users to the corresponding screens according to preset binding rules. This achieves the technical effect of automatic recovery of multi-user configuration after restart, without requiring manual reconfiguration by users, thus ensuring the persistence of system configuration and the consistency of user experience. Attached Figure Description

[0050] Figure 1 This is a flowchart of a vehicle-mounted multi-user, multi-screen adaptation method provided by one or more embodiments of the present invention.

[0051] Figure 2 This is a structural diagram of a vehicle-mounted multi-user, multi-screen adaptation system provided in one or more embodiments of the present invention.

[0052] Figure 3 This is a schematic diagram of a vehicle-mounted multi-user, multi-screen adaptation process provided in a specific embodiment of the present invention.

[0053] Figure 4 This is a schematic diagram of the installation APK package name provided in a specific embodiment of the present invention.

[0054] Figure 5 This is a schematic diagram illustrating the number of profiler users supported by a configuration system provided in a specific embodiment of the present invention.

[0055] Figure 6 This is a schematic diagram illustrating the correspondence between port and screen information provided in a specific embodiment of the present invention.

[0056] Figure 7 This is a block diagram of an electronic device structure for a vehicle-mounted multi-user, multi-screen adaptation method provided in one or more embodiments of the present invention. Detailed Implementation

[0057] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0058] Figure 1 This is a flowchart of a vehicle-mounted multi-user, multi-screen adaptation method provided by one or more embodiments of the present invention.

[0059] like Figure 1 The in-vehicle infotainment system multi-user, multi-screen adaptation method shown is based on the EOL (End of Service) configuration and specifically includes:

[0060] Step S1: When the vehicle system starts, it reads the EOL configuration file stored in an independent partition and parses it to obtain the number of screens and screen type information of the current vehicle model.

[0061] Step S2: Based on the parsed screen information, create an independent profile user for each non-driver screen to achieve user data isolation between different screens;

[0062] Step S3: Bind the created profile user to the corresponding screen so that the applications under the user can only be displayed on the corresponding screen;

[0063] Step S4: Install the corresponding applications for different user profiles according to the preset application installation configuration.

[0064] In this embodiment, the screen configuration information in the EOL configuration file includes: screen type;

[0065] The screen type includes at least one of the following: instrument panel screen, central control screen, passenger screen, panoramic sunroof screen, left rear side screen, right rear side screen, center armrest screen, and rear armrest screen;

[0066] The screen type is identified by a 12-bit binary string; each bit of the string corresponds to a preset screen type.

[0067] In this embodiment, the process includes: after parsing the EOL configuration file, converting the parsed screen information into the system property ro.devoption.displayconfig, and storing it in the vehicle system.

[0068] In this embodiment, the following steps are included: before creating a user, adjusting the maximum number of profile users in the system based on the number of screens, and setting the system property persist.sys.max_profiles to support the creation of the corresponding number of independent users.

[0069] In this embodiment, the process includes: creating profile users; wherein profile users are created sequentially according to a preset screen order; the preset order is incremented, and different screen types correspond to different profile user IDs.

[0070] In this embodiment, the binding of the user and the screen is achieved through a two-level mapping: first, the corresponding occupantzoneID is mapped according to the screen type, then the corresponding displayport is mapped according to the occupantzoneID, and finally the user and the displayport are bound together to achieve the binding of the user and the screen.

[0071] In this embodiment, the following steps are included: installing corresponding applications for different profile users according to preset application installation configurations; and installing applications for all profile users based on the faw identifier.

[0072] The remaining applications are those that need to be installed exclusively for the corresponding user profile; applications not listed in the configuration file will be installed according to the system's native mechanism.

[0073] In this embodiment, the following steps are included: when the vehicle system restarts, all created profile users are automatically started, and the users are re-bound to the corresponding screens according to preset binding rules.

[0074] Specifically, this application also includes: before parsing the 12-bit binary string, validating the format of the binary string; if the string length is not equal to 12 bits, or contains non-0 / 1 characters, it is determined to be a configuration error, and the default screen configuration information is loaded.

[0075] When parsing a 12-bit binary string, the following measures are also included: when ignoring the reserved high 4 bits, only the low 8 bits of the defined screen type identifier are processed to avoid system errors caused by unknown screen types.

[0076] After converting screen information into system property storage, the process also includes setting the system property ro.devoption.displayconfig to read-only, preventing ordinary user processes from modifying it and preventing hardware configuration from being tampered with.

[0077] Before adjusting the maximum number of profile users in the system, the following steps are also taken: verify whether the number of screens exceeds the system's preset maximum number of users. If it does, the maximum number of users is truncated to the system's maximum value, and a configuration exception log is recorded.

[0078] Before creating a profile user, the process also includes: checking if the user ID to be created already exists. If there is a residual old user, the old user is deleted first, and then a new profile user is created to avoid user creation failure.

[0079] Before binding a user to a screen, the process also includes: verifying whether the mapped display port exists in the current hardware system. If it does not exist, the creation of the user corresponding to that screen is skipped to avoid invalid binding operations causing system errors.

[0080] The two-level mapping process also includes: verifying whether the occupantzoneID corresponding to the screen type exists. If it does not exist, the user creation for the corresponding screen is skipped, and the mapping process is terminated.

[0081] Before parsing the application installation configuration file, the process also includes: verifying the integrity of the configuration file. If the configuration file is corrupted or parsing fails, the process falls back to the system's native installation mechanism, ensuring that all applications are installed according to the native rules and guaranteeing normal system startup.

[0082] When installing applications for users with different profiles, the following measures are also included: if the application installation for a single user fails, only the installation error log for that user will be recorded, without interrupting the application installation process for other users, thus avoiding the impact of a single exception on the overall process.

[0083] When a public application identified by faw is updated, it also includes: automatically synchronizing and updating the application under all users of all profiles to ensure that the application version is consistent across all users.

[0084] Before the vehicle system restarts and restores the binding, it also includes: rereading the EOL configuration file, comparing the current screen configuration with the historical configuration, and if they are inconsistent, re-executing the user creation and binding process, rather than directly restoring the old binding relationship.

[0085] When the vehicle system restarts, it also includes: checking if there is a profile user that was manually deleted by the user. If so, the user will not be automatically created, and the user's manually modified configuration will be retained.

[0086] Figure 2 This is a structural diagram of a vehicle-mounted multi-user, multi-screen adaptation system provided in one or more embodiments of the present invention.

[0087] like Figure 2 The in-vehicle multi-user, multi-screen adaptation system shown is based on EOL configuration and includes:

[0088] The EOL configuration storage module is used to store EOL configuration files that are independent of the core system image. The EOL configuration files include the screen configuration information of the current vehicle model.

[0089] The configuration parsing module connects to the EOL configuration storage module and is used to read and parse the EOL configuration file when the system starts up to obtain the number and type of screens for the current vehicle model.

[0090] The user creation module connects to the configuration parsing module. Based on the parsed screen information, it creates an independent profile user for each non-driver screen, thereby achieving user data isolation between different screens.

[0091] The user screen binding module connects to the user creation module and is used to bind the created profile user to the corresponding screen, so that the application under the user can only be displayed on the corresponding screen.

[0092] The application installation module connects to the user creation module and is used to install corresponding applications for different user profiles based on preset application installation configurations.

[0093] In this embodiment, the screen configuration information in the EOL configuration file is identified by a 12-bit binary string, with each bit corresponding to a preset screen type. The screen types include at least one of the following: instrument panel screen, central control screen, passenger screen, panoramic screen, left rear side screen, right rear side screen, central armrest screen, and rear armrest screen.

[0094] In this embodiment, the configuration parsing module is also used to convert the parsed screen information into the system property ro.devoption.displayconfig and store it in the system.

[0095] In this embodiment, the user creation module is also used to adjust the maximum number of profile users in the system according to the number of screens, and set the system property persist.sys.max_profiles to support the creation of the corresponding number of independent users.

[0096] In this embodiment, the user creation module creates profile users sequentially according to the preset order of the screens. The user IDs increment in the preset order, and different screen types correspond to different user IDs.

[0097] In this embodiment, the user screen binding module achieves the binding of the user and the screen through a two-level mapping: first, according to the screen type, the corresponding occupantzoneID is mapped to obtain the corresponding display port, and then according to the occupantzoneID, the corresponding display port is mapped to obtain the corresponding display port, and the user is bound to the display port.

[0098] In this embodiment, the application installation module is also configured with an application installation configuration file. In the configuration file, the "faw" identifier indicates the applications that all profile users need to install, and the other identifiers indicate the applications that the corresponding profile users need to install. Applications not in the configuration file are installed according to the system's native mechanism.

[0099] In this embodiment, when the system restarts, all created profile users are automatically started, and users are re-bound to the corresponding screens according to preset binding rules.

[0100] It is worth noting that although this system / device only discloses the above-mentioned modules / units, it does not mean that this system / device is limited to the above-mentioned basic functional modules. On the contrary, what this invention intends to express is that, based on the above-mentioned basic functional modules, those skilled in the art can add one or more functional modules in combination with the prior art to form an infinite number of embodiments or technical solutions. That is to say, this system is open rather than closed. It cannot be assumed that the scope of protection of the claims of this invention is limited to the above-disclosed basic functional modules just because this embodiment only discloses a few basic functional modules.

[0101] In one specific embodiment, a strategy for multi-user, multi-screen adaptation of in-vehicle systems through EOL configuration is disclosed. By dynamically creating multiple users and multiple screens, no custom development is required, a single codebase can be adapted to multiple products, screen and user data are securely isolated, the system's scalability and reusability are improved, and the development cost and cycle are reduced.

[0102] The modules involved in this embodiment include framework, carservice, and EOL (partition) modules;

[0103] The design principles in this embodiment include:

[0104] 1. The multi-screen multi-user mentioned here mainly refers to non-driver screens, that is, creating corresponding users for other screens and binding them to the corresponding screens.

[0105] 2. First, the basic EOL configuration file is stored in a separate image partition. Different EOL images are flashed for different needs. When the system starts, it first parses the EOL configuration file and reads the screen information that needs to be configured, including the number and type of screens.

[0106] 3. Then, based on this information, create multiple users and install the corresponding apps for each user.

[0107] The specific details are divided into the following parts (such as...) Figure 3 (as shown)

[0108] 1. When the system starts, it reads the EOL configuration and converts the information into a property with the key ro.devoption.displayconfig; the value is a string consisting of 12 digits (0s and 1s). For example: "011000000000". Here, we only need to focus on the screen where users need to be created.

[0109] The screen type is defined as follows:

[0110] / / meter

[0111] private static final int OPPOSITE_DISPLAY = 1 << 11;

[0112] / / Central Control

[0113] private static final int OPPOSITE_DISPLAY = 1 << 10;

[0114] / / Passenger seat

[0115] private static final int OPPOSITE_DISPLAY = 1 << 9;

[0116] / / Sky Screen

[0117] private static final int OVERHEAD_DISPLAY = 1 << 8;

[0118] / / Left rear side screen

[0119] private static final int REAR_LEFT_DISPLAY = 1 << 7;

[0120] / / Right rear screen

[0121] private static final int REAR_RIGHT_DISPLAY = 1 << 6;

[0122] / / Central armrest screen

[0123] private static final int ARMRESET_CENTER_DISPLAY = 1 << 5;

[0124] / / Rear armrest screen

[0125] private static final int ARMRESET_REAR_DISPLAY = 1 << 4;

[0126] The remaining items are reserved, undefined, and unused.

[0127] 2. During system startup, the app's multi-user installation configuration file is parsed (this configuration file is mainly used to differentiate installation strategies for different user profiles) and cached in the system. (e.g.) Figure 4 The userid =faw represents the name of the APK package to be installed for all profile users. The rest are the same as the name, corresponding to "11" and "12" respectively.

[0128] How it works: FAW refers to the apps that need to be monitored and differentiated. Apps not in this FAW list are left unchecked; the app will be processed using the native search mechanism, meaning it doesn't differentiate between user profiles (it installs all apps or none at all). Only apps in the FAW list will be differentiated.

[0129] 3. Parse the properties obtained in step 1 to identify the screens that require user creation, and store them in an array in a fixed order.

[0130] Finally, based on the array size, configure the maximum number of profiler users supported by the system, which is to set `persist.sys.max_profiles` (this property is supported by the system itself, such as...). Figure 5 (As shown), this attribute will be used when creating a user later.

[0131] 4. Create corresponding user profiles based on screen information. For convenience, use a sequential mapping to correspond to users.

[0132] That is, from left to right, user10, user11, 12... are created respectively. In this way, the correspondence is shifted forward according to the number of screens. For example, if there is an OVERHEAD_DISPLAY screen, then it is user11. If there is also an OPPOSITE_DISPLAY screen, then it is user11. If there is an OVERHEAD_DISPLAY screen, then it is user12.

[0133] After a user is successfully created, it will be launched. When the user is launched, it will be bound to a specific screen (by mapping a fixed display port through the parsed screen information, and binding the user to the port, since the underlying information is display port information). The purpose is to ensure that the app under the user can only be displayed on the screen corresponding to the user.

[0134] The mapping between port and screen information is as follows: Each screen type has a corresponding XML file, which establishes the mapping between screen type and port. This is a two-level mapping: first, the screen type finds the occupantzoneid; then, based on the occupantzoneid, the corresponding displayport is found. Figure 6 The two sections highlighted in green)

[0135] 4. App installation: The system itself supports profile users.

[0136] When creating a profile user, the system installs the necessary apps for each profile user based on the configuration file. The native mechanism uses a single configuration file for each profile user, making it impossible to install different apps for multiple profile users. (See step 2 for details).

[0137] Upon restarting, simply launch all the created profile users and bind them to the corresponding screens according to the rules.

[0138] In this embodiment, different projects may have different numbers of screens. The number of screens for each project device is fixed and cannot be changed after flashing. This embodiment creates different user information for different fixed screen information, thereby achieving the purpose of dynamically adapting to different projects.

[0139] Figure 7 This is a block diagram of an electronic device structure for a vehicle-mounted multi-user, multi-screen adaptation method provided in one or more embodiments of the present invention.

[0140] like Figure 7 As shown, this application provides an electronic device, including: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0141] The memory stores a computer program, which, when executed by the processor, causes the processor to perform steps of a vehicle-mounted multi-user, multi-screen adaptation method.

[0142] This application also provides a computer-readable storage medium storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of the vehicle-mounted multi-user multi-screen adaptation method.

[0143] This application also provides a vehicle infotainment system application development platform, including:

[0144] Electronic devices, steps for implementing a multi-user, multi-screen adaptation method for vehicle infotainment systems;

[0145] The processor runs a program, and when the program runs, it executes the steps of the vehicle system multi-user multi-screen adaptation method based on the data output from the electronic device.

[0146] Storage medium for storing programs that, when running, execute steps of the vehicle-mounted multi-user, multi-screen adaptation method based on data output from electronic devices.

[0147] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not indicate that there is only one bus or one type of bus.

[0148] The electronic device comprises a hardware layer, an operating system layer running on top of the hardware layer, and an application layer running on the operating system. The hardware layer includes hardware such as a central processing unit (CPU), a memory management unit (MMU), and memory. The operating system can be any one or more computer operating systems that control the electronic device through processes, such as Linux, Unix, Android, iOS, or Windows. Furthermore, in this embodiment of the invention, the electronic device can be a smartphone, tablet computer, or other handheld device, or a desktop computer, portable computer, or other electronic device; there is no particular limitation in this embodiment.

[0149] In this embodiment of the invention, the executing entity for electronic device control can be an electronic device itself, or a functional module within an electronic device capable of calling and executing a program. The electronic device can obtain the firmware corresponding to the storage medium. This firmware is provided by the supplier, and different storage media may have the same or different firmware; no limitation is made here. After obtaining the firmware corresponding to the storage medium, the electronic device can write this firmware into the storage medium; specifically, it burns the firmware corresponding to the storage medium into the storage medium. The process of burning the firmware into the storage medium can be implemented using existing technology, and will not be elaborated upon in this embodiment of the invention.

[0150] Electronic devices can also obtain reset commands corresponding to the storage media. The reset commands corresponding to the storage media are provided by the supplier. The reset commands corresponding to different storage media can be the same or different, and no restrictions are imposed here.

[0151] At this time, the storage medium of the electronic device is a storage medium on which the corresponding firmware has been written. The electronic device can respond to the reset command corresponding to the storage medium on which the corresponding firmware has been written, thereby resetting the storage medium on which the corresponding firmware has been written according to the reset command. The process of resetting the storage medium according to the reset command can be implemented by existing technology and will not be described in detail in this embodiment of the invention.

[0152] For ease of description, the above devices are described separately by function as various units and modules. Of course, in implementing this application, the functions of each unit and module can be implemented in one or more software and / or hardware.

[0153] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the meaning consistent with their meaning in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined.

[0154] For the sake of simplicity, the method embodiments are described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0155] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0156] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for multi-user, multi-screen adaptation of in-vehicle infotainment systems, characterized in that, The in-vehicle infotainment multi-user, multi-screen adaptation method, based on EOL (End of Service) configuration, specifically includes: When the vehicle system starts up, it reads the EOL configuration file stored in a separate partition and parses it to obtain the number of screens and screen type information of the current vehicle model; Based on the parsed screen information, create an independent profile user for each non-driver screen to achieve user data isolation between different screens; The created profile user is bound to the corresponding screen, so that the application under the user can only be displayed on the corresponding screen; Based on the preset application installation configuration, install the corresponding applications for different user profiles.

2. The in-vehicle multi-user multi-screen adaptation method according to claim 1, characterized in that, The screen configuration information in the EOL configuration file includes: screen type; The screen type includes at least one of the following: instrument panel screen, central control screen, passenger screen, panoramic sunroof screen, left rear side screen, right rear side screen, central armrest screen, and rear armrest screen.

3. The in-vehicle multi-user multi-screen adaptation method according to claim 1, characterized in that, include: After parsing the EOL configuration file, the obtained screen information is converted into the system property ro.devoption.displayconfig and stored in the vehicle's infotainment system.

4. The in-vehicle multi-user multi-screen adaptation method according to claim 1, characterized in that, include: Before creating users, adjust the maximum number of profile users in the system based on the number of screens by setting the system property persist.sys.max_profiles.

5. The in-vehicle multi-user multi-screen adaptation method according to claim 1, characterized in that, include: Create a profile user; In this process, profile users are created sequentially according to the preset order on the screen; The user IDs are incremented in a preset order, with different screen types corresponding to different profile user IDs.

6. The in-vehicle multi-user multi-screen adaptation method according to claim 1, characterized in that, include: This is achieved through a two-level mapping system, which binds the user to the screen. First, based on the screen type, the corresponding occupantzoneID is mapped to obtain the corresponding displayport. Then, based on the occupantzoneID, the corresponding displayport is mapped to obtain the corresponding displayport. Finally, the user is bound to the displayport to achieve the binding of the user and the screen. It also includes: installing corresponding applications for different profile users according to preset application installation configurations; and installing applications for all profile users based on the faw identifier. The remaining applications are those that need to be installed exclusively for the corresponding user profile.

7. A vehicle infotainment system for multiple users and multiple screens, based on end-of-life (EOL) configuration, characterized in that: include: The EOL configuration storage module is used to store EOL configuration files that are independent of the core system image. The EOL configuration files include the screen configuration information of the current vehicle model. The configuration parsing module is connected to the EOL configuration storage module and is used to read and parse the EOL configuration file when the system starts up to obtain the number of screens and screen type information of the current vehicle model. The user creation module, connected to the configuration parsing module, is used to create an independent profile user for each non-driver screen based on the parsed screen information, thereby achieving user data isolation between different screens. The user screen binding module, connected to the user creation module, is used to bind the created profile user to the corresponding screen, so that the application under the user can only be displayed on the corresponding screen; The application installation module, connected to the user creation module, is used to install corresponding applications for different user profiles according to preset application installation configurations.

8. An electronic device, characterized in that, include: The processor, communication interface, memory, and communication bus are connected, with the processor, communication interface, and memory communicating with each other via the communication bus. The memory stores a computer program that, when executed by a processor, causes the processor to perform the steps of the in-vehicle multi-user multi-screen adaptation method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, include: The device stores a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of the vehicle-mounted multi-user multi-screen adaptation method as described in any one of claims 1 to 6.

10. A vehicle infotainment system program development platform, characterized in that, include: An electronic device for implementing the steps of the in-vehicle multi-user multi-screen adaptation method as described in any one of claims 1 to 6; The processor runs a program, and when the program runs, it executes the steps of the in-vehicle multi-user multi-screen adaptation method as described in any one of claims 1 to 6 from the data output by the electronic device. A storage medium for storing a program that, when running, performs the steps of the vehicle-mounted multi-user multi-screen adaptation method as described in any one of claims 1 to 6 on data output from an electronic device.

Images