Rendering methods and systems for vehicles and in-vehicle desktops

Abstract

This application provides a rendering method and system for a vehicle and an in-vehicle desktop. The method includes: in response to receiving a desktop switching instruction, acquiring the current shared data of the current in-vehicle desktop, wherein the desktop switching instruction indicates switching the current in-vehicle desktop to a target in-vehicle desktop; synchronizing the initial in-vehicle data corresponding to the target in-vehicle desktop based on the scene identifier corresponding to the desktop switching instruction, wherein the initial in-vehicle data includes initial private data and initial shared data; and rendering the target in-vehicle desktop based on the current shared data, the initial private data, and the initial shared data. This application solves the technical problem of poor security in the data management of multiple in-vehicle desktops in related technologies.

Description

Technical Field

[0001] This application relates to the fields of vehicles and rendering, and more specifically, to a rendering method and system for vehicles and in-vehicle desktops. Background Technology

[0002] With the evolution of smart cockpit technology, in-vehicle systems are gradually supporting the parallel operation of multiple launchers to simultaneously meet the diverse needs of scenarios such as driving navigation and in-vehicle entertainment.

[0003] However, current multi-desktop data management solutions mainly adopt a global interconnection mode, where different in-vehicle desktops share the same data directory. This can lead to the caching, account information, and pop-up configurations of parking entertainment applications being carried into the driving scenario, causing entertainment interference during driving and resulting in the failure of data security control.

[0004] There is currently no good solution to the above problems. Summary of the Invention

[0005] This application provides a rendering method and system for vehicles and in-vehicle desktops, in order to at least solve the technical problem of poor security in the data management of multiple in-vehicle desktops in related technologies.

[0006] According to one aspect of this application, a method for rendering an in-vehicle desktop is provided, comprising: in response to receiving a desktop switching instruction, obtaining current shared data of the current in-vehicle desktop, wherein the desktop switching instruction is used to indicate switching the current in-vehicle desktop to a target in-vehicle desktop; synchronizing initial in-vehicle data corresponding to the target in-vehicle desktop based on a scene identifier corresponding to the desktop switching instruction, wherein the initial in-vehicle data includes initial private data and initial shared data; and rendering the target in-vehicle desktop based on the current shared data, the initial private data, and the initial shared data.

[0007] Optionally, the target in-vehicle desktop is rendered based on the current shared data, the initial private data, and the initial shared data, including: comparing the current shared data and the initial shared data to obtain the difference data; constructing the target shared data based on the difference data; and rendering the target in-vehicle desktop based on the target shared data and the initial private data.

[0008] Optionally, the current shared data and the initial shared data are compared to obtain the difference data, including: dividing the current shared data into multiple first key-value pairs and dividing the initial shared data into multiple second key-value pairs; comparing each first key-value pair and each second key-value pair separately to obtain at least one pair of difference key-value pairs, wherein the fields of the first key-value pairs in a pair of difference key-value pairs are consistent with the fields of the second key-value pairs in a pair of difference key-value pairs; arbitrating the at least one pair of difference key-value pairs to obtain the target key-value pairs; and constructing the difference data based on the target key-value pairs.

[0009] Optionally, arbitrating at least one pair of differing key-value pairs to obtain a target key-value pair includes: determining the target key-value pair based on the timestamps of at least one pair of differing key-value pairs, wherein the timestamp of the target key-value pair is later than the timestamps of other key-value pairs; or, determining the target key-value pair based on the version numbers of at least one pair of differing key-value pairs, wherein the version number of the target key-value pair is greater than the version numbers of other key-value pairs; or, determining the target key-value pair based on the configuration attributes of at least one pair of differing key-value pairs, wherein the priority order corresponding to the configuration attributes of the target key-value pair is higher than the priority order corresponding to the configuration attributes of other key-value pairs.

[0010] Optionally, before obtaining the current shared data of the current in-vehicle desktop, the above method may also include: freezing the current private data of the current in-vehicle desktop.

[0011] Optionally, after rendering the target vehicle desktop based on the current shared data, initial private data, and initial shared data, the above method further includes: detecting the rendering status of the target vehicle desktop, wherein the rendering status is used to indicate whether the target vehicle desktop has been rendered; and clearing the cached data generated during the switching of the vehicle desktop if the rendering status indicates that the target vehicle desktop has been rendered.

[0012] Optionally, after rendering the target vehicle desktop based on the current shared data, initial private data, and initial shared data, the above method further includes: in response to the configuration command of the target vehicle desktop, obtaining operation data for the target vehicle desktop; and re-rendering the target vehicle desktop based on the operation data.

[0013] Optionally, based on the operation data, the target in-vehicle desktop is re-rendered, including: dividing the operation data into operation shared data and operation private data; updating the target shared data based on the operation shared data to obtain new target shared data; updating the initial private data based on the operation private data to obtain new initial private data; and re-rendering the new target in-vehicle desktop based on the new target shared data and the new initial private data.

[0014] Optionally, the above method further includes: identifying the vehicle's operating scenario based on the vehicle's operating condition data, determining whether the vehicle's operating scenario has changed, and generating a desktop switching command if the operating scenario has changed.

[0015] Optionally, in the case of rendering the target vehicle desktop for the first time, the above method further includes: reading preset shared data and preset private data; and rendering the target vehicle desktop based on the preset shared data and preset private data.

[0016] According to another aspect of this application, a rendering system for an in-vehicle desktop is also provided, comprising: a storage device, the storage area of ​​which is divided into a shared area and multiple private areas, wherein the shared area is used to store shared data of multiple in-vehicle desktops, and different private areas are used to store private data of different in-vehicle desktops, and the different private areas are isolated from each other; a scheduling and management device, used to, in response to receiving a desktop switching command, obtain the current shared data of the current in-vehicle desktop from the shared area, and, based on the scene identifier corresponding to the desktop switching command, synchronize the initial private data corresponding to the target in-vehicle desktop from the private area, and synchronize the initial shared data corresponding to the target in-vehicle desktop from the shared area, wherein the desktop switching command is used to indicate switching the current in-vehicle desktop to the target in-vehicle desktop; and a rendering device, used to render the target in-vehicle desktop based on the current shared data, the initial private data, and the initial shared data.

[0017] Optionally, the scheduling and management equipment is also used to assign different sandboxes to different in-vehicle desktops. The sandboxes are used to read and write shared data and private data from storage devices based on scene identifiers.

[0018] Optionally, the scheduling and management equipment is also used to synchronize shared data between different sandboxes, as well as to isolate private data between different sandboxes.

[0019] Optionally, the scheduling and management device is also used to update shared and / or private data based on the received operational data.

[0020] According to another aspect of this application, a vehicle is also provided, including: an in-vehicle display screen, which is rendered by the methods in various embodiments of this application.

[0021] According to another aspect of this application, a vehicle is also provided, comprising: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods of various embodiments of this application when it runs.

[0022] According to another aspect of this application, a computer-readable storage medium is also provided, which includes a stored executable program, wherein, when the executable program is executed, it controls the device on which the computer-readable storage medium is located to perform the methods of various embodiments of this application.

[0023] According to another aspect of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the methods of various embodiments of this application.

[0024] According to another aspect of this application, a computer program product is also provided, including a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the methods of various embodiments of this application.

[0025] According to another aspect of this application, a computer program is also provided, which, when executed by a processor, implements the methods of various embodiments of this application.

[0026] In this application, in response to receiving a desktop switching command, the current shared data of the current in-vehicle desktop is obtained, wherein the desktop switching command indicates switching the current in-vehicle desktop to the target in-vehicle desktop; based on the scene identifier corresponding to the desktop switching command, the initial in-vehicle data corresponding to the target in-vehicle desktop is synchronized, wherein the initial in-vehicle data includes initial private data and initial shared data; based on the current shared data, the initial private data, and the initial shared data, the target in-vehicle desktop is rendered. Upon receiving the desktop switching command, this application first retains the current shared data of the current in-vehicle desktop to avoid repeated initialization of common configurations. Then, based on the scene identifier, the initial in-vehicle data of the target in-vehicle desktop is accurately synchronized for differentiated data loading. Finally, the current shared data, the initial private data, and the initial shared data are used to render the target in-vehicle desktop, facilitating the reuse of shared components while injecting the scene-specific private components corresponding to the target in-vehicle desktop, thus achieving the goal of ensuring data security and improving data security. This solves the technical problem of poor security in data management of multiple in-vehicle desktops in related technologies. Attached Figure Description

[0027] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0028] Figure 1 This is a flowchart of a method for rendering an in-vehicle desktop according to an embodiment of this application;

[0029] Figure 2 This is a schematic diagram of an optional in-vehicle desktop rendering system according to an embodiment of this application;

[0030] Figure 3 This is a schematic diagram of an optional data architecture according to an embodiment of this application;

[0031] Figure 4 This is a schematic diagram illustrating an optional data mounting and permission isolation method according to an embodiment of this application;

[0032] Figure 5This is a schematic diagram of an optional data synchronization method according to an embodiment of this application;

[0033] Figure 6 This is a schematic diagram of a rendering device for an in-vehicle desktop according to an embodiment of this application. Detailed Implementation

[0034] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0035] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used 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 this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0036] According to an embodiment of this application, a method embodiment for rendering an in-vehicle desktop is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0037] This embodiment provides a method for rendering an in-vehicle desktop. Figure 1 This is a flowchart of a rendering method for an in-vehicle desktop according to an embodiment of this application, such as... Figure 1 As shown, the process includes the following steps:

[0038] Step S102: In response to receiving the desktop switching command, obtain the current shared data of the current vehicle desktop.

[0039] The desktop switching command is used to indicate switching the current in-vehicle desktop to the target in-vehicle desktop.

[0040] The aforementioned in-vehicle desktop refers to the graphical user interface deployed on the vehicle's in-vehicle display screen. The in-vehicle desktop is not a single static page, but rather software composed of components such as a launcher process, window manager, desktop icon layout, and status bar. It relies on the underlying operating system, such as the Android system framework, and requires hardware resources such as a touchscreen, high-definition display, memory, and processor power to maintain smooth rendering performance. The in-vehicle desktop offers a wide variety of functions, including displaying navigation maps, multimedia playback controls, vehicle settings menus, phone contacts, and entry points for third-party applications.

[0041] Different in-vehicle desktops can be configured for different scenarios, such as two or three desktops; there is no limitation. Different desktops can be customized for different usage scenarios. For example, the driving interface emphasizes simplicity and safety, while the parking interface emphasizes entertainment and richness. A well-designed in-vehicle desktop makes vehicle control functions intuitive and convenient, reducing the driver's operational burden and improving driving safety. At the same time, the presence of multiple desktops allows the vehicle to automatically switch interface styles according to the usage scenario, meeting the requirements for safety data while driving, while retaining rich support for entertainment data while parked.

[0042] The aforementioned desktop switching command is used to trigger the in-vehicle system to migrate from one running desktop environment to another. The desktop switching command signifies a scene change caused by user intent or automatic system judgment. It is not merely a simple page jump command, but a system-level event containing contextual information. The command can reflect the identification information of the source and target desktops, as well as the reason for the switch, such as manual user clicks, changes in vehicle operating conditions, or scheduled system tasks. The conditions for generating a desktop switching command can be a driver-initiated switching request via physical buttons, touchscreen gestures, or a voice assistant, or automatic generation by the system when the vehicle gateway receives vehicle status signals such as exceeding a speed threshold or shifting into D or P gear. The desktop switching command can trigger the rendering and interaction of the current in-vehicle desktop, pause relevant background services, and initiate the initialization process of the target in-vehicle desktop, such as data synchronization, permission checks, and interface loading.

[0043] The aforementioned current in-vehicle desktop refers to the in-vehicle desktop instance that is currently running in the foreground, occupying the main display area of ​​the screen, and responding to user interactions before the desktop switching action occurs.

[0044] The aforementioned currently shared data refers to the configuration data currently read, used, or modified by the in-vehicle desktop. This currently shared data should be globally visible, meaning it can be accessed by other in-vehicle desktops besides the current one. The currently shared data reflects the latest desktop status perceived by the current in-vehicle desktop at the current moment, such as volume settings, Bluetooth pairing records, and navigation save points. The currently shared data can be stored in key-value pairs, including data such as the name, value, last modified timestamp, and version number of the configuration item.

[0045] The aforementioned target in-vehicle desktop refers to the in-vehicle desktop instance that will be activated upon the desktop switching command and will replace the current in-vehicle desktop as the foreground display interface. The target in-vehicle desktop is the target environment that the user is about to enter or that the system automatically switches to, representing the expected desktop at the next moment.

[0046] The target in-vehicle desktop takes over the user's interaction tasks in the next scenario, providing application interfaces and function entries that correspond to desktop switching commands, such as switching from the parking entertainment interface to the driving navigation interface, or vice versa.

[0047] In one optional embodiment, the current shared data of the current in-vehicle desktop can be obtained by reading the configuration database. After receiving the desktop switching command, the system queries the configuration database through the application programming interface, using the identifier of the current in-vehicle desktop as a filter condition to retrieve the data records belonging to the current in-vehicle desktop. To ensure the real-time performance and consistency of the data, a read-write lock on the configuration database file is acquired before performing the read operation to prevent other processes from concurrently modifying the shared data during the read process.

[0048] In another optional embodiment, the current shared data of the current in-vehicle desktop is asynchronously retrieved from the shared data management service via a remote procedure call interface. The current in-vehicle desktop, acting as a client, initiates a data retrieval request to the shared data management service. When a desktop switching command arrives, the current in-vehicle desktop instantiates a data request object, containing the identifier of the current in-vehicle desktop and the range of data to be retrieved, and sends it to the shared data management service. Upon receiving the request, the management service executes the data query logic in its internal thread pool, reading data from the shared area of ​​the storage layer. To avoid blocking the main thread of the current desktop, the management service employs an asynchronous callback mechanism, returning the data via a broadcast message after the data retrieval is complete.

[0049] In another alternative embodiment, the current shared data of the in-vehicle desktop is obtained from the shared data buffer via a network socket or a local shared memory block. The shared data in the shared area is loaded into a fixed memory address region and mapped to the process address space of the current in-vehicle desktop, forming a shared memory block. When a desktop switching command is triggered, the data structure in this shared memory region is accessed via a pointer. To ensure data consistency, the system maintains a version number or serial number in the shared memory. Before reading, the version number is checked. If the version number is different from the last read, it means the shared data has been updated, and it needs to be read again and the local cache updated. If the version number is the same, the data in memory is used directly.

[0050] Step S104: Based on the scene identifier corresponding to the desktop switching command, synchronize the initial vehicle data corresponding to the target vehicle desktop.

[0051] The initial vehicle data includes initial private data and initial shared data.

[0052] The aforementioned scene identifier is a string or numerical code used to uniquely determine the logical environment or operating state of the in-vehicle desktop. The scene identifier represents a specific vehicle usage state, such as "driving mode," "parking mode," "child mode," or "driver mode," and each identifier corresponds to a set of preset data isolation rules and authorization list policies. Scene identifiers can be derived by the system based on desktop switching commands, vehicle operating data, or user selections, or read from the target desktop's configuration file. Scene identifiers provide routing guidance, enabling accurate identification of the target in-vehicle desktop's attributes, thus determining which data can be synchronized, which data should be isolated, and what priority strategy to use for conflict resolution. Scene identifiers may include, but are not limited to, scene type, security level, and data access permission list. Scene identifiers are the core index for implementing multi-desktop data, enabling dynamic adjustment of the scope of data sharing and isolation, ensuring the consistency of core vehicle control configurations across different vehicle usage scenarios.

[0053] The aforementioned initial vehicle data refers to the data loaded from the storage device during the switching process of the target vehicle desktop. Initial vehicle data can include initial private data and initial shared data. Initial vehicle data is the configuration data stored for rendering the target vehicle desktop, ensuring that the target vehicle desktop can correctly display icons, application status, and system settings. Initial vehicle data may include, but is not limited to, user personalization settings, application login status, cached files, navigation records, Bluetooth pairing information, etc. Initial private data contains portions specific to the target vehicle desktop, while initial shared data contains configuration items common to all scenarios.

[0054] The aforementioned initial private data refers to configuration data with exclusive access rights belonging solely to the target in-vehicle desktop. This initial private data includes, but is not limited to, privacy-specific content, entertainment account login status, personalized themes, game progress, and specific application preference settings unique to the target in-vehicle desktop. This initial private data is invisible and inaccessible to other in-vehicle desktops. Therefore, the initial private data can be stored in a private area, which other in-vehicle desktops besides the target desktop do not have access to. This ensures that privacy and entertainment data do not interfere with each other in different scenarios, preventing entertainment data residue or privacy leaks during driving, while also ensuring that users' independent personalized configurations are fully preserved and quickly restored when switching between different scenarios, thereby improving user experience continuity and data security.

[0055] The initial shared data described above can be accessed and used by all in-vehicle desktops. This initial shared data may include, but is not limited to, system volume, screen brightness, date and time, network configuration, Bluetooth device list, and navigation bookmarks. The initial shared data ensures that the desktop displays according to the user's general settings and system defaults. The initial shared data can exist in key-value pair format for easy retrieval and merging.

[0056] Since the common configuration items on the current vehicle desktop may change, it is necessary to compare and arbitrate the initial shared data with the current shared data to resolve potential data conflicts and ensure the consistency and stability of the core vehicle control settings.

[0057] In one optional embodiment, initial in-vehicle data corresponding to the target in-vehicle desktop is synchronized through a prefetch caching and predictive loading mechanism. Machine learning algorithms or historical behavior analysis are used to predict the type of in-vehicle desktop the user is about to switch to. Upon detecting a user's intention to switch (e.g., a finger approaching a switch button, voice command recognition, or vehicle operating conditions approaching a switch threshold), the data synchronization process is initiated in advance. Based on the prediction results, the initial in-vehicle data corresponding to the target in-vehicle desktop is read from the storage device and preloaded into a high-speed cache. After detecting a desktop switching command, data can be retrieved from the high-speed cache, achieving low-latency loading. Preloading reduces the waiting time during switching. To improve prefetch accuracy, user switching mode data is continuously collected to train the machine learning algorithm, and the prefetch strategy is dynamically adjusted. For example, if a user frequently switches from driving mode to parking mode after get off work, the system will predict this behavior and preload parking data.

[0058] In another optional embodiment, initial vehicle data corresponding to the target in-vehicle desktop is obtained through a distributed configuration center or cloud synchronization service. This initial in-vehicle data is stored not only on local storage devices but also synchronously backed up to a cloud server. Upon triggering the desktop switching command, the system first checks whether the version number in the local cache matches the latest version on the cloud. If they do not match, a data retrieval request is initiated from the cloud configuration center via the cellular network. The cloud service returns the latest configuration data packet based on the target desktop's scenario identifier. Upon receiving the data packet, the local system performs integrity verification and decryption, then loads it into memory.

[0059] In another alternative embodiment, the initial vehicle data corresponding to the target vehicle desktop is synchronized based on the direct memory access mechanism of memory-mapped files. The initial vehicle data stored in the storage device is mapped to the virtual address space of the process. This allows the application to directly access this data via pointers. Upon triggering a desktop switching command, the corresponding data file is located based on the scene identifier, and a mapping relationship is established. The operating system kernel loads disk data into physical memory pages as needed and handles page faults. For shared area data, multiple desktop processes can map to the same memory region, thereby achieving memory sharing and further reducing system memory usage.

[0060] Step S106: Render the target vehicle desktop based on the current shared data, initial private data, and initial shared data.

[0061] In one alternative embodiment, the current shared data, initial private data, and initial shared data are parsed and converted into a structured configuration object. A layout template is determined based on the scene identifier of the target in-vehicle desktop. Subsequently, the rendering engine merges UI (User Interface) elements from the current shared data, initial private data, and initial shared data, such as driving speed dial, navigation controls, global font size, theme color, and volume icon status.

[0062] The rendering engine then iterates through these UI elements, instantiates the corresponding View objects, and then draws them to the frame buffer. This decouples the UI logic from the data logic, thereby improving rendering efficiency and flexibly adapting to in-vehicle display devices with different resolutions and screen sizes.

[0063] In another alternative embodiment, a high-efficiency rendering technique using a hardware-accelerated graphics rendering pipeline is employed. Utilizing the vehicle's GPU (Graphics Processing Unit) resources, current shared data, initial private data, and initial shared data are transformed into GPU-recognizable texture and vertex data. For example, based on the theme configuration in the current shared data, initial private data, and initial shared data, corresponding background textures, icon atlases, and font glyphs are preloaded into the GPU's video memory. For dynamic elements (such as speedometers and real-time traffic condition layers), corresponding vertex buffers and index buffers are generated. The rendering engine performs real-time tone mapping and lighting processing on the textures through the shader program, ensuring that the display effect matches the current ambient lighting conditions. For 3D models or complex animations, skeletal animation or vertex animation techniques are used for real-time calculations on the GPU, avoiding CPU overhead. During the rendering process, depth testing and stencil testing are used to adjust the rendering order, ensuring that critical driving information (such as warning lights) is always on the top layer of the UI and not obscured by entertainment elements.

[0064] In another alternative embodiment, an event-driven, asynchronous rendering-based responsive UI update mechanism is employed. Changes to current shared data, initial private data, and initial shared data are treated as an event stream. By subscribing to these data change events, a partial redraw is automatically triggered instead of a full refresh when a data update is detected. For example, when a change in volume is detected, only the state and value display of the volume control bar are updated, without re-rendering the entire desktop layout. For static configurations (such as wallpapers and themes), their rendering results are cached after the initial load and recalculated only when the user switches themes. The rendering engine uses an asynchronous task queue to separate UI drawing tasks from data synchronization tasks, ensuring that data computation does not block the main thread's rendering operations. If data synchronization takes a long time, a temporary skeleton screen or placeholder can be displayed to maintain the visual continuity of the interface. Once data synchronization is complete, a smooth transition to the final target in-vehicle interface is achieved through cross-fade-in and cross-fade-out animations. This improves system responsiveness and user experience consistency, avoiding interface stuttering or black screen phenomena caused by data loading delays. Simultaneously, the partial update mechanism reduces rendering workload and lowers power consumption.

[0065] In this embodiment, in response to receiving a desktop switching command, the current shared data of the current vehicle desktop is obtained. The desktop switching command indicates switching the current vehicle desktop to a target vehicle desktop. Based on the scene identifier corresponding to the desktop switching command, the initial vehicle data corresponding to the target vehicle desktop is synchronized. The initial vehicle data includes initial private data and initial shared data. Based on the current shared data, initial private data, and initial shared data, the target vehicle desktop is rendered. Upon receiving the desktop switching command, this application first retains the current shared data of the current vehicle desktop to avoid repeated initialization of common configurations. Then, based on the scene identifier, the initial vehicle data of the target vehicle desktop is accurately synchronized for differentiated data loading. Finally, the current shared data, initial private data, and initial shared data are used to render the target vehicle desktop, facilitating the reuse of shared components while injecting the scene-specific private components corresponding to the target vehicle desktop. This achieves the goal of ensuring data security, thereby improving data security and solving the technical problem of poor security in data management of multiple vehicle desktops in related technologies.

[0066] Optionally, the target in-vehicle desktop is rendered based on the current shared data, the initial private data, and the initial shared data, including: comparing the current shared data and the initial shared data to obtain the difference data; constructing the target shared data based on the difference data; and rendering the target in-vehicle desktop based on the target shared data and the initial private data.

[0067] The aforementioned discrepancy data refers to the inconsistencies identified between two data sets after comparing the current shared data with the initial shared data. Discrepancy data can manifest as additions, deletions, modifications, or changes in the values ​​of common configuration items. It reflects the data that needs to be synchronized, avoiding invalid full-scale overwrites and improving synchronization efficiency and system response speed.

[0068] The aforementioned target shared data refers to the latest common configuration data used to render the target in-vehicle desktop, which is finally determined after comparing, arbitrating, and fusing the current shared data and the initial shared data. The target shared data reflects the latest common configuration items, thereby achieving data consistency and continuity of user habits. This solves the problem of data overwriting and configuration errors caused by alternating modifications across multiple desktops, ensuring that the common settings remain up-to-date regardless of how users switch between different scenarios.

[0069] In one optional embodiment, the current shared data is compared with the initial shared data to identify changes in the common configuration, such as additions, deletions, and modifications, that occur during the switching between two different in-vehicle desktop scenarios, rather than processing the entire dataset. By accurately locating data change points, repeated reading and transmission of unchanged configuration data is avoided, thereby reducing system I / O (Input / Output) operations and memory bandwidth usage. For example, hash comparison or version serial number comparison can be used to quickly filter out datasets containing changed fields, i.e., difference data, improving the response speed and system smoothness during multi-desktop switching.

[0070] Then, by utilizing the unchanged portions of the difference data and the initial shared data, a final common configuration set is derived. This reduces the risk of data inconsistency and conflicts arising from alternating configuration modifications across multiple scenarios, ensuring that the target in-vehicle desktop receives the configuration state after intelligent decision-making. For example, when driving mode and parking mode have different preferences for the same setting, the final retained value is determined according to preset rules, ensuring the consistency and stability of system data, preventing abnormal interface display or functional failures caused by configuration errors, and achieving a balance between personalized settings and system stability through an intelligent conflict resolution mechanism.

[0071] Therefore, based on target shared data and initial private data, the target in-vehicle desktop is rendered to provide an interactive experience that conforms to both the user's global habits and scenario-specific characteristics. This ensures that users can immediately obtain a familiar and personalized operating environment after switching desktops, achieving real-time mapping from data to visual representation. Thus, while ensuring driving safety, user convenience and satisfaction are improved.

[0072] Optionally, the current shared data and the initial shared data are compared to obtain the difference data, including: dividing the current shared data into multiple first key-value pairs and dividing the initial shared data into multiple second key-value pairs; comparing each first key-value pair and each second key-value pair separately to obtain at least one pair of difference key-value pairs, wherein the fields of the first key-value pairs in a pair of difference key-value pairs are consistent with the fields of the second key-value pairs in a pair of difference key-value pairs; arbitrating the at least one pair of difference key-value pairs to obtain the target key-value pairs; and constructing the difference data based on the target key-value pairs.

[0073] In one optional embodiment, the current shared data is divided into multiple first key-value pairs, and the initial shared data is divided into multiple second key-value pairs, thereby decomposing the data set into small-granularity configuration units, i.e., key-value pairs, where the "key" represents the name or identifier of the configuration item, and the "value" represents the specific configuration content. This enables unified identification and processing of complex configuration information. The data can be converted into a list of data structures using a parsing algorithm, ensuring that each configuration item can be independently addressed and accessed, avoiding the ambiguity and inefficiency of overall comparison.

[0074] Then, each first key-value pair and each second key-value pair are compared separately to obtain at least one pair of differing key-value pairs. By traversing the two sets of key-value pair lists, items with the same "key" but different "values," or items that only exist in one set of lists, are filtered out to identify the configuration data that has changed. Through key-value pair comparison, the location and content of data changes are accurately located, eliminating identical configuration items that have not changed and avoiding interference from invalid data. Field-by-field or item-by-item content validation is performed, using hash calculations or string comparison algorithms to identify paired key-value pairs with inconsistent values; these pairs are the differing key-value pairs. This narrows down the range of candidate data that needs further processing, transforming the comparison of full data into the identification of local differences, reducing computational complexity and improving synchronization efficiency.

[0075] Furthermore, arbitration is performed on at least one pair of differing key-value pairs, selecting one pair as the final state of the configuration item. This resolves potential conflicting states of the same configuration item across multiple scenarios, ensuring logical consistency of system data. By executing arbitration algorithms, such as comparing timestamps to determine the latest version or using strategies like "driving priority" or "user manual priority" to decide which value to retain, data conflicts are avoided. This ensures the correctness and security of the vehicle system configuration, prevents system anomalies or security risks caused by data overwriting errors, and achieves intelligent data management.

[0076] Therefore, the target key-value pairs determined after arbitration can be collected and encapsulated into a new data structure or data package. This data contains the latest configuration information that needs to be applied to the target in-vehicle desktop, providing an accurate data source for subsequent interface rendering. The scattered, processed key-value pairs are integrated into a complete set of differential data, which may include operation instructions for adding, modifying, or deleting. The logical arbitration result is transformed into physical data update content, enabling the rendering engine to directly read and apply these latest configurations. This achieves a closed loop from data comparison and conflict resolution to application, ensuring the real-time, accuracy, and completeness of the target in-vehicle desktop configuration, improving user experience smoothness and system stability.

[0077] Optionally, arbitrating at least one pair of differing key-value pairs to obtain a target key-value pair includes: determining the target key-value pair based on the timestamps of at least one pair of differing key-value pairs, wherein the timestamp of the target key-value pair is later than the timestamps of other key-value pairs; or, determining the target key-value pair based on the version numbers of at least one pair of differing key-value pairs, wherein the version number of the target key-value pair is greater than the version numbers of other key-value pairs; or, determining the target key-value pair based on the configuration attributes of at least one pair of differing key-value pairs, wherein the priority order corresponding to the configuration attributes of the target key-value pair is higher than the priority order corresponding to the configuration attributes of other key-value pairs.

[0078] In one optional embodiment, the timestamp associated with each differing key-value pair can be extracted. By comparing the order of these timestamps, it can be determined which data change occurred later, and the key-value pair with the later timestamp is selected as the final target key-value pair to retain. This means that the most recent modification is considered to represent the latest intent of the user or system. Through a simple numerical or time format comparison algorithm, configuration items with the latest timestamps are quickly filtered out, ignoring older data. This resolves the data version conflict problem caused by parallel operations in multiple scenarios, ensuring that the vehicle configuration reflects the latest user operations or system status, and improving the real-time performance and accuracy of data synchronization.

[0079] In another optional embodiment, the version identifier bound to each difference key-value pair is read. By comparing the size or hierarchy of the version numbers, it is determined which version is more advanced or complete, and the key-value pair with the larger version number is selected as the target key-value pair. This introduces a version control mechanism that focuses not only on the time of data changes but also on the iterative state of the data structure. Its function is to parse the version number string or integer sequence, perform logical comparison operations, identify the version identifier representing the latest logical state, and select the corresponding key-value pair as the target key-value pair. This enhances the robustness of data management, especially after structural changes to configuration items or multiple rounds of synchronization correction. The version number effectively prevents erroneous overwriting caused by timestamp resets or clock asynchrony, ensuring that the system loads the latest verified configuration logic, thus improving the reliability and compatibility of data synchronization across multiple devices or scenarios.

[0080] In another optional embodiment, based on preset business rules or security policies, different configuration items are assigned specific priority weights (e.g., driving safety configuration has higher priority than entertainment configuration, or user-manual configuration has higher priority than system default configuration). In case of conflict, the configuration value of the higher-priority attribute is retained first. Decisions are made considering scenario safety and user experience to ensure that critical functions are not interfered with. By querying the configuration attribute table, the priority label of each differing key-value pair is obtained, and the higher-priority key-value pair is selected as the target data according to the priority sorting rules (e.g., descending order). This allows for flexible handling of complex in-vehicle usage scenarios, such as forcibly overriding entertainment settings in driving mode or locking the latest state after manual user adjustment, thereby improving user satisfaction while ensuring driving safety.

[0081] Optionally, before obtaining the current shared data of the current in-vehicle desktop, the above method may also include: freezing the current private data of the current in-vehicle desktop.

[0082] In one optional embodiment, at the initial stage of the desktop switching process, access restrictions are immediately imposed on the private data area of ​​the source in-vehicle desktop (i.e., the current in-vehicle desktop). This could involve modifying file system permissions, disabling data synchronization services, or locking memory mappings, thereby preventing read / write operations from modifying or reading this private data. This severs the dynamic connection between the source desktop and the private data, ensuring that sensitive or private data such as personalized configurations, login status, and cached files on the source desktop remain unchanged during the switching process, preventing data loss due to background process remnants or asynchronous tasks. Through underlying system security mechanisms, a logically static data snapshot environment is created, ensuring that the source desktop's private data is read-only or invisible during the switching window. This avoids the risk of privacy leaks, ensures data isolation, and guarantees the purity of data across different scenarios.

[0083] Optionally, after rendering the target vehicle desktop based on the current shared data, initial private data, and initial shared data, the above method further includes: detecting the rendering status of the target vehicle desktop, wherein the rendering status is used to indicate whether the target vehicle desktop has been rendered; and clearing the cached data generated during the switching of the vehicle desktop if the rendering status indicates that the target vehicle desktop has been rendered.

[0084] The rendering status mentioned above refers to indicators representing the degree of preparation for the target vehicle desktop's construction, data binding, and screen display. The rendering status reflects the progress of the desktop's process from data loading to visualization. It can indicate whether the target vehicle desktop has finished rendering, including data parsing completion, view tree construction completion, resource loading completion, and final drawing completion. The rendering status reflects the health and completion of the rendering process.

[0085] In one optional embodiment, after rendering the target in-vehicle desktop, its rendering status can be detected. This can be achieved by querying the status flags of the graphics rendering engine, the frame buffer completion signal, or callback notifications from the UI thread. The entire lifecycle of the target in-vehicle desktop, from data loading and layout calculation to final pixel rendering, can be monitored in real time to confirm whether it is ready for user interaction. By accurately controlling the execution progress of the rendering task, subsequent resource release operations are avoided before the interface is displayed or is incomplete, preventing issues such as screen flickering, black screens, or data races caused by timing discrepancies. For example, the rendering status can be determined by obtaining the status code returned by the rendering thread (e.g., "Rendering in progress," "Rendering complete," or "Rendering failed") through polling or asynchronous callback mechanisms. This decoupling and synchronization of the rendering process and resource management process improves the determinism and stability of system operation, ensuring a consistent user visual experience and efficient utilization of system resources.

[0086] Therefore, once the rendering state indicates that the target in-vehicle desktop rendering is complete, the system cleans up the cached data generated during the switching process. This is achieved by proactively releasing and clearing temporarily created or occupied memory resources, temporary files, intermediate calculation results, and unused data blocks, such as UI states, window parameters, and synchronization logs in the temporary cache. This prevents resource leaks and avoids the accumulation of garbage data that occupies in-vehicle memory and storage space, thus maintaining the long-term operational efficiency and smoothness of the system. By calling the system memory management interface or file cleanup service, the system can identify and destroy temporary data objects valid during the switching transition, reclaiming the physical memory pages they occupy. This enables dynamic reclamation and closed-loop management of in-vehicle system resources, reducing background memory usage and I / O load, minimizing system heat generation and power consumption, extending the hardware lifespan of in-vehicle electronic devices, and preventing switching delays or system lag caused by cache accumulation. This ensures high-performance and long-term stability of the system in high-frequency multi-desktop switching scenarios.

[0087] Optionally, after rendering the target vehicle desktop based on the current shared data, initial private data, and initial shared data, the above method further includes: in response to the configuration command of the target vehicle desktop, obtaining operation data for the target vehicle desktop; and re-rendering the target vehicle desktop based on the operation data.

[0088] The aforementioned configuration commands refer to control commands issued by the user or system to modify the display style, function parameters, or layout structure of the in-vehicle desktop. Configuration commands trigger dynamic updates and re-rendering of the in-vehicle desktop content. Configuration commands can be generated by the user through touchscreen swiping, clicking settings icons, voice commands, or automatic triggering strategies, to change a specific configuration item on the current desktop.

[0089] Configuration commands are responses to user customization needs or system security policies, dynamically adjusting desktop display content and behavior logic, such as adjusting air conditioning temperature, switching navigation map scale, and hiding entertainment icons. Configuration commands may include, but are not limited to, command type, target attribute, new value, and operation source.

[0090] Configuration commands serve as the entry point for user customization and real-time interaction, transforming the in-vehicle desktop from a static display window into an intelligent interface that flexibly adapts to user intent. By processing configuration commands, the vehicle can update shared or private data and trigger re-rendering, ensuring that user actions take effect immediately. This enhances the vehicle's interactivity and personalized service level, maintaining user activity and satisfaction.

[0091] The aforementioned operational data refers to specific data generated by user interaction or automated system behavior used to update the in-vehicle desktop configuration or application status. Operational data objects include, but are not limited to, modified parameter values, application operation logs, location coordinates, timestamps, etc., thereby driving changes in the desktop status. Operational data is generated by capturing input events and extracting relevant parameters when the user performs configuration operations or the system executes automated tasks.

[0092] The operation data includes, but is not limited to, operation type, operation target, operation value, operation time, and user identifier. The operation data provides the specific information needed to update the target vehicle data, such as new volume levels, new wallpaper backgrounds, and new navigation destination coordinates.

[0093] In one optional embodiment, when a user interacts with the rendered target in-vehicle desktop via touch, voice, physical buttons, or gestures, the system listens for and captures these input events, parses them into configuration commands, and extracts the corresponding operation data. By receiving the raw event stream, and through event distribution and routing mechanisms, the system locates the corresponding graphical user interface component or business logic module, extracts key operation data, and achieves a closed loop of human-computer interaction. This enables users to control and adjust the in-vehicle system status in real time, improving the system's availability and interactivity.

[0094] Then, based on the operation data, the target in-vehicle desktop can be re-rendered, triggering a UI state redraw process. The new configuration results are reflected on the screen in real time, providing instant visual feedback to user actions. This ensures that the interface state and user actions remain synchronized in real time, reducing the delay between operation and visual feedback and providing a smooth interactive experience. For example, by updating the data model, the view layer can be notified to perform a partial or global refresh, recalculating the layout, updating control properties (such as switch status, volume bar position, list scroll position), and calling the graphics API to redraw the affected UI areas. This ensures that the in-vehicle desktop can flexibly adapt to user operation needs, enhancing the user's sense of control and trust in the system, improving user experience smoothness and satisfaction, and also ensuring that configuration data changes take effect in real time.

[0095] Optionally, based on the operation data, the target in-vehicle desktop is re-rendered, including: dividing the operation data into operation shared data and operation private data; updating the target shared data based on the operation shared data to obtain new target shared data; updating the initial private data based on the operation private data to obtain new initial private data; and re-rendering the new target in-vehicle desktop based on the new target shared data and the new initial private data.

[0096] In one optional embodiment, the operation data is divided into shared operation data and private operation data. For example, the operation data can be categorized based on its source, type, and configuration domain. Configuration changes involving global general settings and cross-scene synchronization (such as volume, wallpaper, and Bluetooth status) are classified as shared operation data, while configuration changes specific to the current scene (such as driving shortcut layout and parking entertainment account settings) are classified as private operation data. Data change routing is implemented by parsing the target control identifier or configuration key name of the operation command and matching it with preset classification rules or list mechanisms to split the mixed operation data stream into two independent logical branches.

[0097] Then, the categorized shared operation data can be applied to the currently residing or active target shared data. Through merging, overwriting, or incremental updates, the state of the global common configuration is modified, and new target shared data is generated. User's common operation intentions are persisted to the common configuration storage, ensuring these settings can be inherited and reused in other scenarios or subsequent switches. Atomic operations are used to update corresponding fields in the database or configuration file, potentially involving version number increments and conflict arbitration logic, to guarantee data consistency and integrity. This improves the user experience when switching between different desktops.

[0098] Furthermore, the categorized private operation data is applied to the initial private data specific to the current scenario, modifying the private configuration items bound to that scenario without affecting data in other scenarios or public areas, thereby generating new initial private data reflecting the current scenario. This ensures that scenario-specific personalized settings and privacy data are updated independently and securely, preventing the leakage of private configurations or access by unauthorized scenarios. Through an isolated write mechanism, the locality and security of data modifications are ensured, guaranteeing the independence and privacy of data between different scenarios and preventing security risks or user experience interference caused by mixed configurations.

[0099] Furthermore, based on the new target shared data and the new initial private data, the UI rendering engine is driven to recalculate the interface layout, refresh the control state, and draw the final screen, completing the dynamic update of the target in-vehicle desktop. Redrawing the affected areas or performing a full redraw transforms abstract data changes into concrete visual changes. This ensures immediate response to user operations and real-time synchronization of the interface state, improving the system's response speed and interaction smoothness.

[0100] Optionally, the above method further includes: identifying the vehicle's operating scenario based on the vehicle's operating condition data, determining whether the vehicle's operating scenario has changed, and generating a desktop switching command if the operating scenario has changed.

[0101] In one optional embodiment, the vehicle's operating scenario can be identified based on vehicle operating condition data. For example, vehicle operating parameters can be collected in real time via an onboard bus or sensor network, and these data can be comprehensively analyzed and judged using preset logical rules or algorithm models to determine the specific operating scenario the vehicle is currently in (e.g., parking mode, driving mode, charging mode, rest mode, etc.). This determines whether the vehicle's operating scenario has switched, reducing misjudgments caused by brief vehicle deceleration or signal fluctuations. This ensures the accuracy and reliability of scenario switching triggers, preventing frequent desktop switching triggers in critical states (e.g., about to stop but not yet completely stopped), and avoiding user interface flickering or interruptions. The system also judges whether the current scenario state is inconsistent with historical states and verifies whether the inconsistent state meets the conditions for continuous stability, thus making a "not switched" or "switched" judgment. This introduces a scenario switching stability verification mechanism to ensure that desktop switching is only triggered when the vehicle's operating conditions undergo substantial changes, guaranteeing the continuity and comfort of the user experience.

[0102] Therefore, when the operating scene changes, a desktop switching command can be generated and sent to the UI scheduling service or desktop manager to initiate subsequent data isolation, synchronization, and rendering processes. The scene recognition results are transformed into system-level control actions, coordinating various subsystems (such as data synchronization service, rendering engine, and permission management service) to execute desktop switching tasks according to a predetermined process, enabling the in-vehicle desktop to intelligently adapt to the user's driving behavior.

[0103] Optionally, in the case of rendering the target vehicle desktop for the first time, the above method further includes: reading preset shared data and preset private data; and rendering the target vehicle desktop based on the preset shared data and preset private data.

[0104] In one optional embodiment, upon initial startup or when the target in-vehicle desktop does not yet contain historical user data, pre-set initial public configurations (such as default volume, default wallpaper, and basic network settings) and default scenario-specific configurations (such as the default layout for driving mode or the default application recommendations for parking mode) can be loaded from the system's internal storage or default configuration file. This provides the in-vehicle system with a safe and fully functional initial state, ensuring normal startup and provision of basic usable functions even without personalized user data. Establishing initial shared and private zones guarantees basic availability and consistency after system startup.

[0105] Furthermore, based on preset shared and private data, the UI rendering engine generates the initial interface layout, icon arrangement, background style, and default control states of the target in-vehicle desktop, completing the initial visual presentation. This presents users with a clean initial interactive interface, reducing display anomalies or blank screens that may result from empty data. It achieves seamless integration between system startup and interface display, ensuring the integrity and professionalism of the user experience, and reserving interfaces and space for subsequent user data loading, synchronization, and personalization customization through the initial interface.

[0106] According to an embodiment of this application, an embodiment of a rendering system for an in-vehicle desktop is provided. It should be noted that the device can be used to execute the above-described rendering method for an in-vehicle desktop.

[0107] This embodiment provides a rendering system for an in-vehicle desktop. Figure 2 This is a schematic diagram of a rendering system for an in-vehicle desktop according to an embodiment of this application, such as... Figure 2 As shown, the rendering system includes:

[0108] Storage device 22, the storage area of ​​the storage device is divided into a shared area and multiple private areas. The shared area is used to store the shared data of multiple in-vehicle desktops, and different private areas are used to store the private data of different in-vehicle desktops, and the different private areas are isolated from each other.

[0109] The scheduling and management device 24 is used to respond to receiving a desktop switching command, obtain the current shared data of the current vehicle desktop from the shared area, and synchronize the initial private data corresponding to the target vehicle desktop from the private area and synchronize the initial shared data corresponding to the target vehicle desktop from the shared area based on the scene identifier corresponding to the desktop switching command. The desktop switching command is used to indicate switching the current vehicle desktop to the target vehicle desktop.

[0110] Rendering device 26 is used to render the target vehicle desktop based on the current shared data, the initial private data, and the initial shared data.

[0111] The aforementioned storage devices refer to hardware or logical storage units in an in-vehicle system used for persistently storing data related to the in-vehicle desktop, applications, system configurations, and user files, such as eMMC, UFS flash memory, or SD cards. Storage devices are the physical or logical carriers of data, providing long-term data retention capabilities, ensuring data is not lost even after power failure.

[0112] The storage device provides data read and write services for scheduling and rendering devices. It implements hierarchical management and isolated storage of data, supporting data isolation and sharing mechanisms across multiple desktops by dividing the data into different partitions. This ensures the physical or logical separation of shared data, such as critical security data, from private data, such as entertainment data, thereby improving data security and management flexibility.

[0113] The aforementioned shared area refers to a data partition stored on a storage device that is read and written by multiple in-vehicle desktops. The shared area can be used to store frequently used public configuration information. Access permissions are open to authorized desktops. As a public platform for data exchange between different scenarios, the shared area stores data that needs to be synchronized across desktops, such as system settings, navigation favorites, and Bluetooth pairing. The content of the shared area can exist in the form of key-value pairs, XML configuration files, or lightweight databases, facilitating rapid parsing and merging.

[0114] The shared area achieves a balance between data sharing and isolation, enabling users to maintain the continuity of core settings when switching between different scenarios. At the same time, the authorized list mechanism restricts the scope of data that can be synchronized to prevent privacy data leakage. It is the basic data structure for building a multi-desktop collaborative work environment, improving the system's flexibility and user convenience.

[0115] The aforementioned private zone refers to a data partition stored on a storage device, dedicated to a specific in-vehicle desktop, and subject to access isolation restrictions. It is used to store the desktop's personalized configurations and privacy data. The private zone is a concrete manifestation of the data isolation strategy; it is physically or logically independent of the private zones of other desktops, and other desktops have no direct access to it.

[0116] The private zone creates an independent directory or user space for each desktop and sets access permissions. This stores the desktop's proprietary data, such as driving preferences, in-car entertainment accounts, game progress, themes, and wallpapers, ensuring the privacy and independence of this data. The private zone guarantees data security and privacy protection in different scenarios, preventing entertainment data from interfering with driving safety, while preserving the user's personalized experience. It enables customized services for each scenario and is a key storage unit for achieving secure isolation and personalized services across multiple desktops, enhancing system security and user engagement.

[0117] The aforementioned scheduling and management equipment refers to the software module or hardware controller in the vehicle system responsible for coordinating in-vehicle desktop switching, data synchronization, access control, and resource allocation. The scheduling and management equipment can run at the operating system framework layer. It receives desktop switching commands, parses scene identifiers, controls data flow, and coordinates the work of various components. The scheduling and management equipment can freeze and unlock storage areas, execute incremental synchronization algorithms, arbitrate data conflicts, allocate sandbox environments, and monitor rendering status.

[0118] The dispatch management equipment enables intelligent data control in a multi-desktop environment. Through synchronization and isolation strategies, it resolves data conflicts and security risks, ensuring a smooth switching process and data consistency, thereby improving user experience and ensuring driving safety.

[0119] The aforementioned rendering device refers to the hardware component or graphics processing module in an in-vehicle system that converts target in-vehicle data into a visible graphical interface and outputs it to the in-vehicle display screen, such as a GPU or a specific graphics rendering engine. The rendering device can transform abstract data into concrete pixel arrays, driving the screen to display icons, text, videos, and animations. The rendering device is implemented through the display screen and corresponding graphics drivers and hardware acceleration units, such as performing UI layout calculations, resource loading, graphics drawing, and screen refresh operations.

[0120] The rendering device determines the visual quality and smoothness of the in-vehicle desktop. An efficient rendering device can achieve fast switching, lag-free animation, and high-resolution display, improving the user's visual experience and operation feedback.

[0121] The aforementioned rendering system, through the collaborative operation of storage devices, scheduling and management devices, and rendering devices, constructs a closed-loop technical architecture of data isolation, on-demand synchronization, and fused rendering. Specifically, the storage devices physically divide data into shared areas and mutually isolated private areas, achieving a fundamental separation between driving safety data and in-vehicle entertainment privacy data. Upon receiving a scene switching command, the scheduling and management device no longer performs a full data migration. Instead, it intelligently extracts general configurations from the shared area and synchronizes the corresponding initial private data based on the target scene identifier. This preserves users' cross-scene usage habits while ensuring the purity of scene-specific data. The rendering devices perform rendering based on the fusion of these three types of data, achieving seamless switching, reducing IO overhead and switching latency, and improving the system's real-time performance and security.

[0122] Optionally, the scheduling and management equipment is also used to assign different sandboxes to different in-vehicle desktops. The sandboxes are used to read and write shared data and private data from storage devices based on scene identifiers.

[0123] The aforementioned sandbox refers to a security mechanism or virtual container used in vehicle systems to isolate the runtime environments of different in-vehicle desktop processes and restrict their resource access permissions. A sandbox is not an independent storage device, but rather an access control mechanism. It creates a closed runtime space for each in-vehicle desktop process, restricting access to authorized data partitions.

[0124] Sandboxes ensure that the driving launcher and the parking launcher do not interfere with each other, preventing erroneous codes or operations from affecting other desktops, while also implementing data access control. Sandboxes can include, but are not limited to, lists of permission rules, mount point mappings, and network isolation policies. Sandboxes are a technology for achieving data isolation and security management, fundamentally protecting the security of the in-vehicle system, preventing data leaks and system crashes, while also supporting multiple desktops running in parallel, improving system stability and reliability.

[0125] By leveraging the secure container mechanism provided by the operating system, an independent, permission-controlled data access environment is created for each running in-vehicle desktop, ensuring that each desktop process operates within an authorized sandbox. A fine-grained security boundary is constructed to prevent unauthorized data access and resource contention between different desktops at the process level, enhancing the overall system security. Through kernel-level permission isolation policies, application processes are mapped to the underlying file system, giving each in-vehicle desktop an independent virtual file path or namespace. This logically achieves isolation between physical storage spaces, ensuring the stability and attack resistance of the in-vehicle system when facing complex application ecosystems.

[0126] The sandbox deploys data routing and access control logic that can parse the current scenario identifier (such as driving or parking) and dynamically adjust access permissions and data mapping relationships for shared and private areas in the storage device accordingly. This allows reading the data required for the current scenario while blocking access to unauthorized data. This achieves context-aware data access and dynamic permission control, ensuring that data operations are confined to the current business scenario and preventing unauthorized data access.

[0127] By intercepting and filtering storage I / O requests, and verifying them using scenario identifiers, read and write requests are forwarded to the corresponding shared or private area directories, while unauthorized requests are blocked, thereby achieving fine-grained data isolation and synchronization control. This transforms static storage partitions into dynamic, scenario-aware data access channels, enabling precise data synchronization based on scenario identifiers and improving the flexibility and security of data management.

[0128] Optionally, the scheduling and management equipment is also used to synchronize shared data between different sandboxes, as well as to isolate private data between different sandboxes.

[0129] The dispatch management device utilizes a background synchronization service to periodically or under specific triggering conditions (such as desktop switching or configuration changes) compare version information of corresponding shared data areas in different sandboxes. It identifies discrepancies and performs merging, overwriting, or incremental update operations to ensure global consistency of common configurations (such as Bluetooth pairing, system volume, and navigation favorites) across different scenarios. This reduces version fragmentation of common data across multiple scenarios, preventing users from seeing inconsistent basic settings on different desktops and ensuring the global uniformity of system status. The dispatch management device uses comparison mechanisms (such as MD5 checksums or timestamp comparisons) to lock changed data, transmit and write the differences, achieving efficient data flow. This breaks down data silos between different desktop instances, allowing users to maintain consistent operating habits and common settings throughout the vehicle, thus improving the continuity of the user experience.

[0130] The scheduling and management equipment also ensures that each sandbox accesses its own private data area through access control policies and file system permission management, preventing cross-sandbox reading, writing or modification of private data on other desktops (such as driving-specific layouts, parking entertainment accounts, game progress, etc.), and blocking other data access requests at the process level to prevent the leakage of sensitive data or personalized configurations in different scenarios, thus ensuring the independence and security of data in each scenario.

[0131] By using a sandbox mechanism and permission verification logic, unauthorized data I / O operations are intercepted, ensuring clear boundaries for data access and preventing configuration errors and application crashes caused by data misuse.

[0132] Optionally, the scheduling and management device is also used to update shared and / or private data based on the received operational data.

[0133] After receiving operation data, the dispatch and management equipment can update shared and / or private data based on this data, achieving a persistent conversion of user operation intentions into system configuration data. This ensures that users' personalized settings and scene preferences are recorded and take effect immediately, guaranteeing real-time feedback in interactions. By establishing a mapping logic between operation events and the data storage layer, discrete user inputs are transformed into structured configuration changes, triggering corresponding data write operations. This may involve background processing mechanisms such as version number incrementing, timestamp marking, and conflict detection, enabling the in-vehicle desktop to dynamically adapt to user needs and maintain real-time consistency of configuration status. This lays the foundation for subsequent cross-scene data synchronization, ensuring that users can still enjoy the user experience after switching scenes. At the same time, precise data updates avoid redundant writing of invalid data, improving system resource utilization.

[0134] The technical solution proposed in this application is described below with reference to an optional embodiment. This application proposes a method for application data isolation and controllable sharing synchronization management in a multi-launcher scenario, which is applicable to the parallel operation architecture of AI multi-desktop in vehicle configuration. It can realize secure isolation, hierarchical controllable sharing, incremental differential synchronization and intelligent resolution of data conflicts for launcher application data in different scenarios.

[0135] Current in-vehicle Android multi-launcher solutions mainly fall into two data management modes: One is a global data interoperability mode, where the same application data directory, configuration files, and cached data are shared, with no data isolation mechanism between multiple desktops, and application login status, user configuration, and cached files are globally interconnected. The other mode uses independent application directories for different launchers, with data isolation and no interoperability; all application configurations, caches, and login statuses are independent, and cross-desktop data synchronization is not supported.

[0136] The current solution has the following drawbacks: poor global interoperability and security. For example, data sharing between the driving launcher and the parking launcher means that the cache, account information, and pop-up configurations of the parking entertainment application will be carried over to the driving scenario, easily leading to driving entertainment pop-ups, privacy leaks, and background remnants of unauthorized applications, which does not comply with vehicle driving safety management standards. Disjointed user experience due to isolated interfaces. Independent data on dual desktops prevents users from synchronizing navigation records, favorite addresses, Bluetooth pairing, vehicle settings, and screen mirroring parameters across scenarios. Switching desktops results in configuration resets, account re-logins, and record loss, severely disrupting the user experience. Difficulty in distinguishing between shared and isolated security data hinders hierarchical management and compatibility. High overhead for full synchronization. Synchronization using full file overwrite is time-consuming and consumes a lot of I / O, easily causing switching lag, high system load, and affecting the smooth operation of the vehicle system and aftermarket AI box. When multiple launchers alternately modify the same configuration, data overwriting, configuration errors, and state conflicts are likely to occur, leading to stability issues such as desktop anomalies, application crashes, and configuration failures in the long run.

[0137] This embodiment addresses the issues of residual entertainment data, pop-up interference, privacy leaks, and security control failures caused by global data interoperability among multiple launchers in driving scenarios. It achieves scenario isolation of entertainment-related privacy data and process states. To address the problems of incompatibility between vehicle control configurations, navigation data, and system parameters, leading to fragmented dual-desktop experiences, redundant configuration settings, and inconsistent user habits, as well as the high I / O overhead, high latency, and lag during full file synchronization, a lightweight incremental differential synchronization method is implemented to reduce system load. To address the issues of configuration overwriting, data conflicts, and state inconsistencies caused by alternating data modifications across multiple desktops, a timing priority and conflict resolution mechanism is constructed to ensure data consistency. Finally, a data governance system is established that ensures controllable sharing of secure data and isolation of risky data.

[0138] This embodiment constructs a three-layer data partitioning system through a multi-Launcher data collaborative management architecture that features hierarchical data isolation, controllable sharing of authorized lists, incremental differential synchronization, and intelligent conflict resolution. This enables both secure isolation and on-demand interoperability between the driving Launcher and the parking Launcher, while also ensuring both vehicle safety standards and user experience continuity.

[0139] This embodiment proposes a three-layer data partitioning and hierarchical isolation architecture, dividing application data into three levels: a public shared area, a scene-specific private area, and a temporary cache area. Different launchers independently mount their private partitions, while the public partitions are globally reused under controlled conditions. Simultaneously, through the Android system-level sandbox mounting isolation mechanism, it prohibits the loading of parking entertainment private data in driving scenarios and prevents driving safety configurations from being modified by entertainment applications, achieving security isolation from the ground up.

[0140] The public shared area (authorized list approved) stores low-risk, essential data such as navigation records, favorite addresses, vehicle infotainment system settings, volume and brightness, Bluetooth pairing, general screen mirroring parameters, and network configurations, and supports bidirectional synchronization across Launchers.

[0141] The scene-specific private area is isolated. The parking launcher independently stores audio / video accounts, game data, dynamic wallpaper configurations, entertainment caches, and third-party application login status. The driving launcher independently stores driving preferences, navigation routes, vehicle speed display configurations, and security control parameters. These two types of private data do not overlap or can be read by each other.

[0142] Temporary cache (automatically recycled), such as UI states and window parameters temporarily cached when switching scenes, is automatically cleared after the switch is completed to prevent the residue of junk data.

[0143] This embodiment proposes a controllable bidirectional synchronization mechanism based on an authorized list. By pre-setting an authorized list of data that can be synchronized and an unauthorized list that is prohibited from synchronization, cross-desktop synchronization is performed on the authorized list fields, while the unauthorized list data is isolated. The synchronization trigger is precisely bound to the Launcher switching event, and the data versions of the common areas of the two desktops are automatically compared at the moment of switching to achieve bidirectional merging and updating, ensuring seamless continuity of user settings, navigation data, and device pairing status.

[0144] This embodiment proposes an incremental differential lightweight synchronization algorithm, which uses a differential hash comparison mechanism to identify and synchronize changed data fragments, while unchanged fields directly reuse local cache. The synchronization unit is simplified to a single configuration key-value pair, reducing the average amount of synchronized data by more than 85% and compressing the synchronization time to less than 50ms, avoiding switching lag and IO spikes.

[0145] This embodiment proposes a time-series version management and data conflict resolution mechanism. Each synchronously configurable data entry is marked with both a timestamp and a version number, automatically determining the data update sequence. If a higher timestamp version overwrites a lower version, parallel conflicting data adopts a dual arbitration strategy that prioritizes vehicle configuration and user manual operation, automatically resolving data disorder and overwriting conflicts caused by alternating modifications in multiple scenarios, and ensuring global data consistency.

[0146] This embodiment proposes a scene-linked data freezing and recovery mechanism. When switching to the driving launcher, the system automatically freezes read and write permissions for the parking entertainment private data directory, prohibiting background writing and loading of entertainment data. After switching back to the parking scene, the data is unfrozen and restored, realizing the linkage management of scene data lifecycle and vehicle operating conditions.

[0147] This enhances security. For example, a three-level data partitioning and isolation mechanism, along with a scenario-based permission freezing mechanism, achieves bidirectional physical isolation between driving safety data and parking entertainment privacy data. This prevents data residues such as parking entertainment accounts, entertainment caches, and pop-up configurations from remaining in the driving environment, effectively mitigating the risks of driving entertainment interference and user privacy leaks. It also improves user experience continuity. A controllable bidirectional synchronization mechanism based on authorized lists allows for cross-Launcher bidirectional synchronization of vehicle system basic settings, navigation favorites, Bluetooth / WiFi pairing, and screen mirroring parameters. Users no longer need to repeatedly configure parameters or log in to application accounts, resolving issues of configuration resets and fragmented experiences when switching between multiple desktops, ensuring a consistent and unified user experience. Finally, it improves synchronization performance. A key-value pair-level incremental differential synchronization algorithm synchronizes changed data fragments, keeping the data synchronization time for a single switch stable within 50ms. This represents a performance improvement of over 90% for the volume synchronization solution, achieving seamless data synchronization. To enhance data stability, a timestamp and version number time-series management mechanism is introduced, coupled with a multi-dimensional data conflict arbitration strategy. This intelligently resolves overwriting and data corruption issues caused by alternating data modifications across multiple scenarios, reducing the system data corruption rate to below 0.3%. This effectively addresses stability issues such as configuration anomalies, application crashes, and parameter failures caused by alternating use of multiple desktops. Furthermore, precise incremental differential synchronization filters invalid data synchronization operations, reducing redundant overhead from frequent disk reads and writes. This lowers the overall background I / O load by 78%, effectively reducing power consumption and hardware heat generation, and improving the long-term stability and battery life of the device.

[0148] This embodiment can be deployed on an aftermarket in-vehicle Android desktop system without modifying the original vehicle infotainment system's underlying architecture. Data isolation management, authorized list synchronization, and version arbitration services are added to the Framework layer. Through configuration, data partitions are divided into a public shared area, a scene-specific private area, and a temporary cache area. The smallest unit of synchronization is a single key-value pair. The differential comparison hash algorithm uses MD5. The synchronization timeout threshold is 50ms. Conflict arbitration priority is set to manual user operation. Driving scene configuration is implemented, with parking scene configuration decreasing sequentially. Entertainment data is frozen during driving scenes.

[0149] For the public shared area, navigation favorites, historical routes, volume and brightness, Bluetooth / WiFi configuration, general screen projection parameters, time and date, and basic vehicle control settings are stored. Synchronization is achieved through bidirectional incremental synchronization and version selection overwriting, with no isolation and global readability.

[0150] For the private area in the parking garage, which stores audio and video accounts, playback history, game data, live wallpapers, theme caches, and login status of third-party entertainment applications, cross-scene synchronization is prohibited, and in the driving scene, it is read-only frozen and loading is prohibited.

[0151] For the private driving area, the system stores driving quick layouts, vehicle speed display parameters, safety control thresholds, and navigation simplified mode configurations. Cross-scenario synchronization is prohibited, and parking scenarios are tamper-proof and read-only.

[0152] The temporary cache stores the UI state during the switch, temporary window parameters, and synchronized temporary logs, and is automatically destroyed and recycled after the switch is complete.

[0153] In addition, data synchronization can be achieved using incremental snapshot synchronization or log playback synchronization schemes depending on the volume of in-vehicle data. For scenarios with large-volume in-vehicle configuration files and massive cached data, data synchronization is completed through incremental snapshot capture and frame-by-frame playback of operation logs. This embodiment can also be configured with an AI-powered intelligent learning dynamic list mechanism. For example, by collecting user usage behavior and data operation habits across multiple scenarios, machine learning can be used to autonomously identify high-frequency synchronization-critical data and low-frequency isolated privacy data, dynamically updating synchronization and isolation rules to achieve adaptive data management. Added features include user manual configuration locking, multi-user permission priority differentiation, and differentiated priority strategies for day and night periods. This allows for accurate judgment of data conflicts in scenarios involving alternating operations by multiple users and different usage times, further improving data consistency and adaptability in complex usage scenarios. Furthermore, cloud backup and cross-device roaming synchronization capabilities can be expanded. For example, a cloud-encrypted data warehouse can be built to achieve cloud synchronization and one-click roaming migration of Launcher layouts, system configurations, and personalized parameters across multiple in-vehicle devices and vehicles, breaking the limitations of single-device data and improving the overall continuity of use for users with multiple vehicles and devices.

[0154] Therefore, the rendering test metrics of this embodiment can achieve excellent results. For example, the time for a single data synchronization can be ≤50ms, and the data compression rate can reach 85.2%. The data corruption rate in multiple scenarios is ≤0.3%. The residual rate of in-vehicle entertainment data is 0%. The increase in switching IO load can be reduced by 78%.

[0155] Figure 3 This is a schematic diagram of an optional data architecture according to an embodiment of this application, such as... Figure 3 As shown, the architecture includes a scheduling management layer, a data layer, and an application layer. The scheduling management layer provides data isolation management services, synchronization services, version arbitration services, and operational status linkage services. The data layer uses a three-level data partitioning system, including a public shared area, a parking private area, a driving private area, and a temporary cache area. The public shared area, the parking private area, and the driving private area are isolated from each other. The application layer includes a parking desktop and a driving desktop. The parking desktop mounts the parking private area and the public area, and the driving desktop mounts the driving private area and the public area.

[0156] Figure 4 This is a schematic diagram illustrating an optional data mounting and permission isolation method according to an embodiment of this application, such as... Figure 4As shown, a sandbox mounting and isolation mechanism is configured at the security framework layer. Multiple desktop sandboxes (e.g., parking desktop sandbox 1, driving desktop sandbox 2) are provided through scene identifiers, with independent data directory mounting and access control to achieve data mounting and permission isolation. Parking desktop sandbox 1 can read and write parking private data, public shared areas, and temporary cache areas. Driving desktop sandbox 2 can read and write driving private data, public shared areas, and temporary cache areas. The public shared area achieves bidirectional synchronization, and cross-sandbox data read / write is prohibited using a sandbox isolation wall.

[0157] Figure 5 This diagram illustrates an optional data synchronization method according to an embodiment of this application. It allows for incremental differential comparison of data such as navigation favorites, volume, Bluetooth pairing, and screen mirroring references. This can be achieved by sequentially performing hash comparison, identifying changed key-value pairs, extracting differing data, and compressing the data. Data arbitration can utilize timestamp and version number comparison to propose arbitration strategies based on new timestamps, driving configuration being higher than parking configuration, or manual configuration being higher than automatic configuration. This reduces data corruption rates, decreases single synchronization time, and improves data compression rates.

[0158] Taking the parking-to-driving transition as an example, the data isolation and synchronization process is explained. When the vehicle is in a stable parking condition, the parking launcher is loaded and running normally, granting full data read and write permissions. It can normally access and read / write private entertainment data such as audio and video cache, theme wallpapers, and login status of third-party entertainment applications in the parking private area. At the same time, it continuously maintains the vehicle's configuration, navigation records, and device pairing parameters in the public shared area, ensuring the normal operation of the full-featured entertainment experience in the parking scenario.

[0159] Then, the vehicle's CAN bus collects vehicle operating condition data in real time. After verifying that the operating condition parameters meet the anti-shake threshold and determining that a stable driving scenario has been entered, it actively triggers a dual-Launcher switching command and simultaneously starts the data preprocessing mechanism. It locks and freezes the private data directory for parking, prohibiting the loading and rendering of private data such as entertainment accounts, dynamic themes, and cached files, thus avoiding the problem of entertainment data residue in driving scenarios from the source.

[0160] This process synchronizes the public shared area authorization list data, employs the MD5 differential comparison algorithm to accurately compare the differences in public configuration key-value pairs between the driving Launcher and the parking Launcher, and filters out changed data fragments to generate incremental synchronization data packets. The overall data is compressed to the KB level, and the synchronization time for a single session is controlled within 50ms, ensuring high efficiency and low latency. Based on a dual arbitration rule of timestamps and version numbers, the public shared area configuration parameters are updated preferentially, automatically retaining the latest navigation routes, favorite addresses, Bluetooth / Wi-Fi pairing, system volume and brightness, and other core configurations, achieving seamless continuation of user habits. Simultaneously, private entertainment data in the parking area is isolated, never loaded, migrated, or affected throughout the process, ensuring the purity and security of driving data.

[0161] After the vehicle launcher completes loading and rendering, it reuses secure public infrastructure configurations and vehicle-specific private data, without displaying entertainment pop-ups, dynamic effects, background entertainment processes, or residual data. This ultimately achieves the dual effect of secure data isolation in the driving scenario and seamless synchronization of core vehicle infotainment function configurations, balancing driving safety regulations with the continuity of user experience.

[0162] The data isolation and synchronization process is explained using the driving-to-parking switch as an example. After the vehicle finishes driving and comes to a complete stop, the onboard CAN bus continuously collects operating data such as vehicle speed, gear position, and handbrake status. Once the preset anti-shake threshold is met and a stable parking condition is determined, the automatic switching logic from the driving launcher to the parking launcher is triggered. Simultaneously, read / write permissions for the parking private data directory are released, restoring the normal loading and rendering capabilities of entertainment data, thus preparing for scene restoration.

[0163] The synchronization service automatically initiates the public shared area data synchronization process, employing the MD5 incremental differential comparison mechanism to accurately identify changes in navigation routes, screen volume, screen mirroring adaptation parameters, device configurations, and other content updated within the driving scenario, and synchronizes incremental difference data. With low IO overhead and an ultra-fast synchronization speed of less than 50ms, driving operation configurations are seamlessly synchronized to the parking desktop. After completing the optimized synchronization and update of public configurations, the service fully loads exclusive data from the parking private area, such as user-defined dynamic theme wallpapers, audio / video application login status, historical playback cache, and third-party entertainment application configurations. Personalized entertainment parameters for the parking scenario are fully restored, while public configurations use the latest version.

[0164] Once the scene transition and data synchronization are complete, the system automatically clears temporary cached UI state, window parameters, synchronization logs, and other transitional data from the transition process, and automatically reclaims redundant system memory and disk resources to prevent the accumulation of junk data. This ultimately achieves highly stable data synchronization and complete restoration of the parking scene.

[0165] Furthermore, the intelligent resolution mechanism for data conflicts across multiple scenarios is explained. While the vehicle is in motion, users can independently modify synchronized common configuration parameters such as air conditioning temperature, screen brightness, navigation preferences, and voice broadcast modes in the driving Launcher interface. Because the parking Launcher locally stores the same configuration parameters from previous versions, differences in configuration key-value pairs between the two scenarios can lead to inconsistencies in data versions across multiple scenarios, creating potential data synchronization conflicts.

[0166] During cross-scenario synchronization, the system data synchronization service compares key-value pairs of common configuration parameters in real time to accurately identify data conflicts between the two ends. It then retrieves the timestamps and version numbers bound to both configurations for verification, prioritizing update order and adhering to arbitration rules that prioritize new timestamps and driving configurations. The system automatically overwrites the old parking configuration with the latest driving configuration to ensure data timeliness. If the system detects that configurations in both scenarios are modified concurrently with the same timestamp, making it difficult to determine priority through time sequence, it automatically triggers an arbitration strategy prioritizing user manual operations. The latest configuration parameters manually adjusted by the user are retained first, while the system's default adaptive update data is automatically discarded, avoiding data corruption, configuration overwriting, and parameter anomalies caused by alternating editing across multiple scenarios.

[0167] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0168] According to an embodiment of this application, a device embodiment for rendering an in-vehicle desktop is provided. It should be noted that the device can be used to execute the above-described in-vehicle desktop rendering method.

[0169] This embodiment provides a rendering device for an in-vehicle desktop. Figure 6 This is a schematic diagram of a rendering device for an in-vehicle desktop according to an embodiment of this application, such as... Figure 6 As shown, the device includes:

[0170] The acquisition module 60 is used to acquire the current shared data of the current vehicle desktop in response to receiving a desktop switching command. The desktop switching command indicates that the current vehicle desktop is switched to the target vehicle desktop.

[0171] The synchronization module 62 is used to synchronize the initial vehicle data corresponding to the target vehicle desktop based on the scene identifier corresponding to the desktop switching command. The initial vehicle data includes initial private data and initial shared data.

[0172] Rendering module 64 is used to render the target vehicle desktop based on the current shared data, initial private data, and initial shared data.

[0173] Optionally, the rendering module is also used to: compare the current shared data with the initial shared data to obtain the difference data; construct the target shared data based on the difference data; and render the target in-vehicle desktop based on the target shared data and the initial private data.

[0174] Optionally, the rendering module is also used to: divide the current shared data into multiple first key-value pairs and divide the initial shared data into multiple second key-value pairs; compare each first key-value pair and each second key-value pair to obtain at least one pair of differing key-value pairs, wherein the fields of the first key-value pairs in a pair of differing key-value pairs are consistent with the fields of the second key-value pairs in a pair of differing key-value pairs; arbitrate the at least one pair of differing key-value pairs to obtain target key-value pairs; and construct differing data based on the target key-value pairs.

[0175] Optionally, the rendering module is further configured to: determine a target key-value pair based on the timestamps of at least one pair of differing key-value pairs, wherein the timestamp of the target key-value pair is later than the timestamps of other key-value pairs; or, determine a target key-value pair based on the version numbers of at least one pair of differing key-value pairs, wherein the version number of the target key-value pair is greater than the version numbers of other key-value pairs; or, determine a target key-value pair based on the configuration attributes of at least one pair of differing key-value pairs, wherein the priority order corresponding to the configuration attributes of the target key-value pair is higher than the priority order corresponding to the configuration attributes of other key-value pairs.

[0176] Optionally, the above device also includes a freezing module for freezing the current private data of the current in-vehicle desktop before acquiring the current shared data of the current in-vehicle desktop.

[0177] Optionally, the above device further includes a detection module, used to detect the rendering status of the target vehicle desktop after rendering the target vehicle desktop based on the current shared data, initial private data and initial shared data, wherein the rendering status is used to indicate whether the target vehicle desktop has been rendered; if the rendering status indicates that the target vehicle desktop has been rendered, the cached data generated during the switching of vehicle desktop is cleared.

[0178] Optionally, the rendering module is also used to render the target vehicle desktop based on the current shared data, initial private data, and initial shared data, and then, in response to the configuration instructions of the target vehicle desktop, obtain operation data for the target vehicle desktop; and re-render the target vehicle desktop based on the operation data.

[0179] Optionally, the rendering module is also used to: divide the operation data into operation shared data and operation private data; update the target shared data based on the operation shared data to obtain new target shared data; update the initial private data based on the operation private data to obtain new initial private data; and re-render the new target in-vehicle desktop based on the new target shared data and the new initial private data.

[0180] Optionally, the above device also includes an identification module, used to: identify the vehicle's operating scenario based on the vehicle's operating condition data, determine whether the vehicle's operating scenario has changed, and generate a desktop switching command if the operating scenario has changed.

[0181] Optionally, the rendering module is also used to read preset shared data and preset private data when rendering the target in-vehicle desktop for the first time; and to render the target in-vehicle desktop based on the preset shared data and preset private data.

[0182] Embodiments of this application also provide a vehicle including an in-vehicle display screen, which is rendered using the methods described in various embodiments of this application.

[0183] This application also provides an electronic device, including a memory and a processor, wherein the memory is used to store computer programs; and the processor is used to execute the programs stored in the memory to implement the methods in various embodiments of this application.

[0184] Embodiments of this application also provide a computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of this application.

[0185] Embodiments of this application also provide a computer program product, including a computer program that, when executed by a processor, implements the methods of various embodiments of this application.

[0186] Embodiments of this application also provide a computer program product, including a non-volatile computer-readable storage medium for storing a computer program that, when executed by a processor, implements the methods in various embodiments of this application.

[0187] Embodiments of this application also provide a computer program that, when executed by a processor, implements the methods described in the various embodiments of this application.

[0188] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0189] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection can be through some interfaces; the indirect coupling or communication connection between units or modules can be electrical or other forms.

[0190] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0191] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0192] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0193] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for rendering an in-vehicle desktop, characterized in that, include: In response to receiving a desktop switching command, the system obtains the current shared data of the current in-vehicle desktop, wherein the desktop switching command indicates that the current in-vehicle desktop is switched to the target in-vehicle desktop; Based on the scene identifier corresponding to the desktop switching command, the initial vehicle data corresponding to the target vehicle desktop is synchronized, wherein the initial vehicle data includes initial private data and initial shared data; The target in-vehicle desktop is rendered based on the current shared data, the initial private data, and the initial shared data.

2. The method according to claim 1, characterized in that, Based on the current shared data, the initial private data, and the initial shared data, the target in-vehicle desktop is rendered, including: The current shared data and the initial shared data are compared to obtain the difference data; Based on the aforementioned discrepancies, target shared data is constructed; The target in-vehicle desktop is rendered based on the target shared data and the initial private data.

3. The method according to claim 2, characterized in that, The current shared data and the initial shared data are compared to obtain the difference data, including: The current shared data is divided into multiple first key-value pairs, and the initial shared data is divided into multiple second key-value pairs; Each first key-value pair and each second key-value pair are compared separately to obtain at least one pair of differing key-value pairs, wherein the fields of the first key-value pair in a pair of differing key-value pairs are the same as the fields of the second key-value pair in a pair of differing key-value pairs. Arbitrate the at least one pair of differing key-value pairs to obtain the target key-value pair; The difference data is constructed based on the target key-value pairs.

4. The method according to claim 3, characterized in that, Arbitration of the at least one pair of differing key-value pairs to obtain the target key-value pair includes: The target key-value pair is determined based on the timestamps of the at least one pair of differing key-value pairs, wherein the timestamp of the target key-value pair is later than the timestamps of the other key-value pairs; Alternatively, the target key-value pair can be determined based on the version number of the at least one pair of differing key-value pairs, wherein the version number of the target key-value pair is greater than the version number of the other key-value pairs; Alternatively, the target key-value pair can be determined based on the configuration attributes of the at least one pair of different key-value pairs, wherein the priority order of the configuration attributes of the target key-value pair is higher than the priority order of the configuration attributes of other key-value pairs.

5. The method according to claim 1, characterized in that, Before obtaining the currently shared data of the current in-vehicle desktop, the method further includes: Freeze the current private data of the current in-vehicle desktop.

6. The method according to claim 1, characterized in that, After rendering the target in-vehicle desktop based on the current shared data, the initial private data, and the initial shared data, the method further includes: Detect the rendering status of the target vehicle desktop, wherein the rendering status is used to characterize whether the target vehicle desktop has been rendered. When the rendering state indicates that the target vehicle desktop rendering is complete, clear the cached data generated during the switching of the vehicle desktop.

7. The method according to claim 2, characterized in that, Based on the current shared data, the initial private data, and the initial shared data, after rendering the target in-vehicle desktop, the method further includes: In response to the configuration command of the target vehicle desktop, obtain operation data for the target vehicle desktop; Based on the operation data, the target in-vehicle desktop is re-rendered.

8. The method according to claim 7, characterized in that, Based on the operation data, the target in-vehicle desktop is re-rendered, including: The operational data is divided into shared operational data and private operational data. The target shared data is updated based on the operation shared data to obtain new target shared data; The initial private data is updated based on the operation private data to obtain new initial private data; Based on the new target shared data and the new initial private data, the new target in-vehicle desktop is re-rendered.

9. The method according to claim 1, characterized in that, The method further includes: Based on the vehicle's operating data, the vehicle's operating scenario is identified to determine whether the operating scenario has changed, and if the operating scenario has changed, the desktop switching command is generated.

10. The method according to claim 1, characterized in that, In the case of rendering the target in-vehicle desktop for the first time, the method further includes: Read preset shared data and preset private data; The target in-vehicle desktop is rendered based on the preset shared data and the preset private data.

11. A rendering system for an in-vehicle desktop, characterized in that, include: The storage device has a storage area divided into a shared area and multiple private areas. The shared area is used to store the shared data of multiple in-vehicle desktops, and the different private areas are used to store the private data of different in-vehicle desktops, and the different private areas are isolated from each other. The scheduling and management device is used to respond to receiving a desktop switching instruction, obtain the current shared data of the current vehicle desktop from the shared area, and synchronize the initial private data corresponding to the target vehicle desktop from the private area and synchronize the initial shared data corresponding to the target vehicle desktop from the shared area based on the scene identifier corresponding to the desktop switching instruction. The desktop switching instruction is used to indicate switching the current vehicle desktop to the target vehicle desktop. A rendering device for rendering the target in-vehicle desktop based on the current shared data, the initial private data, and the initial shared data.

12. The rendering system according to claim 11, characterized in that, The scheduling and management device is also used to allocate different sandboxes to different in-vehicle desktops. The sandboxes are used to read and write shared data and private data from the storage device based on the scene identifier.

13. The rendering system according to claim 12, characterized in that, The scheduling and management device is also used to synchronize shared data from different sandboxes and to isolate private data from different sandboxes.

14. The rendering system according to claim 13, characterized in that, The scheduling and management device is also configured to update the shared data and / or the private data based on the received operation data in response to receiving operation data.

15. A vehicle, characterized in that, include: A vehicle-mounted display screen, wherein the vehicle-mounted display screen is rendered by the method of any one of claims 1-10.

16. An electronic device, characterized in that, include: Memory, which stores executable programs; A processor for running the program, wherein the program, when running, performs the method according to any one of claims 1-10.

17. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored executable program, wherein, when the executable program is executed, it controls the device on which the storage medium is located to perform the method according to any one of claims 1-10.

18. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method according to any one of claims 1-10.

Images