A dual-screen heterogeneous display control system and method based on an Android system

Abstract

The application discloses a double-screen different display control system and method based on an Android system, relates to the technical field of screen display control, and through initialization of system driving, configuration of double-screen hardware parameters and setting as independent display controller nodes, simultaneous registration of hot plug interrupt processing functions, configuration of DRM framework to support double display channels, adoption of a vertical synchronization mechanism to keep the refresh rate consistent, real-time monitoring of the connection state of an external screen, allocation of independent display identifiers to the double screens and disabling of a mirror mode, establishment of a display device list for parallel rendering, support of two modes of different display and independent display, loading of a custom layout through a native display class during different display, startup of an independent application program through binding of a display identifier during independent display, dynamic response to external screen plug-in actions, intelligent allocation of resources such as rendering channels and memory spaces, and the like. The application realizes full-stack optimization of the underlying architecture of the Android system, effectively improves the synchronous stability and multitask processing capacity of the double-screen different display of the Android system.

Description

Technical Field

[0001] This invention relates to the field of screen display control technology, specifically a dual-screen display control system and method based on the Android system. Background Technology

[0002] Electronic screen technology is rapidly evolving towards multi-dimensionality and high performance. Multi-screen display functionality has become a significant development trend, shifting from single-screen output to multi-screen collaboration and independent display. This is finding widespread application in various fields such as smart advertising, industrial control, medical electronics, and e-sports entertainment. Users' demand for multi-screen, especially dual-screen, simultaneous display of different content is becoming increasingly urgent.

[0003] However, existing dual-screen display solutions for Android systems generally employ mirroring strategies, which cannot directly achieve stable dual-screen display and require reliance on third-party tools or non-standard interfaces. Furthermore, poor synchronization of dual-screen displays and inconsistent refresh rates and rendering rhythms easily lead to screen stuttering and tearing. These solutions also rely on GPU software compositing or intermediate proxies, resulting in high resource consumption and significant performance degradation. Therefore, there is an urgent need for a dual-screen display system optimized across the entire stack from the kernel to the application layer to address the pain points of existing technologies. Summary of the Invention

[0004] The purpose of this invention is to provide a dual-screen display control system and method based on the Android system to solve the problems raised in the prior art.

[0005] To achieve the above objectives, the present invention provides the following technical solution: A dual-screen display control method based on the Android system, the method includes the following steps: The underlying architecture of the Android system includes a kernel layer, a hardware abstraction layer (HAL), a framework layer, and an application layer; the built-in screen is a screen that supports MIPI-DSI (hereinafter referred to as MIPI); the external screen is a screen that supports HDMI. After initializing the Android system driver, the connection status of the external screen is read in real time at the hardware abstraction layer through the level status of the bound general input / output interface. The connection status includes successful connection and disconnection. When the external screen is disconnected, single-screen display is performed through the built-in screen. Furthermore, the initialization process includes: In the kernel layer: Configure the hardware parameters of the built-in screen and the external screen in the device tree; the device tree is a data structure that describes hardware components and their connection relationships. The built-in screen hardware parameters include resolution, refresh rate, number of data channels, horizontal synchronization duration, vertical synchronization duration, and blanking interval duration in each direction; the external screen hardware parameters include resolution and refresh rate; the resolution and refresh rate of the external screen are mainly read because for external screens such as HDMI, their more precise timing parameters are usually automatically read through EDID (Extended Display Identification Data), without needing to be hard-coded in the device tree, reflecting the flexibility of the design; The horizontal synchronization duration refers to the duration during which the horizontal synchronization signal remains effective. Its function is to ensure that the scanning of each row of pixels can achieve precise starting position alignment at the receiving end (i.e., the built-in screen). The horizontal synchronization signal is a timing pulse that marks the start of scanning a row of pixel data. The horizontal blanking region is the time interval between the end of a line of valid pixel data scanning and the start of the next line's synchronization pulse. It consists of a back shoulder (or back blanking) and a front shoulder (or front blanking), located after the valid line data and before the next line's synchronization pulse, respectively. During this interval, the data signal is invalid, and the electron beam quickly returns from the right side of the screen to the starting position on the left side, preparing for scanning the next line. The existence of the horizontal blanking region provides the necessary time margin for this line reset process. The vertical synchronization duration is the effective width of the vertical synchronization signal. Its function is to ensure the synchronization of the entire display frame in the vertical direction, so that each frame of the image can be refreshed from the top of the screen. The vertical synchronization signal is a timing pulse that indicates that all rows of an image frame have been scanned and a new frame scan is about to begin. The vertical blanking region is the time interval between the end of all valid line scans in a frame and the start of the vertical sync pulse for the next frame. During this interval, line scanning pauses, the electron beam returns from the bottom to the top of the screen, and the vertical sync signal is emitted, marking the start of a new frame. The vertical blanking region provides the necessary timing window for the frame reset operation of the display device.

[0006] The built-in screen is designated as the first independent display controller node, and the external screen as the second independent display controller node. In the DRM framework, a display controller node (CRTC, Cathode Ray Tube Controller) represents an independent hardware unit capable of outputting display signals. Initializing it as the "first" and "second" independent nodes means that the system kernel recognizes the built-in screen and the external screen as two equal and independent display devices, rather than a master-slave relationship. Write and register a hot-plug interrupt handling function to trigger the hot-plug interrupt handling function when an external screen is plugged in or unplugged. The core of writing an interrupt handler function lies in implementing a callback function that conforms to the operating system kernel interrupt handling specifications; this function must have the characteristics of short execution time and non-blocking, and is usually divided into two parts: The upper half function executes in an interrupt context; its primary responsibility is to read the level value of the general-purpose input / output interface or dedicated status register associated with the hot-plug detection pin in order to determine the current physical connection status of the external panel in real time. The upper half function needs to treat the change in connection state as an event and quickly submit it to the kernel's general work queue or trigger a lower half mechanism; after completing this operation, the upper half function should return immediately to ensure that the impact on system real-time performance is minimized. The lower half function executes in the process context and is responsible for handling the events marked by the upper half. Its core logic is to broadcast a hot-plug event to the graphics subsystem through the dedicated application programming interface provided by the DRM (Direct Rendering Manager) framework, based on the newly acquired connection state. Registration is the process of binding a written interrupt handler function to a specific hardware interrupt source, which is usually completed during the initialization phase of the display controller driver: First, obtain the hardware interrupt number bound to the hot-plug detection function through the chip datasheet or device tree configuration; call the interrupt registration function provided by the kernel, passing the interrupt number, interrupt handler function and interrupt trigger flag as parameters; the interrupt trigger flag must be explicitly specified as edge-triggered to ensure that the plugging and unplugging action can be accurately captured when the pin level changes; after successful registration, call the interface to enable the interrupt line.

[0007] When an external screen is connected or disconnected, the level of the hot-plug detection pin on its connector will change. This level change generates an electrical signal, which is sent to the interrupt controller inside the system-on-a-chip. After receiving the signal, the interrupt controller will send an interrupt request to the central processing unit (CPU) core according to the preset priority. The CPU will respond to the interrupt at the appropriate time, suspend the current task, and jump to the address of the pre-registered interrupt handler function to start execution, thereby completing the entire triggering process.

[0008] The DRM framework is configured using multi-plane synthesis configuration items and frame buffer simulation configuration items, enabling the DRM framework to support two independent display controllers (CRTC), two encoders, and two connectors; and the refresh rate of the built-in screen and the external screen is kept consistent through the vertical synchronization (VSYNC) signal synchronization mechanism. The DRM framework is the Linux kernel's graphics subsystem, responsible for managing the graphics processing unit (GPU) and display hardware. Within this framework, the display controller generates video timing signals and scans the frame buffer; the encoder converts the digital signals output by the independent display controller into signals for a specific interface (such as HDMI); the connector represents the physical display interface, used to detect the connection status of the display device and read its capabilities (e.g., via EDID); Multiplanar Support allows the hardware to process multiple image layers (such as graphics and video layers) simultaneously and efficiently composite them into the final image; Framebuffer Emulation provides each display device with a device node compatible with traditional framebuffer interfaces, ensuring backward compatibility for upper-layer applications. The Vertical Synchronization (VSYNC) signal synchronization mechanism aims to solve the problem of slight differences in refresh rates that may occur between two independent display controllers due to differences in clock sources. Without synchronization, noticeable frame rate asynchrony can easily occur after long-term operation, and even tearing or jitter in dynamic images. Its principle is to use the synchronization primitives provided by the DRM framework to align the vertical blanking cycles of the two display controllers. Typically, the system designates one master display controller and the other slave controller. The slave controller waits for the VSYNC event of the master controller and then starts scanning and outputting a new frame within the same vertical blanking interval, thereby forcing the refresh rate to be consistent at the hardware level.

[0009] When the external screen is successfully connected, configure the dual-screen display and perform dual-screen display through the built-in screen and the external screen according to the display mode; Furthermore, in the hardware abstraction layer: Obtain the display parameters of the built-in screen and the display parameters of the external screen, including width, height, refresh rate, and density (DPI). Specifically, when the system service (Display Manager Service) starts or detects a change in the display device status, it accesses the DRM driver nodes corresponding to the built-in screen and the external screen respectively, and actively obtains their respective independent display parameters, including the screen width, height, refresh rate and density DPI. These parameters ensure that the framework layer can know the true capabilities of each physical display device, thereby providing a basis for subsequent resolution adaptation, content layout and parallel rendering strategies.

[0010] Furthermore, within the framework layer: Assign independent display identifiers to the built-in screen and external screen, and disable the mirror display mode of the Android system; The display identifier, along with the corresponding device name and display parameters, are stored in the display device list. The device name includes the built-in screen name and the external screen name. Based on the display identifier, the built-in screen and the external screen are rendered in parallel. When the Display Manager Service (DMS) confirms that the external screen is connected, it assigns a globally unique display identifier to both the internal screen and the external screen. At this stage, the mirror display mode of the Android system is forcibly disabled, thereby switching the dual-screen working mode from the default signal copy to extended display. The display identifier, the corresponding device name, and the display parameters obtained from the hardware abstraction layer are stored in the display device list. This list constitutes a complete topology map of the currently available display resources. Based on this, system components such as window management services perform parallel rendering on the built-in screen and the external screen according to the display identifier. That is, each screen is allocated an independent rendering thread and graphics buffer to achieve hardware-accelerated differential display.

[0011] Furthermore, within the framework layer: The display device list is traversed to read the display identifier, as well as the corresponding device name and display parameters, to distinguish between built-in screens and external screens; The display modes include differential display and independent display; The built-in screen and the external screen display content through an application; when the built-in screen and the external screen run the same application, it is considered a different display; when the built-in screen and the external screen run different applications, it is considered an independent display. When the difference is displayed, an external screen display instance is created based on the native presentation class of the Android system, and a custom external screen layout file is loaded according to the external screen display instance to display the difference on the external screen. When displayed independently, the system obtains the launch intent of the application running on the external screen and generates a corresponding program launch configuration. The application is then launched according to the launch intent and program launch configuration, allowing the application running on the external screen to run independently within the external screen. For the differential display mode, its implementation relies on the native display class of the Android system. An external screen display instance is created based on the native display class of the Android system. This native display class is a dialog-style window specifically designed for displaying specific content on the secondary display screen. Developers need to load a custom external screen layout file based on the external screen display instance. This external screen layout file can be completely different from the interface design of the main screen. By calling the display method of the display instance, differential display can be performed on the external screen. This method is lightweight and efficient, suitable for scenarios where interactive operations are required on the main screen while information is displayed on the secondary screen simultaneously, such as main screen control and secondary screen video playback. For standalone display mode, the core is to bind the application process to a specific screen; the application or system needs to obtain the launch intent of the display program running on the external screen, which includes the component information to be launched; at the same time, it generates the corresponding program launch configuration, the key of which is to specify the identifier of the target display; and launches the display program according to the launch intent and program launch configuration; the display program refers to the application used to present content on the screen (such as a navigation APP, video player, custom interface component, etc.). This mechanism allows different instances of the same application or completely different applications to run independently in different screen contexts without interfering with each other, thus achieving true multitasking. For example, in an in-vehicle system, a navigation application can run on the built-in screen while an entertainment application runs on the external screen.

[0012] During the dual-screen display process, the insertion and removal actions of the external screen are acquired in real time, and resources are allocated according to the insertion and removal actions. Furthermore, the process of allocating resources includes: The insertion and removal actions include insertion and removal; When an external screen is inserted, the display parameters of the external screen are obtained; and independent resources are allocated to the external screen, including a dedicated rendering channel to ensure the independence of its graphics command flow; independent memory space for allocating front / back frame buffers to avoid memory conflicts; and specific window scheduling priorities so that the window management service can correctly handle the focusing, sorting, and compositing relationships of the dual-screen windows. Accordingly, when the external screen is unplugged, the resources of the external screen are released sequentially to prevent resource leakage; and the display identifier of the external screen is removed from the display device list, and the global display topology is updated.

[0013] A dual-screen display control system based on the Android system, comprising a kernel layer module, a hardware abstraction layer module, a framework layer module, and an application layer module.

[0014] The kernel layer module is used to initialize the drivers for the Android system; The hardware abstraction layer module is used to read the connection status and display parameters of the external screen in real time. The framework layer module is used to assign independent display identifiers to the built-in screen and the external screen, perform parallel rendering of the built-in screen and the external screen according to the display identifiers, disable the mirror display mode of the Android system, and allocate resources according to the plugging and unplugging actions. The application layer module is used to perform dual-screen display according to the display mode.

[0015] Compared with the prior art, the beneficial effects of the present invention are: 1. This invention optimizes the entire system from the kernel layer to the application layer. At the kernel layer, the built-in screen and the external screen are initialized as independent display controller nodes and the DRM framework is configured to support dual independent display channels. At the hardware abstraction layer, the hot-plug status of the external screen is monitored in real time. At the framework layer, display identifiers and system resources are allocated in a state-of-the-art manner. At the application layer, differentiated display logic is implemented. This invention builds a complete Android native dual-screen display solution that does not rely on third-party tools and effectively solves the problem of existing technologies relying on mirror display or non-standard interfaces.

[0016] 2. This invention employs a vertical synchronization signal synchronization mechanism at the kernel layer and uses the DRM framework to align the vertical blanking cycles of the two independent display controllers, forcibly maintaining the same refresh rate between the built-in screen and the external screen. At the same time, it allocates an independent rendering thread and graphics buffer for each screen at the framework layer for parallel rendering, avoiding long-term frame rate asynchrony, screen stuttering, or tearing caused by clock source differences, and significantly improving the synchronization stability and visual smoothness of dual-screen display.

[0017] 3. This invention provides two flexible modes at the application layer: differential display and independent display. In differential display mode, a custom layout is quickly loaded based on the native display class to display specific content on the secondary screen. In independent display mode, different applications run completely independently on the two screens by binding the application launch intent and display identifier. This design enables the system to adapt to multi-tasking scenarios such as controlling the secondary screen from the main screen or running different applications on both screens, greatly enhancing the functionality and scenario adaptability of dual-screen differential display. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating a dual-screen display control method based on the Android system according to the present invention. Detailed Implementation

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

[0020] Example: Figure 1 As shown, the present invention provides a technical solution, a dual-screen display control method based on the Android system, the method comprising the following steps: The underlying architecture of the Android system includes a kernel layer, a hardware abstraction layer (HAL), a framework layer, and an application layer; the built-in screen is a screen that supports MIPI-DSI (hereinafter referred to as MIPI); the external screen is a screen that supports HDMI. After initializing the Android system driver, the connection status of the external screen is read in real time at the hardware abstraction layer through the level status of the bound general input / output interface. The connection status includes successful connection and disconnection. When the external screen is disconnected, single-screen display is performed through the built-in screen. The initialization process includes: In the kernel layer: Configure the hardware parameters of the built-in screen and the external screen in the device tree; the device tree is a data structure that describes hardware components and their connection relationships. The built-in screen hardware parameters include resolution, refresh rate, number of data channels, horizontal synchronization duration, vertical synchronization duration, and blanking interval duration in each direction; the external screen hardware parameters include resolution and refresh rate; the resolution and refresh rate of the external screen are mainly read because for external screens such as HDMI, their more precise timing parameters are usually automatically read through EDID (Extended Display Identification Data), without needing to be hard-coded in the device tree, reflecting the flexibility of the design; The horizontal synchronization duration refers to the duration during which the horizontal synchronization signal remains effective. Its function is to ensure that the scanning of each row of pixels can achieve precise starting position alignment at the receiving end (i.e., the built-in screen). The horizontal synchronization signal is a timing pulse that marks the start of scanning a row of pixel data. The horizontal blanking region is the time interval between the end of a line of valid pixel data scanning and the start of the next line's synchronization pulse. It consists of a back shoulder (or back blanking) and a front shoulder (or front blanking), located after the valid line data and before the next line's synchronization pulse, respectively. During this interval, the data signal is invalid, and the electron beam quickly returns from the right side of the screen to the starting position on the left side, preparing for scanning the next line. The existence of the horizontal blanking region provides the necessary time margin for this line reset process. The vertical synchronization duration is the effective width of the vertical synchronization signal. Its function is to ensure the synchronization of the entire display frame in the vertical direction, so that each frame of the image can be refreshed from the top of the screen. The vertical synchronization signal is a timing pulse that indicates that all rows of an image frame have been scanned and a new frame scan is about to begin. The vertical blanking region is the time interval between the end of all valid line scans in a frame and the start of the vertical sync pulse for the next frame. During this interval, line scanning pauses, the electron beam returns from the bottom to the top of the screen, and the vertical sync signal is emitted, marking the start of a new frame. The vertical blanking region provides the necessary timing window for the frame reset operation of the display device.

[0021] For example: Built-in screen parameters are defined as follows: resolution 1920×1080, refresh rate 60Hz, 4-lane data channels, horizontal sync duration 10μs, vertical sync duration 2ms, horizontal blanking area 2μs for the front shoulder and 4μs for the rear shoulder, and vertical blanking area 5ms. 1920×1080 is the mainstream high-definition resolution for Android devices, and the 60Hz refresh rate meets the visual smoothness requirements of the human eye. The 4-lane MIPI channel balances the transmission rate and power consumption. The sync duration and blanking area parameters refer to the general timing standards for high-definition screens to avoid screen tearing. Define the external screen parameters: resolution 2560×1440, refresh rate 60Hz; 2560×1440 is a common 2K external screen specification, balancing display clarity and hardware load. The HDMI interface can automatically read the precise timing through EDID, without the need for additional device tree configuration.

[0022] The built-in screen is designated as the first independent display controller node, and the external screen as the second independent display controller node. In the DRM framework, a display controller node (CRTC, Cathode Ray Tube Controller) represents an independent hardware unit capable of outputting display signals. Initializing it as the "first" and "second" independent nodes means that the system kernel recognizes the built-in screen and the external screen as two equal and independent display devices, rather than a master-slave relationship. Write and register a hot-plug interrupt handling function to trigger the hot-plug interrupt handling function when an external screen is plugged in or unplugged. The core of writing an interrupt handler function lies in implementing a callback function that conforms to the operating system kernel interrupt handling specifications; this function must have the characteristics of short execution time and non-blocking, and is usually divided into two parts: The upper half function executes in an interrupt context; its primary responsibility is to read the level value of the general-purpose input / output interface or dedicated status register associated with the hot-plug detection pin in order to determine the current physical connection status of the external panel in real time. The upper half function needs to treat the change in connection state as an event and quickly submit it to the kernel's general work queue or trigger a lower half mechanism; after completing this operation, the upper half function should return immediately to ensure that the impact on system real-time performance is minimized. The lower half function executes in the process context and is responsible for handling the events marked by the upper half. Its core logic is to broadcast a hot-plug event to the graphics subsystem through the dedicated application programming interface provided by the DRM (Direct Rendering Manager) framework, based on the newly acquired connection state. Registration is the process of binding a written interrupt handler function to a specific hardware interrupt source, which is usually completed during the initialization phase of the display controller driver: First, obtain the hardware interrupt number bound to the hot-plug detection function through the chip datasheet or device tree configuration; call the interrupt registration function provided by the kernel, passing the interrupt number, interrupt handler function and interrupt trigger flag as parameters; the interrupt trigger flag must be explicitly specified as edge-triggered to ensure that the plugging and unplugging action can be accurately captured when the pin level changes; after successful registration, call the interface to enable the interrupt line.

[0023] When an external screen is connected or disconnected, the level of the hot-plug detection pin on its connector will change. This level change generates an electrical signal, which is sent to the interrupt controller inside the system-on-a-chip. After receiving the signal, the interrupt controller will send an interrupt request to the central processing unit (CPU) core according to the preset priority. The CPU will respond to the interrupt at the appropriate time, suspend the current task, and jump to the address of the pre-registered interrupt handler function to start execution, thereby completing the entire triggering process.

[0024] The DRM framework is configured using multi-plane synthesis configuration items and frame buffer simulation configuration items, enabling the DRM framework to support two independent display controllers (CRTC), two encoders, and two connectors; and the refresh rate of the built-in screen and the external screen is kept consistent through the vertical synchronization (VSYNC) signal synchronization mechanism. The DRM framework is the Linux kernel's graphics subsystem, responsible for managing the graphics processing unit (GPU) and display hardware. Within this framework, the display controller generates video timing signals and scans the frame buffer; the encoder converts the digital signals output by the independent display controller into signals for a specific interface (such as HDMI); the connector represents the physical display interface, used to detect the connection status of the display device and read its capabilities (e.g., via EDID); Multiplanar Support allows the hardware to process multiple image layers (such as graphics and video layers) simultaneously and efficiently composite them into the final image; Framebuffer Emulation provides each display device with a device node compatible with traditional framebuffer interfaces, ensuring backward compatibility for upper-layer applications. The Vertical Synchronization (VSYNC) signal synchronization mechanism aims to solve the problem of slight differences in refresh rates that may occur between two independent display controllers due to differences in clock sources. Without synchronization, noticeable frame rate asynchrony can easily occur after long-term operation, and even tearing or jitter in dynamic images. Its principle is to use the synchronization primitives provided by the DRM framework to align the vertical blanking cycles of the two display controllers. Typically, the system designates one master display controller and the other slave controller. The slave controller waits for the VSYNC event of the master controller and then starts scanning and outputting a new frame within the same vertical blanking interval, thereby forcing the refresh rate to be consistent at the hardware level.

[0025] For example: In the device tree, the built-in screen is bound as the first independent display controller node (CRTC0), and the external screen is bound as the second independent display controller node (CRTC1); the node naming follows the DRM framework specification, which makes it easy for the kernel to identify the independent hardware units of the two screens; The hot-plug interrupt handler is bound to the GPIO pin GPIO1_0, and the interrupt trigger mode is set to rising edge (insertion) and falling edge (removal). GPIO1_0 is a commonly used expansion pin in Android devices. Edge triggering can accurately capture the level transition of the insertion and removal action and avoid false triggering. Multi-plane compositing supports three layers (graphics layer, video layer, and UI layer). Frame buffer simulation allocates independent device nodes / dev / dri / card0 and / dev / dri / card1 for each screen. The three layers meet the needs of complex image compositing, and the independent device nodes ensure that the frame data of the two screens do not interfere with each other. CRTC0 is designated as the master controller and CRTC1 as the slave controller. The slave controller starts frame scanning 0.5μs after waiting for the VSYNC signal from the master controller. The 0.5μs delay is within the hardware response range and can force the refresh rate of the two screens to be consistent, eliminating jitter caused by frame rate difference. The connection status is determined by the GPIO1_0 level: a high level (3.3V) indicates a successful connection, and a low level (0V) indicates a disconnection.

[0026] When the external screen is successfully connected, configure the dual-screen display and perform dual-screen display through the built-in screen and the external screen according to the display mode; In the hardware abstraction layer: Obtain the display parameters of the built-in screen and the display parameters of the external screen, including width, height, refresh rate, and density (DPI). Specifically, when the system service (Display Manager Service) starts or detects a change in the display device status, it accesses the DRM driver nodes corresponding to the built-in screen and the external screen respectively, and actively obtains their respective independent display parameters, including the screen width, height, refresh rate and density DPI. These parameters ensure that the framework layer can know the true capabilities of each physical display device, thereby providing a basis for subsequent resolution adaptation, content layout and parallel rendering strategies.

[0027] For example: The built-in screen has a width of 1920 pixels, a height of 1080 pixels, a refresh rate of 60Hz, and a DPI density of 480; the external screen has a width of 2560 pixels, a height of 1440 pixels, a refresh rate of 60Hz, and a DPI density of 560. The DPI parameters are calculated based on the physical size of the screen. The 1080P screen has a physical size of 5.5 inches, and 480 DPI meets the high-definition display density standard; the 2K screen has a physical size of 6 inches, and 560 DPI matches its resolution accuracy. In the framework layer: Assign independent display identifiers to the built-in screen and external screen, and disable the mirror display mode of the Android system; The display identifier, along with the corresponding device name and display parameters, are stored in the display device list. The device name includes the built-in screen name and the external screen name. Based on the display identifier, the built-in screen and the external screen are rendered in parallel. When the Display Manager Service (DMS) confirms that the external screen is connected, it assigns a globally unique display identifier to both the internal screen and the external screen. At this stage, the mirror display mode of the Android system is forcibly disabled, thereby switching the dual-screen working mode from the default signal copy to extended display. The display identifier, the corresponding device name, and the display parameters obtained from the hardware abstraction layer are stored in the display device list. This list constitutes a complete topology map of the currently available display resources. Based on this, system components such as window management services perform parallel rendering on the built-in screen and the external screen according to the display identifier. That is, each screen is allocated an independent rendering thread and graphics buffer to achieve hardware-accelerated differential display.

[0028] For example: The built-in screen is identified as "DISP_001", and the external screen is identified as "DISP_002". The identification adopts the format of "DISP + three digits" to facilitate the system to quickly retrieve and manage dual-screen resources. Enter the device name "MIPI_MAIN_SCREEN" corresponding to the identifier "DISP_001" and the above-mentioned built-in screen display parameters; enter the device name "HDMI_EXT_SCREEN" corresponding to the identifier "DISP_002" and the above-mentioned external screen display parameters; the device name intuitively reflects the interface type, making it convenient for upper-layer applications to call it; The built-in screen is assigned the rendering thread ID "THREAD_DISP001", with 16MB of memory and a window scheduling priority of 5; the external screen is assigned the rendering thread ID "THREAD_DISP002", with 32MB of memory and a window scheduling priority of 4. The 16MB of memory is adapted to the requirements of 1080P double buffering (approximately 8.3MB per frame), and the 32MB is sufficient for 2K double buffering and application temporary data storage. The priority settings ensure that the main screen's interactive response takes precedence over the secondary screen. By calling setMirrorMode(false) through the DisplayManagerService interface in the framework layer, the system forces a switch to extended display mode; this meets the core requirements of dual-screen display and avoids the default mirror mode from overriding custom configurations. In the framework layer: The display device list is traversed to read the display identifier, as well as the corresponding device name and display parameters, to distinguish between built-in screens and external screens; The display modes include differential display and independent display; The built-in screen and the external screen display content through an application; when the built-in screen and the external screen run the same application, it is considered a different display; when the built-in screen and the external screen run different applications, it is considered an independent display. When the difference is displayed, an external screen display instance is created based on the native presentation class of the Android system, and a custom external screen layout file is loaded according to the external screen display instance to display the difference on the external screen. When displayed independently, the system obtains the launch intent of the application running on the external screen and generates a corresponding program launch configuration. The application is then launched according to the launch intent and program launch configuration, allowing the application running on the external screen to run independently within the external screen. For the differential display mode, its implementation relies on the native display class of the Android system. An external screen display instance is created based on the native display class of the Android system. This native display class is a dialog-style window specifically designed for displaying specific content on the secondary display screen. Developers need to load a custom external screen layout file based on the external screen display instance. This external screen layout file can be completely different from the interface design of the main screen. By calling the display method of the display instance, differential display can be performed on the external screen. This method is lightweight and efficient, suitable for scenarios where interactive operations are required on the main screen while information is displayed on the secondary screen simultaneously, such as main screen control and secondary screen video playback. For standalone display mode, the core is to bind the application process to a specific screen; the application or system needs to obtain the launch intent of the display program running on the external screen, which includes the component information to be launched; at the same time, it generates the corresponding program launch configuration, the key of which is to specify the identifier of the target display; and launches the display program according to the launch intent and program launch configuration; the display program refers to the application used to present content on the screen (such as a navigation APP, video player, custom interface component, etc.). This mechanism allows different instances of the same application or completely different applications to run independently in different screen contexts without interfering with each other, thus achieving true multitasking. For example, in an in-vehicle system, a navigation application can run on the built-in screen while an entertainment application runs on the external screen.

[0029] For example: Differences: The built-in screen runs a video player application (version V1.3) and displays the video playback interface (including a progress bar and volume control buttons); the external screen creates a display instance based on the Android Presentation class, loads the custom layout file "layout_external_video.xml", and only displays the video frame and playback duration, hiding the operation controls; it is suitable for scenarios where "main screen controls and secondary screen displays only", such as operating the main screen of a car navigation system and playing videos on the secondary screen.

[0030] Independent Display: Launch the navigation application (version V3.6) from an external screen with the launch intent "android.intent.action.NAVIGATE". The application launch configuration specifies the target display identifier "DISP_002" and allocates an additional 6MB of memory for map cache storage. The navigation application runs independently without relying on the main screen, and the 6MB map cache can improve offline navigation loading speed.

[0031] During the dual-screen display process, the insertion and removal actions of the external screen are acquired in real time, and resources are allocated according to the insertion and removal actions. The process of allocating resources includes: The insertion and removal actions include insertion and removal; When an external screen is inserted, the display parameters of the external screen are obtained; and independent resources are allocated to the external screen, including a dedicated rendering channel to ensure the independence of its graphics command flow; independent memory space for allocating front / back frame buffers to avoid memory conflicts; and specific window scheduling priorities so that the window management service can correctly handle the focusing, sorting, and compositing relationships of the dual-screen windows. Accordingly, when the external screen is unplugged, the resources of the external screen are released sequentially to prevent resource leakage; and the display identifier of the external screen is removed from the display device list, and the global display topology is updated.

[0032] For example: External screen insertion: GPIO1_0 level is detected to change from 0V to 3.3V. The external screen display parameters are obtained within 100ms. A dedicated rendering channel "CHANNEL_002", 32MB of memory space, and window scheduling priority of 4 are allocated. The 100ms response speed meets the real-time expectations of the user's plug-in and plug-out operation. Dedicated resources ensure that the external screen can run independently without interference.

[0033] External screen unplugged: Upon detecting the GPIO1_0 level changing from 3.3V to 0V, within 200ms, the rendering channel "CHANNEL_002", 32MB of memory, and scheduling priority are released sequentially, and the external screen identifier "DISP_002" is removed from the display device list; resource release is completed within 200ms to avoid memory leaks and ensure efficient utilization of system resources.

[0034] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered exemplary and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

Claims

1. A dual-screen display control method based on the Android system, characterized in that: The method includes the following steps: After initializing the Android system driver, the connection status of the external screen is read, including whether the connection is successful or disconnected; when the external screen is disconnected, single-screen display is performed through the built-in screen. When the external screen is successfully connected, configure the dual-screen display and perform dual-screen display through the built-in screen and the external screen according to the display mode; During the dual-screen display process, the insertion and removal actions of the external screen are acquired in real time, and resources are allocated according to the insertion and removal actions.

2. The dual-screen display control method based on the Android system according to claim 1, characterized in that, The initialization process includes: Configure the hardware parameters of the built-in screen and the external screen in the device tree. The hardware parameters of the built-in screen include resolution, refresh rate, number of data channels, horizontal synchronization duration, vertical synchronization duration, and blanking period duration in each direction. The hardware parameters of the external screen include resolution and refresh rate. The built-in screen is designated as the first independent display controller node, and the external screen is designated as the second independent display controller node.

3. The dual-screen display control method based on the Android system according to claim 2, characterized in that, The initialization process also includes: Write and register a hot-plug interrupt handling function to trigger the hot-plug interrupt handling function when an external screen is plugged in or unplugged. The DRM framework is configured using multi-plane synthesis configuration items and frame buffer simulation configuration items, enabling the DRM framework to support two independent display controllers, two encoders, and two connectors; and the refresh rate of the built-in screen and the external screen is kept consistent through a vertical synchronization signal synchronization mechanism.

4. The dual-screen display control method based on the Android system according to claim 1, characterized in that, The process of configuring dual-screen display includes: Obtain the display parameters of the built-in screen and the display parameters of the external screen, including width, height, refresh rate, and density (DPI). Assign independent display identifiers to the built-in screen and external screen, and disable the mirror display mode of the Android system; The display identifier, along with the corresponding device name and display parameters, are stored in the display device list. The device name includes the built-in screen name and the external screen name. Based on the display identifier, the built-in screen and the external screen are rendered in parallel.

5. The dual-screen display control method based on the Android system according to claim 4, characterized in that, The process of dual-screen display via built-in and external screens according to display mode includes: The display device list is traversed to read the display identifier, as well as the corresponding device name and display parameters, to distinguish between built-in screens and external screens; The display modes include differential display and independent display; The built-in screen and the external screen display content through an application; when the built-in screen and the external screen run the same application, it is considered a different display; when the built-in screen and the external screen run different applications, it is considered an independent display. When the difference is displayed, an external screen display instance is created based on the native display class of the Android system, and a custom external screen layout file is loaded according to the external screen display instance to display the difference on the external screen. When displayed independently, the system obtains the startup intent of the application running on the external screen and generates the corresponding program startup configuration. The application is then launched according to the startup intent and program startup configuration, allowing the application running on the external screen to run independently within the external screen.

6. The dual-screen display control method based on the Android system according to claim 4, characterized in that, The process of allocating resources includes: The insertion and removal actions include insertion and removal; When an external screen is inserted, the display parameters of the external screen are obtained; and independent resources are allocated to the external screen, including rendering channels, memory space, and window scheduling priority. When the external screen is unplugged, the resources of the external screen are released sequentially; and the display identifier of the external screen is removed from the display device list.

7. A dual-screen display control system based on an Android system, which is applied to the dual-screen display control method based on an Android system as described in any one of claims 1-6, characterized in that: The system includes a kernel layer module, a hardware abstraction layer module, a framework layer module, and an application layer module.

8. A dual-screen display control system based on Android system according to claim 7, characterized in that: The kernel layer module is used to initialize the drivers for the Android system; The hardware abstraction layer module is used to read the connection status and display parameters of the external screen in real time.

9. A dual-screen display control system based on Android system according to claim 7, characterized in that: The framework layer module is used to assign independent display identifiers to the built-in screen and the external screen, perform parallel rendering of the built-in screen and the external screen according to the display identifiers, disable the mirror display mode of the Android system, and allocate resources according to the plugging and unplugging actions. The application layer module is used for single-screen display via the built-in screen, or for dual-screen display according to the display mode.

Images