Application adaptation method and terminal device

Abstract

The application is applied to the terminal technical field, and provides an application adaptation method and a terminal device, the method comprising: establishing a screen projection connection with a vehicle terminal; obtaining first screen information of the vehicle terminal; starting a vehicle desktop, and displaying the vehicle desktop on the vehicle terminal; determining first configuration information of a target display mode based on the first screen information, the first configuration information comprising the position and size of the window of the display application; detecting a click operation of a user on an application icon on the vehicle desktop; and in the case that the first application corresponding to the application icon supports the target display mode, displaying at least one interface of the first application on the vehicle desktop in the target display mode. Through the above scheme, the vehicle desktop can be configured by using the terminal device, the application is displayed in the target display mode in the case that the target display mode is supported, the interface display after the vehicle terminal is connected with the terminal device is adapted, display problems such as too small control and disordered display are avoided, and better display effect is provided.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to an application adaptation method and terminal device. Background Technology

[0002] With the development of automotive intelligence, users can use smart car connectivity products to connect their mobile phones and car systems while driving. Simply connect your phone in the car to share lifestyle services on your phone to the in-car screen, and experience and control different applications through the in-car screen.

[0003] However, due to the varying screen sizes of existing in-vehicle infotainment systems, and the presence of landscape, irregularly shaped, and low-resolution screens, many applications on mobile phones are not adapted to the irregularly shaped or landscape modes of in-vehicle infotainment systems during the interconnection process between the in-vehicle infotainment system and mobile phones. This results in poor display effects and display errors on the in-vehicle infotainment system. Summary of the Invention

[0004] This application provides an application adaptation method and terminal device to solve the problem of poor display effect or even display disorder caused by adaptation issues when displaying applications on the vehicle terminal.

[0005] According to a first aspect of the embodiments of this application, an application adaptation method is provided, applied to a terminal device, the method comprising: establishing a screen projection connection with a vehicle-mounted terminal; acquiring first screen information of the vehicle-mounted terminal; launching an in-vehicle desktop and displaying the in-vehicle desktop on the vehicle-mounted terminal; determining first configuration information of a target display mode based on the first screen information, the first configuration information including the setting position and size of the window for displaying the application; detecting a user's click operation on an application icon on the in-vehicle desktop; and, if the first application corresponding to the application icon supports the target display mode, displaying at least one interface of the first application on the in-vehicle desktop in the target display mode.

[0006] The above solution enables the in-vehicle desktop to be configured via the terminal device when the vehicle-mounted system is connected to the terminal device. This allows the applications clicked by the user to be displayed in the target display mode if it is supported, thus adapting to the difference in display areas between the vehicle-mounted system and the terminal device, providing a better display effect, and avoiding display problems such as controls being too small or display errors.

[0007] In one feasible implementation, determining the first configuration information of the target display mode based on the first screen information includes: obtaining the position and size of the navigation bar on the in-vehicle desktop; and determining the size and position of at least two display windows based on the position and size of the navigation bar and the first screen information. This avoids obstructing the navigation bar on the in-vehicle desktop, preventing display windows from occupying the navigation bar and affecting user interaction with the in-vehicle desktop.

[0008] In one feasible implementation, after detecting a user's click on an application icon on the in-vehicle desktop, the method further includes: obtaining second configuration information of the first application; obtaining, based on the second configuration information, the support status of the first application for a target display mode and the status of a function switch; and, if the first application corresponding to the application icon supports the target display mode, displaying at least one interface of the first application on the in-vehicle desktop in the target display mode, including: if the first application supports the target display mode and the function switch is on, then displaying the first application on the in-vehicle desktop in the target display mode; the function switch includes a switch for turning the target display mode on or off corresponding to the first application. In this way, the user can adjust the display method of the application by operating the function switch for the target display mode, thus facilitating user operation.

[0009] In one feasible implementation, after launching the in-vehicle desktop and displaying it on the vehicle's infotainment system, the method further includes: obtaining the user's wallpaper settings for the in-vehicle desktop; if the target display service is connected, updating the background wallpaper of the target display mode according to the wallpaper settings; after determining the first configuration information of the target display mode based on the first screen information, the method further includes: obtaining the display window of the background wallpaper according to the first configuration information; and displaying the background wallpaper in at least one display window. This allows for updating and displaying the background wallpaper, enabling users to update the wallpaper on the vehicle's infotainment system, while also reducing display issues caused by low activity levels during application launches.

[0010] In one feasible implementation, determining the first configuration information for the target display mode based on the first screen information further includes: calculating the window size of the in-vehicle desktop based on the first screen information; calculating the setting position and size of the display window when different applications are in the target display mode based on the window size of the in-vehicle desktop; and updating the first configuration information based on the setting position and size of the display window. This allows for the calculation of the overall window size of the in-vehicle desktop and the size and setting position of the display window within the in-vehicle desktop, thereby making the target display mode of the application more compatible with the in-vehicle screen and improving the display effect.

[0011] In one feasible implementation, the method further includes: detecting a user's click on a function switch displayed on the in-vehicle desktop or terminal device; turning the function switch on or off; and updating second configuration information based on the state of the function switch. In this way, the user can operate the function switch to switch application functions.

[0012] In one feasible implementation, the method further includes: updating wallpaper settings in response to a wallpaper change; changing the background wallpaper according to the updated wallpaper settings; and displaying the updated background wallpaper in a display window. This allows the user-set wallpaper to be displayed through a display window, improving the display effect while avoiding interference with ongoing activities.

[0013] In one feasible implementation, if the terminal device's screen is off, the first application is stopped from being displayed on the terminal device's screen; the terminal device's status information is obtained; if the terminal device is in a locked screen state or a vehicle-to-vehicle connection state, the visibility of the first application on the vehicle desktop is updated. In this way, the terminal device can update its own status and determine whether it still needs to provide vehicle desktop services to the vehicle-to-vehicle system when the screen is off. If the terminal device is connected to the vehicle-to-vehicle system, it will continue to provide vehicle desktop services to the vehicle-to-vehicle system even after its own screen is turned off.

[0014] In one feasible implementation, the method further includes: turning off the in-vehicle desktop when the terminal device is disconnected from the vehicle's infotainment system; and setting the connection status of the target display service to a disconnected state. This disconnects the in-vehicle desktop display, allowing the user to control the display status and terminate the display of the in-vehicle desktop and applications on the vehicle's infotainment system.

[0015] According to a second aspect of the embodiments of this application, a terminal device is provided, including: a display screen, a memory, and one or more processors; the display screen, the memory, and the processors are coupled; wherein, the memory stores computer program code, the computer program code including computer instructions, and when the computer instructions are executed by the processor, the terminal device performs the application adaptation method provided as in the first aspect and any feasible implementation thereof.

[0016] It is understood that the beneficial effects that the technical solution provided in the second aspect above can achieve can be referred to the beneficial effects of the first aspect and any feasible implementation thereof, which will not be repeated here. Attached Figure Description

[0017] Figure 1 This is a schematic diagram illustrating an application display after vehicle-machine interconnection.

[0018] Figure 2 This is a schematic diagram of the structure of a terminal device according to an embodiment of this application;

[0019] Figure 3 This is a schematic diagram of the layered architecture of a terminal device software system in an embodiment of this application;

[0020] Figure 4 This is a schematic diagram of the layered architecture of the in-vehicle desktop and parallel window manager functions in the embodiments of this application;

[0021] Figure 5 This is a schematic diagram of the software structure of the parallel window manager in the embodiments of this application;

[0022] Figure 6 This is a flowchart illustrating an application adaptation method in an embodiment of this application.

[0023] Figure 7 This is a timing diagram of an application adaptation method in an embodiment of this application;

[0024] Figure 8 This is a schematic diagram of a wallpaper update process according to an embodiment of this application;

[0025] Figure 9 This is a schematic diagram illustrating the display of a wallpaper background in an embodiment of this application;

[0026] Figure 10 This is a schematic diagram of a vehicle desktop display in an embodiment of this application;

[0027] Figure 11 This is a schematic diagram of an application startup process in an embodiment of this application.

[0028] Figure 12 This is a schematic diagram showing the function switches in an embodiment of this application;

[0029] Figure 13 This is a flowchart illustrating the process of turning on the function switch in an embodiment of this application;

[0030] Figure 14 This is a schematic diagram of another application startup process in an embodiment of this application;

[0031] Figure 15 This is a schematic diagram of the process of launching a first application in the target display mode according to an embodiment of this application;

[0032] Figure 16 This is a schematic diagram of a process for modifying the configuration of a display window in an embodiment of this application;

[0033] Figure 17 This is a schematic diagram of the process after a terminal device is disconnected from the vehicle-mounted terminal in an embodiment of this application;

[0034] Figure 18 This is a schematic diagram illustrating a process for turning off a display screen in an embodiment of this application;

[0035] Figure 19 This is a schematic diagram of the structure of an application adaptation system in an embodiment of this application. Detailed Implementation

[0036] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. Other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are all within the protection scope of this application.

[0037] In the following description, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with "first," "second," etc., may explicitly or implicitly include one or more of that feature. In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0038] Furthermore, in this application, directional terms such as "upper" and "lower" are defined relative to the orientation of the components shown in the accompanying drawings. It should be understood that these directional terms are relative concepts, used for relative description and clarification, and can change accordingly depending on the orientation of the components in the accompanying drawings.

[0039] With the development of automotive intelligence, users can use smart car connectivity products to connect their mobile phones and car systems while driving. Simply connect your phone in the car to share lifestyle services on your phone to the in-car screen, and experience and control different applications through the in-car screen.

[0040] However, existing in-vehicle infotainment systems, especially older ones, have screens of varying sizes and are characterized by horizontal orientation, irregular shapes, and low resolution. During the interconnection process between the in-vehicle infotainment system and a mobile phone, many applications are difficult to adapt to the in-vehicle screen due to the greater number of functions and applications on the phone and the differences in screen shape and resolution between the phone and the in-vehicle screen.

[0041] Figure 1 This is a schematic diagram of an application display after vehicle-machine interconnection.

[0042] like Figure 1 As shown, if the application is not adapted to the vehicle's irregular screen or landscape mode, it will be displayed directly on the vehicle's screen in the same way as on a mobile phone. This will result in the application's controls being too small and the unused window area being too large, leading to poor display of the application on the vehicle's screen. In some embodiments, display errors may also occur.

[0043] To address the aforementioned issues, this application provides an application adaptation method and terminal device. By adjusting the application to the target display mode of in-application split-screen during the display process, the area of ​​the in-vehicle desktop displayed when the vehicle-mounted terminal is connected to the terminal device is adjusted, thereby increasing the operability of the application and optimizing the display effect of the application on the vehicle-mounted terminal.

[0044] To facilitate a clear description of the technical solutions in the embodiments of this application, some terms and technologies involved in the embodiments of this application will be briefly introduced below:

[0045] An Activity is a crucial application component in the Android system, providing a platform for screen interaction. Each Activity receives a window for drawing its user interface; this window can fill the screen or be smaller and float on top of other windows. The activities described in this application are all Activities.

[0046] A stack is a linear data structure with restricted operations. The restriction is that insertion and deletion operations are only allowed at one end of the list, called the top of the stack, and the other end is called the bottom of the stack. When operating on a stack, pushing data onto the stack is called pushing, and removing data from the stack is called popping.

[0047] An application typically consists of multiple loosely connected Activities. Generally, a particular Activity is designated as the main Activity, which is the Activity presented to the user when the application is first launched.

[0048] Activities can navigate between each other to perform different actions. Whenever a new Activity starts, the old Activity stops, but the system retains it in a stack, specifically the back stack. When a new Activity starts, the system also pushes it onto the back stack and gains focus from the user. It's important to understand that the Activity at the top of the stack receives focus. When the user finishes the current Activity and clicks the back button, the system pops the current Activity from the top of the stack and destroys it, then returns to the previous Activity.

[0049] An Activity's lifecycle is the collection of states it goes through from beginning to end. For example, the process of an Activity going from nothing to something and back to nothing constitutes its lifecycle. An Activity will have at least four states during its lifecycle:

[0050] 1. When running (Active / Running), the Activity is in an active state. At this time, the Activity is at the top of the stack and is visible. Users can interact with the Activity by clicking or other means.

[0051] 2. Paused: When an Activity loses focus (i.e., it is not popped up but is covered by another Activity), it enters a paused state. The Activity is not destroyed, but it loses the ability to interact with the user. Its state information and variables are retained until it returns to the top of the stack or is automatically reclaimed by the system due to insufficient memory.

[0052] 3. Stopped: When an Activity is completely covered by the system, it enters the stopped state and is no longer visible, but the resources it occupies are not reclaimed by the system.

[0053] 4. System Recycling (Killed) is the end state of an Activity's lifecycle. After the system recycles an Activity, it will release the resources occupied by that Activity.

[0054] It should be understood that other transitional states may also be included among the above four states, thereby realizing the transformation of the above states, which will not be elaborated here.

[0055] AOSP, or Android Open Source Project, is an open-source operating system development project for Android. AOSP allows modification and addition of software within the Android system, providing interfaces and tools for implementing new features.

[0056] The technical solutions provided in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0057] In this embodiment, the user can connect to the vehicle's infotainment system via any terminal device with wired and / or wireless connectivity, thereby achieving interconnection between the terminal device and the vehicle's infotainment system. Therefore, the terminal device in this embodiment can be any terminal device with wired and / or wireless connectivity, such as a smartphone, tablet, laptop, personal computer (PC), personal digital assistant (PDA), etc. This embodiment does not impose any limitations on this.

[0058] For example, taking a mobile phone as the terminal device, Figure 2This is a schematic diagram of the structure of a terminal device in an embodiment of this application.

[0059] Reference Figure 2 As shown, the terminal device may include a processor 110, an external memory interface 120, an internal memory 121, a charging management module 140, a power management module 141, a battery 142, antenna 1, antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a display screen 193, a subscriber identification module (SIM) card interface 194, and a camera 195, etc. The sensor module 180 may include pressure sensors, gyroscope sensors, barometric pressure sensors, magnetic sensors, accelerometers, distance sensors, proximity sensors, fingerprint sensors, temperature sensors, touch sensors, ambient light sensors, bone conduction sensors, etc.

[0060] Processor 110 may include one or more processing units, such as: application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, memory, video codec, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0061] The controller can serve as the nerve center and command center of a terminal device. Based on the instruction opcode and timing signals, the controller generates operation control signals to control the fetching and execution of instructions.

[0062] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0063] In some embodiments, the processor 110 may include one or more interfaces. Interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0064] The external memory interface 120 can be used to store executable program code, including instructions. The external memory interface 120 may include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during the use of the terminal device (such as audio data, phonebook, etc.). Furthermore, the external memory interface 120 may include one or more storage units, such as volatile memory (e.g., dynamic random access memory, DRAM, static random access memory, SRAM), etc.; and non-volatile memory (NVM), such as read-only memory (ROM), flash memory, etc. The processor 110 executes various functional applications and data processing of the terminal device by running instructions stored in the external memory interface 120 and / or instructions stored in memory located in the processor.

[0065] Internal memory 121 may include one or more random access memory (RAM) and one or more non-volatile memory (NVM). The RAM can be directly read and written by the processor 110 and can be used to store executable programs (e.g., machine instructions) of the operating system or other running programs, as well as user and application data. The NVM can also store executable programs and user and application data, and can be pre-loaded into the RAM for direct read and write operations by the processor 110.

[0066] The charging management module 140 is used to receive charging input from a power supply device (such as a charger, laptop power supply, etc.). The charger can be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 can receive charging input from the wired charger via the USB interface 130. In some wireless charging embodiments, the charging management module 140 can receive wireless charging input via the wireless charging coil of the terminal device.

[0067] While charging the battery 142, the charging management module 140 can also supply power to the terminal device through the power management module 141. Specifically, the battery 142 can be composed of multiple batteries connected in series. The power management module 141 is used to connect the battery 142, the charging management module 140, and the processor 110.

[0068] The power management module 141 connects the battery 142, the charging management module 140, and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140, providing power to the processor 110, internal memory 121, display screen 193, camera 195, and wireless communication module 160, etc. The power management module 141 can also monitor parameters such as battery voltage, current, battery cycle count, and battery health status (leakage current, impedance). In some other embodiments, the power management module 141 may also be located within the processor 110.

[0069] The wireless communication function of the terminal device can be implemented through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem, and baseband processor.

[0070] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in the terminal device can be used to cover one or more communication frequency bands. In some embodiments, the antennas can be used in conjunction with a tuning switch, and different antennas can be multiplexed to improve antenna utilization.

[0071] The mobile communication module 150 can provide solutions for wireless communication applications including 2G / 3G / 4G / 5G on terminal devices. The mobile communication module 150 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1. In some embodiments, at least some functional modules of the mobile communication module 150 can be housed in the processor 110. In some embodiments, at least some functional modules of the mobile communication module 150 and at least some modules of the processor 110 can be housed in the same device.

[0072] The modem processor may include a modulator and a demodulator. The modulator modulates the low-frequency baseband signal to be transmitted into a mid-to-high frequency signal. The demodulator demodulates the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After processing by the baseband processor, the low-frequency baseband signal is transmitted to the application processor. The application processor outputs sound signals through audio devices (not limited to speaker 170A, receiver 170B, etc.) or displays images or videos through the display screen 193. In some embodiments, the modem processor may be a separate device. In other embodiments, the modem processor may be independent of the processor 110 and may be housed in the same device as the mobile communication module 150 or other functional modules.

[0073] The wireless communication module 160 may include a Wi-Fi module, a Bluetooth (BT) module, a GNSS module, a near-field communication (NFC) module, an infrared (IR) module, etc. The wireless communication module 160 may be one or more devices integrating at least one of the above modules. The wireless communication module 160 receives electromagnetic waves via antenna 2, modulates and filters the electromagnetic wave signal, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, modulate and amplify them, and then convert them into electromagnetic waves for radiation via antenna 2.

[0074] Display screen 193 is used to display images, videos, etc. Display screen 193 includes a display panel. The display panel may be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a Mini LED, a MicroLED, a Micro-OLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, the terminal device may include one or N displays 193, where N is a positive integer greater than 1.

[0075] A touch sensor, also known as a "touch device," can be coupled to a display screen 193 to form a touchscreen, also called a "touch display." The touch sensor detects touch operations applied to or near it. It transmits the detected touch operation to an application processor to determine the type of touch event. Visual output related to the touch operation can be provided via the display screen 193. In other embodiments, the touch sensor may be located on the surface of the terminal device, in a different position than the display screen 193.

[0076] A pressure sensor is used to sense pressure signals and convert them into electrical signals. In some embodiments, the pressure sensor may also be coupled to the display screen 193. There are many types of pressure sensors, such as resistive pressure sensors, inductive pressure sensors, and capacitive pressure sensors. When a touch operation is applied to the display screen 193, the terminal device monitors the intensity of the touch operation based on the pressure sensor. The terminal device can also calculate the touch location based on the monitoring signal from the pressure sensor. In some embodiments, touch operations applied to the same touch location but with different touch operation intensities can correspond to different operation commands.

[0077] The SIM card interface 194 is used to connect a SIM card. The SIM card can be inserted into or removed from the SIM card interface 194 to achieve contact and separation with the terminal device. The terminal device can support one or more SIM card interfaces. The SIM card interface 194 supports Nano SIM cards, Micro SIM cards, and other SIM cards. Multiple cards can be inserted into the same SIM card interface 194 simultaneously. The SIM card interface 194 is also compatible with external memory cards. The terminal device interacts with the network through the SIM card to achieve functions such as calls and data communication. One SIM card corresponds to one user number.

[0078] It is understood that the interface connection relationships between the modules illustrated in the embodiments of the present invention are merely illustrative and do not constitute a structural limitation on the terminal device. In other embodiments of this application, the terminal device may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments. Meanwhile, the above... Figure 2 The illustration shown is merely an example when the terminal device is a mobile phone. If the terminal device is a tablet, handheld computer, PC, PDA, wearable device (such as a smartwatch, smart bracelet), or other device form factor, the structure of the terminal device may include more advanced features. Figure 2 The fewer structures shown can also include more than Figure 2 The structures shown are not limited here.

[0079] It should be understood that in order to connect with the terminal device and display and control the content displayed on the terminal device, the vehicle screen on the vehicle terminal has the same function as the display screen 193 in the terminal device. The vehicle screen also needs to be coupled with a touch sensor and / or a pressure sensor to receive the user's click operation on the vehicle screen.

[0080] Furthermore, in order to connect with terminal devices, the vehicle-mounted system also needs to be equipped with a wired communication module and / or a wireless communication module. This allows it to communicate with the terminal devices via any of the connection methods such as Wi-Fi, Bluetooth, and USB. The vehicle-mounted system can then connect with the terminal devices to experience and control the application services of the terminal devices on the in-vehicle screen.

[0081] It should be noted that the connection method between the vehicle-mounted system and the terminal device in this application is only one example; there are other ways to achieve the connection between the vehicle-mounted system and the terminal device.

[0082] It is understandable that, generally speaking, the implementation of terminal device functions requires not only hardware support but also software cooperation. The software system of a terminal device can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This application's embodiment uses a layered architecture... Taking the system as an example, the software structure of the terminal device is illustrated.

[0083] Figure 3 This is a schematic diagram of a layered architecture for a terminal device software system according to an embodiment of this application. The layered architecture divides the software into several layers, each with a clear role and division of labor. The layers communicate with each other through software interfaces (e.g., APIs).

[0084] In some examples, such as Figure 3 As shown in this embodiment, the software of the terminal device is divided into five layers, from top to bottom: application layer, framework layer, system library and Android runtime, HAL layer (hardware abstraction layer), and driver layer (or kernel layer). The system library and Android runtime can also be called the native framework layer, and the framework layer can also be called the application framework layer.

[0085] The application layer can include a series of applications. For example... Figure 3 As shown, the application layer can include applications (APPs) such as camera, gallery, calendar, map, WLAN, Bluetooth, music, video, SMS, call, navigation, and instant messaging.

[0086] The framework layer provides application programming interfaces (APIs) and programming frameworks for applications in the application layer. The application framework layer includes predefined functions or services. For example, the application framework layer may include an activity manager, window manager, content provider, audio service, view system, phone manager, resource manager, notification manager, package manager, etc., but this embodiment does not impose any limitations on these.

[0087] The window manager is used to manage windowed applications. It can retrieve screen size, determine the presence of a status bar, lock the screen, and capture screenshots, among other things.

[0088] Content providers store and retrieve data, making that data accessible to applications. This data can include videos, images, audio, phone calls made and received, browsing history and bookmarks, phone books, etc.

[0089] A view system includes visual controls, such as controls for displaying text and controls for displaying images. View systems can be used to build applications. A display interface can consist of one or more views. For example, a display interface including a text notification icon could include views for displaying text and views for displaying images.

[0090] A phone manager is used to provide communication functions for terminal devices. For example, a phone manager can manage the call status of a calling application (including initiation, connection, and termination).

[0091] The file explorer provides applications with various resources, such as localized strings, icons, images, layout files, video files, and more.

[0092] The notification manager allows applications to display notifications in the status bar. These notifications can be used to deliver informational messages and can disappear automatically after a short pause, requiring no user interaction. For example, the notification manager can be used to notify users of download completion or message alerts. The notification manager can also display notifications as icons or scrolling text in the top status bar, such as notifications from background applications, or as dialog boxes on the screen. Examples include displaying text messages in the status bar, emitting sounds, vibrating the device, and flashing indicator lights.

[0093] Package manager in The package manager is used to manage application packages. It allows applications to obtain detailed information about installed applications and their services, permissions, etc. The package manager is also used to manage events such as application installation, uninstallation, and upgrades.

[0094] The system library can include multiple functional modules. For example: a surface manager, media libraries, OpenGL ES, and SGL. The surface manager manages the display subsystem and provides 2D and 3D layer blending for multiple applications. The media libraries support playback and recording of various common audio and video formats, as well as still image files. The media libraries support various audio and video encoding formats, such as MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG. OpenGL ES is used for 3D graphics drawing, image rendering, compositing, and layer processing. SGL is a 2D graphics engine.

[0095] The Android runtime consists of the core libraries and the ART virtual machine. The Android runtime is responsible for scheduling and managing the Android system. The core libraries comprise two parts: one part contains the functionalities that Java code needs to call, and the other part consists of the Android core libraries. The application layer and application framework layer run in the ART virtual machine. The ART virtual machine executes the Java files of the application layer and application framework layer into binary files. The ART virtual machine is used for managing object lifecycles, stack management, thread management, security and exception management, and garbage collection.

[0096] The Hardware Abstraction Layer (HAL) is the interface layer between the operating system kernel and the hardware circuitry, designed to abstract the hardware. It hides the platform-specific hardware interface details, providing the operating system with a virtual hardware platform that is hardware-independent and portable across multiple platforms. The HAL provides a standard interface that exposes device hardware functionality to the higher-level Java API framework (i.e., the framework layer). The HAL contains multiple library modules, each implementing an interface for a specific type of hardware component, such as: audio HAL, Bluetooth HAL, camera HAL (also known as camera HAL or camera hardware abstraction module), and sensors HAL (or i-sensor service).

[0097] The kernel layer is the layer between hardware and software. The kernel layer includes at least display drivers, camera drivers, audio drivers, sensor drivers, battery drivers, etc., but this application does not limit this. Specifically, the sensor drivers can include drivers for each sensor included in the terminal device, such as a pressure sensor driver.

[0098] In this embodiment, the application layer also includes smart mobility. Specifically, smart mobility may include an in-vehicle desktop, a connection management module, a projection management module, and an in-vehicle parallel view management module. The in-vehicle desktop is the software system that provides display content for the in-vehicle screen after the terminal device is connected to the in-vehicle infotainment system. The connection management module manages the connection between the terminal device and the in-vehicle infotainment system, providing connection services and monitoring for the terminal device. The projection management module manages and controls the in-vehicle desktop projected to the in-vehicle infotainment system. The in-vehicle parallel view management module manages the display mode of split-screen within the application through a parallel window manager (MagicWindowManager).

[0099] Through smart mobility in the application layer, terminal devices can be connected to the vehicle's infotainment system, and then the various modules within the system can be used to achieve display adaptation of applications on the vehicle's infotainment system.

[0100] The framework layer also includes a parallel window manager (MagicWindowManager), which can manage the customized services of the software system in this application. Its main function is to encapsulate a series of strategy interfaces by combining multiple data modules within the service, to manage the startup, management, and display processes of Activities in the native application framework layer, and to execute the strategies of the parallel window service (MagicWindowService), thereby providing a basic framework for various applications to implement in-application split-screen functionality through the in-vehicle desktop, i.e., parallel view mode (MagicWindow).

[0101] It should be understood that Parallel View is merely a description of in-application split-screen in this application embodiment; correspondingly, Parallel View mode can also be used to refer to the in-application split-screen function. In this way, the in-vehicle desktop can achieve functions such as connection, screen projection, and display by calling the aforementioned management module.

[0102] Figure 4 This is a schematic diagram of the layered architecture of the in-vehicle desktop and parallel window manager functions in an embodiment of this application. Figure 5 This is a schematic diagram of the software structure of the parallel window manager in the embodiments of this application.

[0103] It should be noted that, Figure 4 The layered architecture of the software system shown is an exemplary implementation of the intelligent mobility and parallel window manager functions, therefore, except Figure 4 In addition to the layered architecture shown in the figure, the layered architecture in the embodiments of this application also includes Figure 3 The content shown.

[0104] like Figure 4 As shown, in order to enable the terminal device to display content on the in-vehicle screen after connecting to the in-vehicle infotainment system, the terminal device can utilize the in-vehicle desktop in the application layer, thereby enabling the in-vehicle screen to display the applications and services on the terminal device when connected to the in-vehicle infotainment system.

[0105] Terminal devices can modify the existing AMS (ActivityManagerService) and WMS (WindowManagerService) through AOSP, and add interfaces in FWK (Framework Layer) to implement the functions of parallel window manager and smart travel.

[0106] In smart mobility, different functional modules are placed in the application layer and business platform respectively. Among them, the in-vehicle desktop is an application used to project the screen of the in-vehicle system onto the terminal device through the connection between the terminal device and the in-vehicle system. Figure 4 The business middle platform shown is an integration of services called from the application layer. In some embodiments of this application, such as... Figure 3 As shown, the management module in the business middle platform can also be set in the application layer to support smart mobility functions. It should be understood that during actual operation, the in-vehicle desktop can project its screen onto the vehicle's infotainment system and control it by calling the management module in the business middle platform, or it can directly call the corresponding service interface of the management module to achieve the same function. This application does not restrict the method by which the in-vehicle desktop calls services.

[0107] like Figure 4As shown, the various functional modules in FWK are mainly used to realize in-application split-screen display and control on the vehicle's in-vehicle screen. FWK includes AOSP, Parallel View Service, and common window capabilities. Among them, AOSP allows modification and addition of AMS and WMS, enabling the software system to control the displayed content and effects after the terminal device is connected to the vehicle's in-vehicle screen.

[0108] The Parallel View service can achieve in-app split-screen functionality on the vehicle's desktop and display it on the vehicle's screen via functional modules. Window common capabilities control the windows displayed on the vehicle's desktop through these functional modules. It should be understood that, in this embodiment, the Parallel View service is... Figure 3 The parallel window manager (MagicWindowManager) shown.

[0109] The Parallel View service needs to be implemented through the interface layer, business layer, and data layer. The in-vehicle Parallel View management module in the business middle platform can use the Parallel View service to call the functional modules in the interface layer, business layer, and data layer to achieve intra-business screen splitting.

[0110] The interface layer includes an EasyGo interface and an E / F interface. The EasyGo interface is a fast access protocol interface. Through the EasyGo interface, the Parallel Vision Management Module can quickly call the corresponding function modules of Parallel Vision in FWK to provide configuration support for the vehicle desktop to enter Parallel Vision mode.

[0111] The E / F interface enables the Parallel View management module to call the function module that adjusts and controls the configuration of windows and other elements in the Parallel View mode, thereby controlling the Parallel View mode in the vehicle desktop.

[0112] The business layer includes an AMS extension, a WMS extension, and a UX (User Experience) interaction subsystem. The AMS extension includes lifecycle management, stack management, mode switching, configuration, and homepage identification. Lifecycle management represents the state of an Activity; it should be understood that during application display, an Activity can be considered a window or interface. Stack management manages Activities pushed onto the stack, mode switching controls the display mode for parallel viewports, configuration is used to configure Activities, and homepage identification identifies the application's main display page.

[0113] WMS extensions include window coordinates, screen rotation, window animations, status bar, window hierarchy, window scaling, and screen collapsibility. WMS is used to manage windows, including creating, modifying, and deleting them, as well as setting a window as the focus. Through these WMS extensions, WMS can acquire and manage window information. It should be understood that... Figure 4 The functions and extensions of WMS in China Figure 3 The window manager shown in the paper is similar, which can obtain the window size, determine whether there is a status bar, lock the screen, capture the screen, resize the window, rotate the screen, switch between folded screens, etc., which will not be described in detail in this application.

[0114] The UX interaction subsystem is the subsystem that enables user interaction, including background wallpaper, window dragging, and gesture interaction. Specifically, by invoking the UX interaction subsystem, the in-vehicle desktop can display a background wallpaper, which can be changed based on user actions. Furthermore, by collecting user gestures and actions, windows can be dragged or other operations performed. For example, the UX interaction subsystem can call functional modules in the WMS to modify or delete windows.

[0115] The data layer includes cloud data, EasyGo data, application switch data, and local configuration. Cloud data is data stored on a cloud server by the terminal device; EasyGo data provides configuration parameters for the EasyGo interface; application switch data provides users with settings for the application's own function switches; and local configuration is the terminal device's own configuration information.

[0116] The window resizing, focus switching, and common window animations in the window's common capabilities can be achieved either by calling the interface individually or by calling WMS to manage and control the window as a whole.

[0117] It should be noted that the AMS and WMS in AOSP have the same target objects as the functional modules with the same names in the AMS and WMS extensions in the business layer. Functional modules with the same names can be connected to achieve unified calls through interfaces. Furthermore, the functional modules in the AMS and WMS extensions may have more or fewer functions than the functional modules with the same names in AMS and WMS, and this application does not impose any restrictions on this.

[0118] like Figure 5As shown, the parallel window manager (MagicWindowManager) may include: an activity task management service module (ActivityTaskManagerService), a first activity launcher (xxActivityStarter), a second activity launcher (ActivityStarter), a parallel window management service module (MagicWindowManagerService), a parallel activity trigger (MagicActivityStarter), a window manager (MagicWinManager), a mode switching module (MagicModeSwitcher), a window mode management module (MagicModeA1An), a mode container module (MagicContainer), a parallel window configuration module (MagicWindowConfig), a configuration loading module (MagicWindowConfigLoader), a parallel mode base module (MagicModeBase), a configuration container module (ConfigurationContainer), an activity record module (ActivityRecord), a window container module (WindowContainer), a task execution module (Task), a startup window control module (StartingSurfaceController), and a wallpaper module (MagicWallpaper).

[0119] It should be understood that the aforementioned modules can be set as part of the MagicWindowManager, or they can be set in other modules in the software architecture, such as AMS, WMS, etc. When the functions of the above modules need to be applied, the MagicWindowManager can call the modules in the above modules through commands to achieve the corresponding functions. Therefore, in this application... Figure 5 The module structure shown is only one feasible implementation in this application, and this application does not limit the specific structure of the parallel window manager (MagicWindowManager). The parallel window manager (MagicWindowManager) can be called by the in-vehicle parallel view management module to provide in-application split-screen services for applications on the in-vehicle desktop.

[0120] The following describes the functionality of the parallel window manager (MagicWindowManager) or its called modules.

[0121] The ActivityTaskManagerService module receives instructions and controls the initiation of activities, thereby controlling the launch of activities. For example, the ActivityTaskManagerService module can also be configured to... Figure 4 The in-vehicle parallel view management module in the business platform shown receives and responds to click commands from the in-vehicle desktop. It should be understood that the location of the activity task management service module is merely an exemplary implementation, and the specific location of the activity task management service module is not limited in this application.

[0122] For example, in some embodiments, the ActivityTaskManagerService module can also be set in AMS to replace the corresponding activity launch function in AMS.

[0123] The first activity launcher (xxActivityStarter) and the second activity launcher (ActivityStarter) can receive instructions from the ActivityTaskManagerService module to start the corresponding activity.

[0124] The MagicWindowManagerService module manages the windows displayed on the device, enabling them to execute parallel view strategies and prepare for parallel view display, facilitating subsequent parallel view decisions and display.

[0125] The MagicActivityStarter is used to decide whether an application should launch in parallel view mode. For example, it can make this decision by calling a functional module to detect whether the application supports parallel view mode. If the MagicActivityStarter receives information that the application supports parallel view mode, it can decide to display the application in parallel view mode.

[0126] Window Manager (MagicWinManager): It can manage the in-vehicle screen and the display screen 193 of the terminal device, realize the interaction of windows in multiple devices, and send focus transfer commands to the mode switching module (MagicModeSwitcher).

[0127] The mode switching module (MagicModeSwitcher) is used to respond to commands sent by the window manager and focus the display on the in-vehicle screen of the vehicle terminal. It should be understood that since the software system in this embodiment is applied to a terminal device, the display screen 193 on the terminal device can be used as a physical screen within the software system, allowing the software system to control the display. Because the in-vehicle screen is connected to the terminal device via a communication connection or screen projection connection, to avoid data errors when the terminal device controls the in-vehicle screen, it can use the in-vehicle desktop as a virtual screen to set window configuration information. The settings of the virtual screen can then be projected onto the in-vehicle screen using the screen projection function to achieve screen settings and reduce the number of interactions, thereby reducing transmission time. Simultaneously, it ensures that the configuration information in the virtual screen does not interfere with the configuration information on the physical screen, improving configuration efficiency.

[0128] The window mode management module (MagicModeA1An) can call the parallel window configuration module (MagicWindowConfig) to obtain the preset boundaries of each window when connected to the vehicle's infotainment system. This allows for the determination of the size and position of each window, enabling the planning of display positions for parallel view mode and facilitating in-application split-screen display. Furthermore, it can determine the number of displayed activities and reset the boundaries for each activity.

[0129] The MagicContainer module updates the window size for the MagicWindowConfig module, allowing the MagicWindowConfig module to set limits for window sizes in different locations for in-vehicle infotainment scenarios.

[0130] Parallel Window Configuration Module (MagicWindowConfig): It can receive window update information and reconfigure the size, boundaries, position and other information of the window to make the in-vehicle screen on the vehicle terminal adapt to different applications. At the same time, it can also obtain the preset boundaries of each window when connected to the vehicle terminal from the Parallel Mode Base Module (MagicModeBase) to provide configuration data for the Window Mode Management Module (MagicModeA1An).

[0131] Furthermore, the parallel window configuration module (MagicWindowConfig) can also receive application switch data through the parallel window management service module (MagicWindowManagerService) to update the application switch status.

[0132] The configuration loading module (MagicWindowConfigLoader) can obtain the on / off status of the current application through the parallel window configuration module (MagicWindowConfig), thereby determining whether the current application can be displayed in parallel view mode.

[0133] The Parallel Mode Base module (MagicModeBase) stores the basic window configuration for the parallel view mode. It also receives updates to window boundaries from the window mode management module (MagicModeA1An), allowing for the setting of appropriate window boundaries for each application requiring adaptation. Furthermore, the Parallel Mode Base module (MagicModeBase) can set and update data in the Configuration Container module (ConfigurationContainer) to facilitate subsequent window modifications for the parallel view mode.

[0134] Configuration Container module: It can receive modification and update information of the configuration, thereby updating the configuration of the display window of the parallel view.

[0135] The ActivityRecord module records application activities, such as starting an activity, opening a new window, and refreshing parallel view configuration information, to document changes generated by these activities. It's important to note that in practice, the ActivityRecord module is managed by the Task module and is used to record changes in activities during task execution.

[0136] The WindowContainer module can receive instructions to overwrite and modify the window's configuration, such as changing the window's position and size, and update the window through the Task module.

[0137] The Task execution module (Task) can receive activity launch signals sent by the second ActivityStarter to launch the corresponding activity, and can also receive window configuration information to modify the window configuration. Specifically, the Task execution module (Task) can be managed by a screen management module (displaycontent (not shown in the figure)) for managing screen display. The screen management module can manage the display content of the entire screen. Taking this embodiment as an example, the screen management module can manage the virtual screen of the in-vehicle desktop.

[0138] The StartingSurfaceController module can obtain the activities that the Task execution module needs to display in order to control the desktop to display the corresponding start window.

[0139] The MagicWallpaper module is used to set the background displayed on the in-vehicle infotainment system as the background wallpaper for the parallel view mode.

[0140] Based on the above Figure 2 The structure of the terminal device shown in the figure, and Figure 3 , Figure 4 and Figure 5 The software architecture shown below, combined with Figure 6 and Figure 7 The content in the document will be used to illustrate the application adaptation method in this application.

[0141] Figure 6 This is a flowchart illustrating an application adaptation method in an embodiment of this application. Figure 7 This is a timing diagram of an application adaptation method in an embodiment of this application.

[0142] In this embodiment, users can utilize the applications and hardware settings in their terminal devices to achieve interconnection with the vehicle's infotainment system while simultaneously adapting the applications on the terminal device to the vehicle's in-vehicle screen, thereby improving the display effect of the application interface and enhancing the user experience. For example... Figure 6 As shown, the method includes:

[0143] S100: Establishes a screen mirroring connection with the vehicle's infotainment system.

[0144] In this embodiment of the application, the terminal device is as described above. Figure 2 The terminal device shown is illustrated as an example. Therefore, in this embodiment, the terminal device can be a mobile phone, and the terminal device is equipped with a wireless communication module 160 and a universal serial bus interface, etc., for wireless or wired communication. Therefore, when the terminal device establishes a connection with the vehicle's infotainment system using a mobile phone-vehicle infotainment system smart interconnection product, interconnection can be achieved through wireless or wired connections.

[0145] It should be understood that this application does not restrict the connection method between the terminal device and the vehicle-mounted terminal; the connection method can be either wired or wireless.

[0146] like Figure 4 and Figure 7As shown, after the terminal device connects to the vehicle's infotainment system via the interconnection product, the connection management module can send a connection success signal to the interconnection product, thus informing the interconnection product of the successful connection. The interconnection product can be an application in the application layer of the terminal device's software system, and this application can call the connection management module. In some embodiments, the establishment of a connection between the terminal device and the vehicle's infotainment system via the interconnection product actually involves the interconnection product calling the connection management module to establish the connection between the terminal device and the vehicle's infotainment system, and then the connection management module sending a connection success notification to the interconnection product.

[0147] It should be noted that the above embodiments are only one feasible implementation method in this application. After the terminal device and the vehicle terminal are interconnected, the connection management module may not send a connection success message to the interconnected product, but may directly proceed to subsequent steps.

[0148] S200: Obtain the first screen information from the vehicle's infotainment system.

[0149] The first screen information contains the configuration information of the vehicle-mounted screen on the in-vehicle infotainment system, such as screen size, screen resolution, and desktop display settings. The in-vehicle screen is the device used for display on the in-vehicle infotainment system. Because the size and shape of the in-vehicle screen differ from the display screen 193 of the terminal device, the resolution and other parameters of the in-vehicle screen are also different from those of the display screen 193. After the two are connected, if the in-vehicle screen directly displays the content displayed on the display screen 193, there will be issues such as the display controls being too small, display misalignment, and ineffective operation.

[0150] Therefore, by obtaining the first screen information from the vehicle's infotainment system, applications in the terminal device can be adapted according to the corresponding screen information, thereby improving the efficiency of application adaptation and enhancing the display effect of the in-vehicle screen.

[0151] like Figure 6 and Figure 7 As shown, information such as the display size and window size of the in-vehicle screen can be obtained through connected products, thereby obtaining the first screen information of the in-vehicle system.

[0152] It should be understood that after establishing a connection with the terminal device, the vehicle-mounted system can directly send the first screen information to the connected product, thereby enabling the terminal device to obtain the first screen information corresponding to the vehicle-mounted screen.

[0153] S300: Start the in-vehicle desktop and display it on the vehicle's infotainment system.

[0154] After the terminal device establishes a connection with the vehicle's infotainment system and obtains the first screen information, the connection management module can notify the in-vehicle desktop to start. The in-vehicle desktop can serve as a desktop displaying different application icons from the terminal device. Simultaneously, from the terminal device's perspective, the in-vehicle desktop can act as a virtual screen to distinguish it from the terminal device's display screen 193, thereby separating the in-vehicle screen from the terminal device's display screen 193.

[0155] For example, in order to identify the in-vehicle scenario, i.e. the in-vehicle desktop is a virtual screen and the terminal device's display screen 193 is a physical screen, the in-vehicle system can set a root task execution module (rootTask). Through the root task execution module (rootTask), the in-vehicle desktop can be customized according to the in-vehicle screen conditions and the status of the target application to be launched, adjusting the window display level, window visibility, window display mode, etc. of the target application. The task execution module (Task) called by the target application in the terminal device's software architecture can be used for the management of activities within the terminal device.

[0156] It should be noted that in this step, the in-vehicle desktop displayed on the in-vehicle screen is in an unsplit-screen state because no applications are displayed, thus allowing the entire in-vehicle desktop to be displayed.

[0157] like Figure 7 As shown, after the in-vehicle desktop is displayed on the in-vehicle screen, if the desktop is successfully displayed, it can send a connection success message to the connection management module, thereby triggering subsequent operations by the connection management module. Upon receiving the connection success notification, the connection management module can send the connection success message to the parallel view management module, enabling the parallel view management module to configure the current parallel view mode.

[0158] In some embodiments, after receiving the first screen information, the connection management module can simultaneously send a connection success message to both the vehicle's desktop and the parallel view management module, thereby activating the vehicle's desktop and parallel view mode. Furthermore, to ensure better performance when applications are displayed in parallel view mode, the connection management module, while transmitting the connection success message, also sends the acquired first screen information to the parallel view management module, making the parallel view mode configuration obtained by the parallel view management module more compatible with the vehicle's screen.

[0159] To improve the display of the in-vehicle desktop, users can set the wallpaper after the desktop is displayed. Users can then change the wallpaper and perform other operations through their terminal devices and / or the in-vehicle system.

[0160] After the terminal device connects to the vehicle's infotainment system via the connection management module, the terminal device can obtain the user's operations on the in-vehicle desktop through the in-vehicle screen. Therefore, the process of updating or replacing the wallpaper on the in-vehicle desktop can be achieved by obtaining the user's wallpaper settings through the in-vehicle screen or the terminal device.

[0161] The user can set the wallpaper for the in-vehicle desktop by either inputting an image into the in-vehicle system or a terminal device and setting it as the in-vehicle desktop wallpaper, or by selecting a wallpaper from the wallpapers stored on the terminal device or in-vehicle system and setting it as the in-vehicle desktop wallpaper. This application does not restrict the method of receiving wallpaper update instructions.

[0162] Figure 8 This is a schematic diagram illustrating a wallpaper update process according to an embodiment of this application. Figure 9 This is a schematic diagram illustrating the display of a wallpaper background in an embodiment of this application.

[0163] like Figure 8 As shown in (a), the parallel window manager (MagicWindowManager) may also include a window management listener (MagicWindowManagerEx). The window management listener (MagicWindowManagerEx) can respond to user actions in the window and send the listened-up events to the corresponding processing modules. Figure 8 As shown in the example, the window management listener (MagicWindowManagerEx) can receive the signals that the user inputs to the in-vehicle desktop through the vehicle's infotainment system and transmit them to the corresponding processing module.

[0164] In this embodiment, the terminal device can obtain the user's operation on the in-vehicle desktop displayed on the vehicle's infotainment system through the connection management module. Then, the connection management module can send a connection success notification to the in-vehicle parallel view management module, and then the in-vehicle parallel view management module generates a wallpaper setting command and sends it to the window management listener (MagicWindowManagerEx), so that it can send the wallpaper setting instruction to the parallel window management service module (MagicWindowManagerService) for processing, so that the parallel window management service module (MagicWindowManagerService) can manage and operate the window that is displayed.

[0165] In this embodiment, when dividing the in-vehicle desktop window according to the target display mode, if the first application only starts one activity, that activity can occupy only one display window in the target display mode, while other display windows in the target display mode are inactive. To avoid empty display windows in inactive states, wallpaper can be displayed in these windows to fill the blank spaces. Simultaneously, to reduce the impact of the wallpaper on display windows showing active content, the wallpaper can be blurred to add special effects, thus better displaying the active content through the display windows. Here, the display window is a window in the target display mode used for split-screen application display.

[0166] For example, the parallel window manager (MagicWindowManager) may also include a wallpaper blur management module (MagicWallpaperBlurController). After receiving the instruction to set the wallpaper, the parallel window management service module (MagicWindowManagerService) can blur the wallpaper through the wallpaper blur management module (MagicWallpaperBlurController) and display the blurred wallpaper through an inactive display window.

[0167] It should be noted that users can also change their wallpaper using the steps described above. For example... Figure 8 As shown in (b), users can send wallpaper change commands to terminal devices via the vehicle's infotainment system. For example, a user can send a notification of a wallpaper change to the vehicle's parallel view management module through operations on the vehicle's desktop. The window management listener (MagicWindowManagerEx) can then forward the wallpaper change command to the parallel window management service module (MagicWindowManagerService) for processing, so that it changes the wallpaper currently displayed on the vehicle's desktop.

[0168] and Figure 8 The process of setting the wallpaper shown in (a) is different from that shown in (a). Figure 8 The wallpaper change operation shown in (b) requires clearing the old wallpaper first through the wallpaper blur management module (MagicWallpaperBlurController) in a scenario where wallpaper blurring is needed, and then setting the new wallpaper to achieve the wallpaper replacement process.

[0169] It should be understood that the above process of setting and changing wallpaper only involves blurring the set or changed wallpaper, and does not involve displaying it.

[0170] Therefore, in some embodiments of this application, the parallel window manager (MagicWindowManager) may also include a task processing module (TaskEX). For example... Figure 8 As shown in (c), after the parallel window management service module (MagicWindowManagerService) receives the instruction to set or change the wallpaper, it can send an instruction to load the wallpaper to the task execution module (Task). Then, the task execution module (Task) loads the wallpaper through the task processing module (TaskEX) and calls the wallpaper module (MagicWallpaper) to update the display background of the vehicle desktop.

[0171] Furthermore, to enable the display of wallpapers processed by the MagicWallpaperBlurController module, the MagicWallpaper module can set a blur layer on the background of the in-vehicle desktop after receiving an update to the display background. The wallpaper can then be written to the virtual screen, i.e., the in-vehicle desktop. The MagicWallpaper module can also obtain a screenshot of the wallpaper corresponding to the display window from the MagicWallpaperBlurController module, thereby displaying the wallpaper on the in-vehicle desktop.

[0172] like Figure 9 As shown in (a) and (b), the wallpaper can be changed through the vehicle's infotainment system, thereby covering the inactive display windows in the target display mode with a blurred wallpaper, thus improving the aesthetics of the display.

[0173] It should be understood that during the wallpaper display process, the display window for the background wallpaper needs to be determined based on the first configuration information and the position and size of the display window first invoked during application execution, in order to avoid obscuring the application that needs to be displayed. Then, the background wallpaper is displayed in at least one display window. The first configuration information can be obtained through step S400 below, and in scenarios where the application displays multiple activities simultaneously, the display window for the background wallpaper can be appropriately reduced or the background wallpaper can be not displayed.

[0174] Similarly, when changing the wallpaper, the MagicWindowManager responds to the wallpaper change by updating the wallpaper settings, then changes the background wallpaper based on the updated settings, and finally displays the updated background wallpaper through the display window. It should be noted that the above-described process of setting and changing the background wallpaper is only one feasible implementation method in this application. In practical applications, other methods can also be used to set and change the background wallpaper, which will not be elaborated upon here.

[0175] In this embodiment, the background wallpaper is displayed using a display window on the vehicle desktop that is not occupied by an application. Therefore, when all display windows on the vehicle desktop are called by applications, the background wallpaper does not need to be displayed on the vehicle's infotainment system.

[0176] S400: First configuration information for determining the target display mode based on the first screen information.

[0177] The first configuration information includes the setting position and size of the application window to be displayed, and the target display mode is also a name for the in-application split-screen display, that is, the target display mode is the parallel view mode.

[0178] like Figure 7 As shown, after receiving a successful connection message from the vehicle-mounted system, the Parallel View Management module can send a connection success message to the Parallel View module, thereby informing the Parallel View module of the current connection status. Based on this, the Parallel View Management module can also calculate the display window for the Parallel View mode, thus obtaining the configuration of the basic display window for the Parallel View mode. The Parallel View module is a module that provides target display mode services for applications. In this embodiment, the Parallel View module can be a parallel window manager (MagicWindowManager) called by the Parallel View Management module.

[0179] In some embodiments, configuration information for the display window can be calculated based on the first screen information. For example, the parallel view mode includes two display windows. Therefore, during the calculation of configuration information, the display area of ​​the vehicle screen can be divided into two areas of the same size, which serve as the first window and the second window, respectively, for application display in subsequent steps.

[0180] Figure 10 This is a schematic diagram of a vehicle-mounted desktop display according to an embodiment of this application. See also... Figure 10When displaying content, in-vehicle screens often include a navigation bar, or dock area, to guide user operations. However, in some implementations, the navigation bar on the in-vehicle screen is drawn using the view function in the Android system. Since the area drawn by the view is an independent area within the desktop and cannot be moved or eliminated through page insertion, when the in-vehicle desktop is a virtual screen, the display window in parallel view mode needs to avoid obscuring the navigation bar to prevent the displayed content from being blocked.

[0181] For example, before determining the first configuration information based on the first screen information, the position and size of the navigation bar on the in-vehicle desktop can be obtained through the parallel window configuration module (MagicWindowConfig), thereby determining the area that the display window needs to avoid. Therefore, after obtaining the configuration information of the navigation bar, the size and position of at least two display windows can be determined based on the position and size of the navigation bar and the first screen information, so as to use the size and position of at least two display windows as the first configuration information, thereby enabling the parallel vision module to make corresponding settings.

[0182] In some embodiments of this application, the window configuration information obtained by the parallel view module can be stored using the parallel mode base module (MagicModeBase) so that it can be called during the application display process.

[0183] It should be noted that the target display modes stored in the parallel mode base module (MagicModeBase) can include various different modes, such as a target display mode consisting of two display windows, or a target display mode consisting of three or more display windows. The display position and boundaries of different display windows can also distinguish the target display modes. Taking a target display mode with two display windows as an example, with the first window positioned on the left side of the vehicle's desktop and the second window positioned on the right side, the target display mode can have three modes: the first window and the second window are the same size, the first window is larger than the second window, and the first window is smaller than the second window.

[0184] In a target display mode with at least two display windows, the at least two display windows do not intersect, thereby displaying at least two interfaces in an application respectively.

[0185] It should be understood that the target display mode stored in the parallel mode base module (MagicModeBase) also needs to be set to adjust the size of the display window on the in-vehicle desktop based on the window size of the in-vehicle desktop. The terminal device can obtain the window size of the in-vehicle desktop by reading the device information from the vehicle's infotainment system. The device size of the in-vehicle screen determines the overall display size of the in-vehicle desktop; therefore, by obtaining the first screen information of the in-vehicle screen, the window size of the in-vehicle desktop can be calculated.

[0186] After calculating the window size of the vehicle desktop using the information from the first screen, the setting position and size of the display window for different applications in the target display mode can be calculated based on the window size of the vehicle desktop. Different applications may correspond to different numbers and / or different sizes of display windows.

[0187] After obtaining information such as the number, location, and size of the display windows, the first configuration information can be updated accordingly. It should be understood that the number, location, and size of the display windows obtained through the above method can be stored as one of the target display modes in the parallel mode base module (MagicModeBase). This allows the mode switching module (MagicModeSwitcher) to read and set the corresponding mode when the in-vehicle desktop is displayed, and then use the window mode management module (MagicModeA1An) to set and update the data of the display windows within that mode.

[0188] S500: Detected user click on application icons on the vehicle desktop.

[0189] Once the vehicle-mounted infotainment system successfully connects to the terminal device and the in-vehicle desktop is displayed on the in-vehicle screen, it can detect the user's clicks through the in-vehicle desktop and respond to them in a timely manner, allowing the user to control the in-vehicle desktop.

[0190] like Figure 7 As shown, when the in-vehicle desktop detects that any application icon has been clicked, an application notification is initiated and sent to the Parallel View Management Module. This application notification includes information about the first application corresponding to the application icon. The Parallel View Management Module then determines the application's status and whether to display the first application in the target display mode via the Parallel View Module. For example, if the Parallel View Management Module detects that the first application supports the target display mode, step S600 is executed.

[0191] Figure 11 This is a schematic diagram of an application startup process in an embodiment of this application.

[0192] like Figure 11As shown, in some embodiments, when the vehicle's infotainment system detects that any application icon displayed on the in-vehicle desktop has been clicked by a user, the MagicWindowManager can invoke certain functional modules to launch the corresponding activity. For example, it can invoke functional modules such as the ActivityTaskManagerService, the first activity launcher (xxActivityStarter), the second activity launcher (ActivityStarter), the MagicWindowManagerService, and the MagicActivityStarter to launch and decide on the first application after it has been clicked.

[0193] First, after the in-vehicle desktop detects that any application icon from the vehicle's infotainment system has been clicked, the in-vehicle desktop can send the message that the application icon has been clicked, along with information about the first application corresponding to the clicked application icon, to the ActivityTaskManagerService module to start the activity to be launched in the first application.

[0194] Simultaneously, the in-vehicle desktop can send notifications to the in-vehicle parallel view management module, informing it of the first application to be launched and its corresponding package name. The package name is the software name within the application directory, named using the reverse domain name rule, such as com.xx.xxx.xxxx. This notifies the module of the corresponding name, allowing the in-vehicle parallel view management module to decide whether to launch the application in the target display mode.

[0195] After making a decision, the vehicle-mounted parallel view management module can send the support status of the first application for the target display mode to the parallel window management service module (MagicWindowManagerService), and notify the parallel activity trigger (MagicActivityStarter) of the support status of the first application for the target display mode through the parallel window management service module (MagicWindowManagerService).

[0196] Upon receiving the activity start command from the first application, the ActivityTaskManagerService module calls the Android system's specified user start command (startActivityAsUser) to launch an activity corresponding to the first application and run it as the specified user's activity. Normally, without further operation or prior setup, this specified user can be the current user.

[0197] Then, the ActivityTaskManagerService module will send an execution signal (execute) to the first activity launcher (xxActivityStarter). Through the interaction of the execution signal (execute) and execution request signal (executeRequest) between the first activity launcher (xxActivityStarter) and the second activity launcher (ActivityStarter), thread allocation and lifecycle changes will be performed on the activity corresponding to the first application.

[0198] After the activity corresponding to the first application is created, the second activity launcher (ActivityStarter) calls the activity check instruction (startActivityUnchecked) to check the activity's launchability, preventing situations where the activity cannot start and ensuring that the activity can start successfully. Then, it calls the stack management instruction (startActivityInner) to manage the stack of the activity to be launched, so that the activity can be displayed smoothly.

[0199] The second activity starter sends the activity to be launched to the MagicWindowManagerService module, so that it can execute the MagicWindowPolicy for the activity to be launched.

[0200] Finally, the parallel window management service module (MagicWindowManagerService) sends the activity to the parallel activity trigger (MagicActivityStarter) to override the window information corresponding to the activity (overrideIntentForMagicWin) so that the activity is the activity corresponding to the target display mode.

[0201] If the first application is found to support the target display mode, the parallel activity trigger (MagicActivityStarter) will decide to launch the application in the target display mode and display the launched activities.

[0202] It should be understood that the above-described process of launching the application in response to a user click in the target display mode is only one feasible implementation method in the embodiments of this application, and this application does not limit the process of launching the application in response to a user click.

[0203] In some embodiments of this application, after the parallel activity trigger (MagicActivityStarter) decides to launch the application in the target display mode, the activity corresponding to the application to be launched can be sent to the task execution module (Task) through the second activity launcher (ActivityStarter) so that the activity of the application can be executed by the task execution module (Task).

[0204] For example, the task execution module (Task) may include a stack, to which a second activity starter (ActivityStarter) sends a command to the task execution module (Task) to push an application activity onto the top of the stack, so that when the terminal device displays activities, it can display the activity at the top of the stack.

[0205] Then, the StartingSurfaceController module retrieves the activities to be displayed from the Task execution module, thereby controlling the in-vehicle desktop to display the corresponding startup window interface. For example... Figure 11 As shown, the StartingSurfaceController module can also send the command to display the start window to the ActivityRecord module to record and update the activity status.

[0206] In this embodiment, the ActivityRecord module is used to record activities, namely the basic information of the Activity and its subsequent changes. Each operation on an activity in the terminal device sends the corresponding operation information to the ActivityRecord module, enabling the ActivityRecord module to record the changes to the activity.

[0207] In another embodiment of this application, the ActivityRecord module can be connected to the second ActivityStarter so that after the second ActivityStarter starts the activity, the ActivityRecord module can be called to record the basic information and status of the activity, thereby realizing the calling and implementation of the ActivityRecord module.

[0208] S600: If the first application corresponding to the application icon supports the target display mode, the first application will be displayed on the in-vehicle desktop in the target display mode.

[0209] As described in step S500 above, when it is detected that the first application corresponding to the application icon supports the target display mode, the first application is displayed on the in-vehicle desktop in the target display mode. For example, as shown... Figure 11 As shown, the second activity starter (ActivityStarter) can be used to call the permission detection instruction (startActivityInner) so that the parallel window management service module (MagicWindowManagerService) can obtain the support status of the first application for the target display mode, and then determine the display mode of the first application based on the support status of the first application for the target display mode.

[0210] Figure 12 This is a schematic diagram showing the function switches in an embodiment of this application.

[0211] In some embodiments of this application, the application also includes a function switch, allowing the user to select whether the application can be displayed in the target mode. For example... Figure 12 As shown in (a) and (b), these are schematic diagrams of the function switch displays in the vehicle-mounted infotainment system and the terminal equipment, respectively. Figure 12 As shown, the function switches in both the vehicle-mounted system and the terminal device are in the "on" state. These function switches include switches for turning the target display mode on or off for the first application, and may also include switches for turning the target display mode on or off for other applications.

[0212] It should be understood that when the function switch is in the on state, if the application corresponding to the function switch supports the target display mode, it can be displayed on the vehicle desktop in the target display mode; however, if the function switch is in the off state, even if the application corresponding to the function switch supports the target display mode, it can only be displayed on the vehicle desktop in full-screen mode.

[0213] Figure 13 This is a flowchart illustrating the process of turning on the function switch in an embodiment of this application. Figure 14 This is a schematic diagram of another application startup process in an embodiment of this application.

[0214] like Figure 13 As shown, the parallel window manager (MagicWindowManager) can also control the function switches of applications on the user terminal device through the window management listener (MagicWindowManagerEx).

[0215] For example, the user's click on a function switch displayed on the in-vehicle desktop or terminal device can be detected through the in-vehicle screen or display screen 193 to update the state of the function switch. Then, based on the original state of the function switch, the function switch clicked by the user is turned on or off. If the original state of the function switch was on, the function switch is turned off after the user clicks it; if the original state of the function switch was off, the function switch is turned on after the user clicks it.

[0216] It should be understood that the aforementioned user clicks on the vehicle screen or display screen 193 are all single valid clicks, that is, the clicks are collected by the vehicle screen or display screen 193. Since multiple clicks will cause the function switch to cycle between the on and off states, in some embodiments, the original state of the function switch and the user's click position and number of clicks can be used to obtain the state of the function switch. Taking the function switch as an example, if the number of clicks is even, the off state is maintained; if the number of clicks is odd, the state of the function switch is changed to the on state.

[0217] In some embodiments, the frequent turning of the function switch on and off can be reduced by limiting the collection of click operations. The above-described operation of the function switch is an exemplary description in this application, and other operation methods may also be possible, which are not limited in this application.

[0218] Taking the function switch of the second application as being in the off state as an example, the second application can be any application in the terminal device. When it is detected that the user has clicked to update the state of the function switch, that is, to turn on the function switch of the second application, the vehicle desktop settings module can notify the vehicle parallel vision management module of the function switch being clicked. Then, the vehicle parallel vision management module can call the window management listener (MagicWindowManagerEx) and send it a message to update the switch state.

[0219] After receiving a message about the switch status update, the window management listener (MagicWindowManagerEx) can obtain the status of the function switch, then call the switch start command, and then send it to the parallel window management service module (MagicWindowManagerService).

[0220] The parallel window management service module (MagicWindowManagerService) modifies the state of the function switch by executing a switch start command, and then sends the result of the execution command to the parallel window configuration module (MagicWindowConfig) so that the configuration module updates its stored application configuration information. Finally, the configuration loading module (MagicWindowConfigLoader) writes the updated application configuration information, thus completing the process of turning the application's function switch from off to on.

[0221] It should be understood that the process of turning the application's function switch from on to off is similar to the process of turning the application's function switch from off to on, except that the instruction called by the window management listener (MagicWindowManagerEx) is a switch off instruction, and the switch off instruction is sent to the parallel window management service module (MagicWindowManagerService) for subsequent processing, which will not be elaborated here in this application.

[0222] As can be seen from the above, the state of the function switch of the first application also affects whether the application can be displayed in the target display mode. Therefore, in this embodiment of the application, as... Figure 14 As shown, after detecting a user's click on an application icon on the in-vehicle desktop, the in-vehicle desktop can notify the Parallel Vision Management Module of the clicked application icon. The Parallel Vision Management Module obtains the second configuration information of the first application, which includes the support status of the first application for the target display mode and the status of the function switch of the first application. Thus, the Parallel Vision Management Module can obtain the support status of an application for the target display mode and the status of the function switch of the first application through the second configuration information.

[0223] After obtaining the above information, the display mode of the first application on the vehicle desktop can be obtained. Therefore, after obtaining the above information, if the first application supports the target display mode and the function switch is turned on, the Parallel View Management Module sends an instruction to the Parallel View Module to display the application in the target display mode, so that the Parallel View Module can display the first application on the vehicle desktop in the target display mode.

[0224] Figure 15 This is a schematic diagram of the process of launching a first application in the target display mode according to an embodiment of this application.

[0225] In this embodiment, as Figure 15As shown, after the MagicActivityStarter determines that the first application can be launched in the target display mode, the vehicle's parallel view management module can be notified to perform operations through the vehicle's desktop settings module.

[0226] The vehicle-mounted parallel view management module calls the window manager (MagicWinManager) and sends messages to the window manager (MagicWinManager) to update the display status of the application on multiple display windows.

[0227] The window manager (MagicWinManager) can then send corresponding information to the modal container module (MagicContainer) to update the screen size of the parallel view in the modal container module (MagicContainer).

[0228] Furthermore, after updating the screen size of the parallel view, the mode container module (MagicContainer) sends window update information to the parallel window configuration module (MagicWindowConfig). Upon receiving the window update information, the parallel window configuration module (MagicWindowConfig) reconfigures the size, boundaries, and positions of the windows in the vehicle scene to adapt to the vehicle screen on the vehicle terminal according to different applications. At the same time, it can also obtain the preset boundaries of each window when connecting to the vehicle terminal from the parallel mode base module (MagicModeBase) to provide configuration data for the window mode management module (MagicModeA1An).

[0229] Once the window mode management module (MagicModeA1An) configures the activity limits in the parallel mode base module (MagicModeBase), the parallel mode base module (MagicModeBase) can send the changed limit data of the display window to the configuration container module (ConfigurationContainer) to update the configuration information.

[0230] like Figure 13 As shown in some embodiments of this application, the parallel window configuration module (MagicWindowConfig) can also receive application switch data through the parallel window management service module (MagicWindowManagerService), thereby updating the status of the application's function switches.

[0231] After the configuration update is complete, the window manager (MagicWinManager) can change the focus to the window displayed in the target display mode on the virtual screen. In this embodiment, the virtual screen is the in-vehicle desktop transmitted to the vehicle's infotainment system via the connection management module; therefore, the window manager (MagicWinManager) changes the focus to the in-vehicle desktop.

[0232] After the focus is moved to the in-vehicle desktop, the mode switching module (MagicModeSwitcher) can set the window boundaries in the target display mode according to the number of activities corresponding to the first application. For example, if the target display mode of the first application corresponds to two activities, then a target display mode with two windows, a first window and a second window, is set, and the specific boundaries between the first window and the second window can be obtained through the boundary information pre-stored in the mode.

[0233] Since different applications may have different window boundaries, the mode switching module (MagicModeSwitcher) sends a command to the window mode management module (MagicModeA1An) after setting the target display mode for the first application, so that it can obtain the target display mode and modify the window position, size and other information in the target display mode.

[0234] For example, after a user clicks the application icon, the window mode management module (MagicModeA1An) can select the mode corresponding to the first application from the stored target display modes, based on the number of windows supported by the first application and the specific settings of the first application, to set the window limits of the first application.

[0235] The window mode management module (MagicModeA1An) can read the stored target display mode from the parallel mode base module (MagicModeBase). Since the target display mode is obtained from the size of the in-vehicle desktop and the application's configuration information, the window position and size required by an application's launched activity may differ from the mode called by the window mode management module (MagicModeA1An) during actual operation. Therefore, the window configuration information of the target display mode corresponding to the first application can be retrieved from the parallel window configuration module (MagicWindowConfig) and the parallel mode base module (MagicModeBase).

[0236] After obtaining the window configuration information of the target display mode corresponding to the first application, the window mode management module (MagicModeA1An) will also make decisions based on the window configuration information and the number of activities in the first application, thereby determining the boundary of each activity, that is, determining the display position of each activity.

[0237] To save time switching the target display mode when the first application is clicked again in subsequent processes, after determining the display position and boundaries of each activity, the updated data can be sent to the parallel mode base module (MagicModeBase) for storage, and the configuration can be modified through the parallel mode base module (MagicModeBase).

[0238] In some embodiments of this application, if the first application is clicked multiple times, the activity limits of the first application are recorded in the parallel mode base module (MagicModeBase). Therefore, after the application icon corresponding to the first application is clicked again, a setting command for the target display mode can be sent directly to the parallel mode base module (MagicModeBase) through the window mode management module (MagicModeA1An), thereby improving operating efficiency.

[0239] It should be understood that the above-mentioned mode invocation and settings are all feasible implementation methods in this application, and this application does not limit the specific invocation and setting methods of the modes.

[0240] Figure 16 This is a schematic diagram illustrating a process for modifying the display window configuration in an embodiment of this application.

[0241] In some embodiments of this application, after the parallel mode base module (MagicModeBase) obtains data from the window mode management module (MagicModeA1An), it can send the obtained window boundary data to the configuration container module (ConfigurationContainer). When the window boundary data changes, the configuration container module (ConfigurationContainer) refreshes each layer of the display window, thereby refreshing the configuration of the display window using the configuration container module (ConfigurationContainer).

[0242] like Figure 16 As shown, during the configuration update process, the ActivityRecord module first determines whether the display window in the vehicle desktop has been modified, thus avoiding window display errors. Furthermore, when the display window's configuration is modified, the onConfigurationChanged instruction determines whether to reload activity resources related to the display window's orientation and other configuration characteristics, thereby sending the window's configuration information to the WindowContainer module.

[0243] When the configuration call command determines that configuration-related active resources need to be reloaded, it can send a command to the task execution module (Task) through the window container module (WindowContainer) to enable it to reload the resources required for the display window and update the wallpaper currently displayed in the window. If the wallpaper needs to be updated, the task execution module (Task) can send a command to the wallpaper module (MagicWallpaper) to update the background wallpaper of the display window.

[0244] It should be understood that the aforementioned method of application startup and configuration update is only one feasible implementation method in this application. The application startup and configuration update process can also be implemented in other ways, and this application does not limit it.

[0245] S700: Close the in-vehicle desktop when the terminal device is disconnected from the vehicle's infotainment system.

[0246] Figure 17 This is a schematic diagram illustrating the process after a terminal device is disconnected from the vehicle's infotainment system, as described in an embodiment of this application.

[0247] like Figure 17 As shown, when the connection management module in the vehicle-machine intelligent interconnection product or terminal device detects that the connection between the terminal device and the vehicle-machine interface is disconnected, the terminal device will close the in-vehicle desktop to stop displaying on the vehicle-machine interface.

[0248] In some embodiments, when the in-vehicle desktop is turned off, the terminal device can directly destroy the process running the in-vehicle desktop, thereby turning off the in-vehicle desktop and saving process usage within the terminal device.

[0249] Figure 18 This is a schematic diagram of a process for turning off a display screen according to an embodiment of this application.

[0250] like Figure 18 As shown, the display screen 193 of the terminal device can be managed through the display screen management module to obtain its screen display status. When the display screen 193 times out and turns off, that is, when the screen display status is off, the visibility of the display screen 193 is updated through the display screen module, so that the display screen of the terminal device stops displaying the first application.

[0251] Then, the display module obtains the lock screen status of the terminal device through the lock screen module, and detects the connection scenario between the terminal device and the vehicle terminal to obtain the current status information of the terminal device.

[0252] If the display module detects that the terminal device is in a locked state or in a vehicle-to-everything (V2X) connection scenario, it updates the visibility of the first application on the in-vehicle desktop through the parallel window management service module (MagicWindowManagerService). In this embodiment, the first application can continue to be displayed on the in-vehicle desktop when the terminal device is in a locked state or in a V2X connection scenario.

[0253] If the terminal device is in a locked state but the connection to the vehicle system is disconnected, the display of the vehicle desktop on the vehicle system will stop.

[0254] S800: Set the connection status of the target display service to disconnected.

[0255] The target display service is the parallel view service. For example... Figure 17 As shown, when the terminal device closes the in-vehicle desktop, it can send a disconnection message to the Parallel Vision Management Module through the Connection Management Module to stop the operation of the Parallel Vision Management Module and the Parallel Vision Module.

[0256] It should be understood that after disconnection, the Parallel Vision management module will send a disconnection message to the Parallel Vision modules it can call, thereby stopping the Parallel Vision service.

[0257] Based on the above technical solution, the connection between the terminal device and the vehicle's infotainment system can make the applications displayed on the vehicle's infotainment system more compatible with the vehicle's screen. By using the target display mode or parallel view mode within the application to display the application that the user clicks, the user experience can be improved.

[0258] It is understood that, in order to achieve the aforementioned functions, the terminal device includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein, the embodiments of the present invention can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of this application.

[0259] This application embodiment can divide the terminal device into functional modules according to the above method example. For example, each function can be divided into its own functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0260] Figure 19 This is a schematic diagram of the structure of an application adaptation system in an embodiment of this application.

[0261] Based on the aforementioned application adaptation method, this application also provides an application adaptation system. In some embodiments, the terminal device can... Figure 19 The hardware device shown implements the corresponding function. For example... Figure 19 As shown, the application adaptation system may include: a display screen 1901, a memory 1902, a processor 1903, and a communication module 1904. The memory 1902, processor 1903, and communication module 1904 can be connected to each other via one or more communication buses 1905, and the display screen 1901 can be connected to the memory 1902 and processor 1903 via the communication module 1904.

[0262] In one embodiment, the display screen 1901 may include a display panel 19011 and a touch sensor 19012. The display panel 19011 is used to display images, and the touch sensor 19012 can transmit detected touch operations to the processor 1903 via a communication module 1904 to determine the operation of the display application, and then provide visual output related to the touch operation through the display panel 19011. The processor 1903 may include one or more processing units, such as an application processor, a modem processor, a graphics processor, an image signal processor, a controller, a video codec, a digital signal processor, a baseband processor, and / or a neural network processor. Different processing units may be independent devices or integrated into one or more processors. The memory 1902 is coupled to the processor 1903 and is used to store various software programs and / or multiple sets of instructions. The memory 1902 may include volatile memory and / or non-volatile memory. When the software programs and / or multiple sets of instructions in the memory 1902 are executed by the processor 1903, the terminal device implements the method steps in the above embodiments and their implementations.

[0263] Based on the aforementioned application adaptation method, this application also provides a terminal device, including: a display screen, a memory, and one or more processors; the display screen, the memory, and the processors are coupled; wherein, the memory stores computer program code, which includes computer instructions, and when the computer instructions are executed by the processor, the terminal device performs the application adaptation method provided in the foregoing embodiments. The specific structure of this terminal device can be referred to... Figure 2 The structure of the terminal device shown is illustrated.

[0264] This application also provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the methods described above.

[0265] This application also provides a computer program product containing instructions that, when run on a computer, cause the computer to perform the methods described above.

[0266] This application also provides a chip system including a processor for supporting the system in implementing the functions involved in the above embodiments, such as generating or processing information involved in the aforementioned application adaptation method. In one possible design, the chip system further includes a memory for storing computer instructions and data necessary for the application adaptation system. This chip system may be composed of chips or may include chips and other discrete devices.

[0267] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

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

[0269] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0270] 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.

[0271] 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 readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially or in other words, the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor 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 USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0272] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. An application adaptation method, characterized in that, The method is applied to a terminal device equipped with an interconnected application. This application establishes a screen mirroring connection with a vehicle-mounted infotainment system. The interconnected application includes a parallel view management module, which manages the target display mode of the split-screen within the application through a parallel window manager. The parallel window manager is implemented by the terminal device based on a modified window manager (WMS) from the operating system's open-source project AOSP. The parallel window manager also includes a wallpaper blur management module. The method comprises: when the terminal device establishes a screen mirroring connection with the vehicle-mounted infotainment system based on the interconnected application, in response to a successful screen mirroring connection, controlling the vehicle-mounted infotainment system to display a vehicle-mounted desktop on the vehicle screen based on the interconnected application. The vehicle-mounted desktop includes at least one application icon, and each application icon corresponds to an application on the terminal device. When a user clicks on a target application icon on the in-vehicle desktop, if the first application corresponding to the target application icon supports the target display mode, the target display mode is executed based on the parallel window manager so that the in-vehicle desktop displays at least one interface of the first application based on a split-screen window in the target display mode, wherein the window size of the split-screen window is adapted to the in-vehicle screen. When the first application launches an activity, the interface corresponding to the activity is displayed based on the first target split-screen window, and the background wallpaper provided by the Internet application is displayed in the remaining split-screen windows, wherein the background wallpaper has been blurred based on the wallpaper blur management module.

2. The application adaptation method according to claim 1, characterized in that, Also includes: During the process of establishing a screen projection connection between the terminal device and the vehicle terminal based on the interconnection application, the first screen information of the vehicle terminal is obtained based on the interconnection application. The first screen information includes at least one of the following: screen size, screen resolution, and desktop display status of the vehicle screen. When the vehicle desktop is displayed on the vehicle screen on the vehicle terminal, the first configuration information corresponding to the target display mode is determined based on the connected application. The first configuration information is determined based on the first screen information and includes the window setting position and size of the first application.

3. The application adaptation method according to claim 2, characterized in that, The step of determining the first configuration information corresponding to the target display mode based on the interconnected application includes: Based on the connected application, the position and size of the navigation bar on the vehicle desktop are obtained, so as to determine the size and position of at least two split-screen windows by means of the position and size of the navigation bar and the first screen information.

4. The application adaptation method according to claim 2, characterized in that, Also includes: After the user clicks on the target application icon on the in-vehicle desktop, the second configuration information of the first application is obtained based on the connected application. The second configuration information includes: the support status of the first application for the target display mode and the status of the function switch. If the first application corresponding to the target application icon supports the target display mode, then the target display mode is executed based on the parallel window manager, so that the in-vehicle desktop displays at least one interface of the first application based on the split-screen window of the target display mode, including: If the support status is determined based on the interconnected application to be that the first application supports the target display mode, and the status of the function switch is determined to be that the target display mode is turned on, then the target display mode is executed based on the parallel window manager, so that the in-vehicle desktop displays at least one interface of the first application based on the split-screen window.

5. The application adaptation method according to any one of claims 1 to 4, characterized in that, Also includes: After the user clicks on the target application icon on the in-vehicle desktop, the user's wallpaper settings for the in-vehicle desktop are obtained based on the connected application, and the background wallpaper of the target display mode is updated according to the wallpaper settings. After determining the first configuration information corresponding to the target display mode based on the Internet application, the method further includes: obtaining the second target split-screen window corresponding to the background wallpaper based on the Internet application, wherein the second target split-screen window is determined according to the first configuration information; The background wallpaper is displayed in the second target split-screen window.

6. The application adaptation method according to claim 3, characterized in that, After determining the first configuration information corresponding to the target display mode based on the interconnected application, the method further includes: Based on the first screen information obtained by the connected application, the window size of the in-vehicle desktop is calculated; Based on the window size of the in-vehicle desktop, calculate the setting position and size of the split-screen window corresponding to different applications when they are in the target display mode; Update the first configuration information according to the set position and size of the split-screen window.

7. The application adaptation method according to claim 5, characterized in that, Also includes: Update the wallpaper settings in response to wallpaper changes; The background wallpaper is changed according to the updated wallpaper settings; The updated background wallpaper is displayed in the second target split-screen window.

8. The application adaptation method according to claim 1, characterized in that, Also includes: If the screen display of the terminal device is off, the first application will stop being displayed on the screen of the terminal device. Obtain the status information of the terminal device; If the terminal device is in a locked state or in a vehicle-mounted system connected state, update the visibility of the first application on the vehicle desktop.

9. The application adaptation method according to claim 1, characterized in that, Also includes: When the terminal device is disconnected from the vehicle's infotainment system, the in-vehicle desktop is turned off. Set the connection status of the target display mode to disconnected.

10. A terminal device, characterized in that, include: A display screen, a memory, and one or more processors; the display screen, the memory, and the processors are coupled; wherein the memory stores computer program code, the computer program code including computer instructions, which, when executed by the processor, cause the terminal device to perform the application adaptation method as described in any one of claims 1 to 9.

Images