Android application running device and method, computing equipment and machine readable storage medium
By creating a virtual display screen and using the Hardware Abstraction Layer interface and kernel drivers to transmit frames to a non-standard physical display screen, the problem of poor compatibility between non-standard displays and the Android system is solved, achieving efficient and reliable screen display and reducing development costs.
Patent Information
- Application Number
- CN202511051223.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-07-29
- Publication Date
- 2025-11-18
AI Technical Summary
In existing technologies, non-standard physical displays have poor compatibility with the Android system, resulting in high development costs, high complexity, high resource consumption, and limited application development.
By creating a virtual display, the output frames are acquired and processed. The processed output frames are then transmitted to a non-standard physical display using the Hardware Abstraction Layer interface and kernel drivers, thus avoiding the use of the Android display framework.
It enables efficient and reliable display of Android application screens on non-standard physical displays, reduces the amount of Android system driver code and development cycle, and avoids resource consumption of HWC.
Smart Images
Figure CN120973448A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer technology, and more specifically to an Android application running device, method, computing device, and machine-readable storage medium. Background Technology
[0002] In Android applications that display on a physical screen, the physical screen and its kernel driver typically need to conform to the Android display's HAL (Hardware Abstraction Layer) standard and be deeply integrated with HWC (Hardware Composer) to handle the compositing and display of the graphics buffer. This means that the physical screen and its kernel driver provide a standard software interface, allowing the Android system to discover, configure, and control the physical screen through this interface, without needing to know the specific hardware model and control logic of the physical screen. This standard software interface enables unified management of multi-screen displays, allowing the Android system to render images to the target screen.
[0003] However, if any physical display screen and kernel driver are non-standard, the Android system will be unable to recognize the physical display screen, or even if it does recognize it, performance will be degraded and functions will be unavailable, ultimately preventing the display of Android application content. Making such non-standard physical displays compatible with the Android system presents problems such as high development costs, high complexity, significant resource consumption, increased power consumption, and limitations on application development. Summary of the Invention
[0004] The purpose of this application is to provide a device, method, processor, and storage medium for running Android applications, in order to solve the problems in the prior art where, when an external non-standard physical display screen is connected, the development cost is high, the complexity is large, a large amount of resources are consumed, power consumption is increased, and application development is limited, in order to make the non-standard physical display screen compatible with Android standards.
[0005] To achieve the above objectives, in a first aspect, this application provides an Android application running device, which includes: The display creation module is used to create a virtual display and launch the target Android application onto the virtual display. The output frame acquisition module is used to acquire the output frames of the virtual display screen; The output frame processing module is used to perform preset processing on the output frame according to the characteristics of the non-standard physical display screen to obtain the processed output frame. The non-standard physical display screen is a physical display screen that does not support the Android display framework. The output frame transmission module is used to transmit the processed output frame to a non-standard physical display screen through the hardware abstraction layer interface and kernel driver, so as to display the processed output frame on the non-standard physical display screen. The hardware abstraction layer interface does not use the Android display framework.
[0006] In embodiments of this application, the output frame acquisition module includes: The ImageReader submodule is used to create ImageReaders based on the characteristics of the virtual display screen. The ImageReader submodule is used to bind the ImageReader's image to a virtual display screen and obtain the output frames of the virtual display screen through the ImageReader.
[0007] In the embodiments of this application, the output frame transmission module includes: The abstract layer interface definition submodule is used to define the hardware abstraction layer interface between the framework layer and the hardware abstraction layer based on AIDL. The output frame conversion submodule is used to convert the processed output frame into a structure that can be recognized by the kernel driver at the hardware abstraction layer interface. The structure sending submodule is used to send a recognizable structure to the kernel driver based on an ioctl call to obtain the target image data; The image data sending submodule is used to send target image data to a non-standard physical display screen via the kernel driver, so that the processed output frame can be displayed on the non-standard physical display screen.
[0008] In embodiments of this application, the display screen creation module includes: The identifier acquisition submodule is used to create virtual displays and obtain the display identifier of the virtual displays; The Intent Object Construction submodule is used to construct the intent object corresponding to the target Android application; The Android application launcher submodule is used to launch a target Android application onto a virtual display screen based on a display identifier and an intent object.
[0009] In the embodiments of this application, the output frame transmission module includes: The synchronization signal acquisition submodule is used to acquire the preset synchronization signal; The output frame synchronization transmission submodule is used to transmit the processed output frame to a non-standard physical display screen through the hardware abstraction layer interface and kernel driver according to the preset synchronization signal, so that the processed output frame can be displayed on the non-standard physical display screen.
[0010] In the embodiments of this application, the output frame transmission module includes: The attribute value retrieval submodule is used to retrieve the attribute values corresponding to the processed output frame; The post-processing transmission submodule is used to transmit the processed output frame to a non-standard physical display screen through the hardware abstraction layer interface and kernel driver, provided that the attribute value is the target attribute value, so that the processed output frame can be displayed on the non-standard physical display screen.
[0011] In the embodiments of this application, the preset processing includes at least one of rotation, scaling, color conversion, space conversion, and format conversion.
[0012] Secondly, this application provides an Android application running method, which includes: Create a virtual display screen and launch the target Android application onto the virtual display screen; Get the output frame of the virtual display screen; The output frame is pre-processed according to the characteristics of the non-standard physical display screen to obtain the processed output frame. The non-standard physical display screen is a physical display screen that does not support the Android display framework. The processed output frame is transmitted to a non-standard physical display screen through the Hardware Abstraction Layer (HAL) interface and kernel driver, so that the processed output frame can be displayed on the non-standard physical display screen. The HAL interface does not use the Android display framework.
[0013] Thirdly, this application provides a computing device, comprising: The memory is configured to store instructions; The processor is configured to retrieve instructions from memory and, when executing those instructions, to implement the aforementioned Android application execution methods.
[0014] Fourthly, this application provides a machine-readable storage medium storing instructions that cause a machine to execute the above-described Android application running method.
[0015] This application provides an Android application running device, including: a display creation module for creating a virtual display and launching a target Android application onto the virtual display; an output frame acquisition module for acquiring the output frame of the virtual display; an output frame processing module for performing preset processing on the output frame according to the characteristics of a non-standard physical display to obtain a processed output frame, wherein the non-standard physical display is a physical display that does not support the Android display framework; and an output frame transmission module for transmitting the processed output frame to the non-standard physical display through a hardware abstraction layer interface and a kernel driver, so as to display the processed output frame on the non-standard physical display, wherein the hardware abstraction layer interface does not use the Android display framework. By using a virtual display and a custom hardware abstraction layer interface that does not use the Android display framework, the image screen of the Android application can be transmitted to a physical display that does not support the Android standard display framework, which can efficiently and reliably display the screen content of the Android application, thereby realizing multi-screen display. In addition, it significantly reduces the amount of Android system driver code and development cycle, and avoids the resource consumption of complex HWC.
[0016] Other features and advantages of the embodiments of the present invention will be described in detail in the following detailed description section. Attached Figure Description
[0017] The accompanying drawings are provided to further illustrate embodiments of the present invention and form part of the specification. They are used together with the following detailed description to explain the embodiments of the present invention, but do not constitute a limitation thereof. In the drawings: Figure 1 A schematic diagram of the structure of the Android application running device provided in the embodiments of this application is shown; Figure 2 A flowchart of the Android application running method provided in the embodiments of this application is shown. Detailed Implementation
[0018] The specific embodiments of the present invention will now be described in detail with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for illustrative and explanatory purposes only and are not intended to limit the scope of the present invention.
[0019] The components of the embodiments of the invention described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.
[0020] In the following, the terms “comprising,” “having,” and their cognates, which may be used in various embodiments of the invention, are intended only to indicate a particular feature, number, step, operation, element, component, or combination thereof, and should not be construed as excluding, firstly, the presence of one or more other features, numbers, steps, operations, elements, components, or combinations thereof, or adding the possibility of one or more features, numbers, steps, operations, elements, components, or combinations thereof.
[0021] Furthermore, the terms "first," "second," and "third" are used only to distinguish descriptions and should not be interpreted as indicating or implying relative importance.
[0022] Unless otherwise specified, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which the various embodiments of the invention pertain. Terms (such as those defined in commonly used dictionaries) shall be interpreted as having the same meaning as in their contextual meaning in the relevant technical field and shall not be interpreted as having an idealized or overly formal meaning, unless clearly defined in the various embodiments of the invention.
[0023] For Android systems, the physical display interface and kernel driver typically need to meet the standard requirements supporting the Android display framework. This allows upper-layer graphics systems such as SurfaceFlinger and HWC to work with the display driver, ensuring that image data can be transmitted to the physical display with high bandwidth and low latency. Displays with simple interfaces such as SPI (Serial Peripheral Interface) and I2C (Inter-Integrated Circuit) buses do not meet the standard requirements, thus preventing multi-screen display.
[0024] Specifically, Android systems require the transmission of large amounts of image data in a short period of time, while simple interfaces such as SPI and I2C are used for signal control or low-speed, small-volume data exchange, and their data transmission rates are far from sufficient to support continuous full-screen image data transmission.
[0025] Android's graphics composition relies on precise vertical synchronization signals to coordinate buffer switching and page flipping, preventing screen tearing and latency. This requires the underlying interface and hardware controller to generate, capture, and transmit synchronization signals in each refresh cycle. Simple interfaces like SPI and I2C typically lack dedicated hardware mechanisms to generate stable signals or support low-latency interrupts, making them unsuitable for timing control. Furthermore, to improve smoothness and reduce flicker, Android displays often employ multi-buffered structures such as double and triple buffering, requiring the display interface hardware to support fast and seamless page flipping. Simple interfaces typically only provide basic data transmission functions and cannot implement complex multi-buffered management and page synchronization mechanisms.
[0026] Android system display drivers not only need to output data to the physical display screen, but also need to support memory mapping, direct buffer access, multi-tasking collaborative processing, hardware acceleration, and secure display. Simple interfaces typically only meet basic read and write operations and struggle to support features such as multi-buffering, DMA transfer, dedicated interrupts, and efficient memory allocation. Furthermore, upper-layer graphics systems like SurfaceFlinger and HWC rely on standardized and high-performance hardware interfaces to maintain the performance of the entire display pipeline. When a simple interface serves as the lower-layer interface, the lack of support for features such as high-speed data channels, hardware synchronization, and dedicated resource management makes it difficult to establish an efficient collaborative working mechanism between the upper-layer interface and the driver, thus affecting the overall window display quality and smoothness of the Android system.
[0027] Furthermore, simple interfaces such as SPI and I2C are primarily used for low-speed communication scenarios such as device configuration, sensor data exchange, and peripheral command control, not for continuous high-definition video display. Even if some simple interfaces can be used to transmit image data, they typically only meet the basic needs of small display devices with low resolution and low refresh rates, and cannot meet the display requirements of the Android system.
[0028] Upper-layer graphics systems such as SurfaceFlinger and HWC require the underlying display driver to provide a variety of functions, placing extremely high demands on the data path. Simple interfaces such as SPI and I2C cannot meet the needs of high data volume transmission, cannot provide fine timing control and synchronization, cannot provide memory mapping and hardware acceleration functions, and are mismatched with application scenarios, thus making it difficult to meet the standard requirements of the Android system.
[0029] Forcing compatibility between Android and non-standard displays with simple interfaces requires significant resources for driver development and adaptation, resulting in high development costs and complexity, as well as additional resource consumption and power consumption. Furthermore, non-standard display applications face limitations, unable to utilize mature, standard Android application development models and UI (User Interface) frameworks, thus restricting the application ecosystem and development efficiency.
[0030] Example 1 Please see Figure 1 , Figure 1 A schematic diagram of the structure of the Android application running device provided in the embodiments of this application is shown. Figure 1 The Android application running device 200 includes: Display creation module 210 is used to create a virtual display and launch the target Android application onto the virtual display.
[0031] The output frame acquisition module 220 is used to acquire the output frame of the virtual display screen.
[0032] The output frame processing module 230 is used to perform preset processing on the output frame according to the characteristics of the non-standard physical display screen to obtain the processed output frame. The non-standard physical display screen is a physical display screen that does not support the Android display framework.
[0033] The output frame transmission module 240 is used to transmit the processed output frame to a non-standard physical display screen through the hardware abstraction layer interface and the kernel driver, so as to display the processed output frame on the non-standard physical display screen. The hardware abstraction layer interface does not use the Android display framework and does not need to support memory mapping, direct buffer access, multi-task collaborative processing, hardware acceleration and security display.
[0034] In this embodiment, the application running method is applied to a target device based on the Android system. The type of target device is set according to actual needs and can be a mobile phone, tablet computer, etc., and is not limited here. For ease of understanding, in this embodiment, the custom framework layer service of the Android system is named LsPresentationService, which is used to transmit the image screen of the target Android application to a non-standard physical display screen and manage the display of the non-standard physical display screen.
[0035] After the Android system starts, LsPresentationService creates a virtual display screen through DisplayManager. The parameters of the virtual display screen are set according to actual needs and are not limited here. For ease of understanding, in the embodiments of this application, the virtual display screen is named LocalLsVirtualSubDisplay, with a size of 284*240 pixels and a resolution of 220.
[0036] After creating the virtual display, DisplayManager sends a notification to LsPresentationService to inform the Android application that a usable virtual display has been added. The target Android application is then launched onto the virtual display, forcing it to be displayed only on the virtual display, meaning it cannot be displayed on the target device's home screen.
[0037] The target Android application generates frame-by-frame images on a virtual display screen; that is, the target Android application renders its UI on the virtual display screen. Capturing the output frames rendered by the virtual display screen yields the image display rendered by the target Android application.
[0038] In this embodiment, the non-standard physical display screen is a physical display screen that does not support the Android display framework, such as a physical display screen using simple interfaces like SPI and I2C. The output frame is pre-processed according to the characteristics of the non-standard physical display screen to obtain a processed output frame that is adapted to the characteristics of the non-standard physical display screen.
[0039] The processed output frames are transmitted to a non-standard physical display screen via the Hardware Abstraction Layer (HAL) interface and kernel driver. In this embodiment, the HAL interface is independent of the Android display compositing framework, meaning it does not use the integrated HWC framework and displays the processed output frames on a non-standard physical display screen. By using a virtual display screen and a custom HAL interface that does not use the Android display framework, the image screen of the Android application is transmitted to a physical display screen that does not support the standard Android display framework, enabling efficient and reliable display of the Android application's screen content, thereby achieving multi-screen display. Furthermore, it significantly reduces the amount of Android system driver code and development cycle, and avoids the resource consumption of complex HWC.
[0040] In embodiments of this application, the output frame acquisition module 220 includes: The ImageReader submodule is used to create ImageReaders based on the characteristics of the virtual display screen. The Display Output Frame Acquisition and Creation submodule is used to bind the ImageReader's image to the virtual display screen and acquire the output frames of the virtual display screen through the ImageReader.
[0041] ImageReader is a class provided by the Android system used to obtain image data from different sources such as files and buffers, and can access image data rendered to the Surface (canvas). In this embodiment, ImageReader is used to capture the output frames of the virtual display.
[0042] Specifically, an ImageReader is created based on the characteristics of the virtual display screen. The ImageReader is then bound to the virtual display screen. In this example, a Surface of the ImageReader that receives RGBA_8888 format images is created as the output of the virtual display screen. That is, the Surface of the ImageReader is used as the canvas of the virtual display screen to receive high-precision images in RGBA_8888 format.
[0043] Register `onImageAvailable` to set up an image listener. The target Android application renders on a virtual display screen. The display screen output frame acquisition submodule is used to bind the image of the `ImageReader` to the virtual display screen. The `ImageReader`'s `Surface` serves as the rendering target of the virtual display screen. All image frames rendered by the target Android application to the virtual display screen can be output to the `ImageReader`, which then captures the output frames of the virtual display screen. By using `ImageReader` as a bridge between the virtual and physical display screens, the standard application development experience is preserved while avoiding strong dependence on HWC, thus enabling the redirection of Android application image streams to non-standard physical display screens.
[0044] HardwareBuffer is a buffer object for ImageReader, used by the Android system to share image data between processes or between the CPU (Central Processing Unit) and GPU (Graphics Processing Unit). The onImageAvailable callback of ImageReader is triggered, passing in the HardwareBuffer containing the rendering result. In other words, the Android system obtains the image from the target Android application through onImageAvailable, where HardwareBuffer provides the raw data. The HardwareBuffer is then wrapped as a Bitmap to process the raw data into a standard format for easier subsequent processing.
[0045] In embodiments of this application, the output frame transmission module 240 includes: The Hardware Abstraction Layer Interface Definition submodule is used to define the Hardware Abstraction Layer interface between the framework layer and the Hardware Abstraction Layer based on AIDL. The output frame conversion submodule is used to convert the processed output frame into a structure that can be recognized by the kernel driver at the hardware abstraction layer interface. The structure sending submodule is used to send a recognizable structure to the kernel driver based on an ioctl call to obtain the target image data; The image data sending submodule is used to send target image data to a non-standard physical display screen via the kernel driver, so that the processed output frame can be displayed on the non-standard physical display screen.
[0046] AIDL (Android Interface Definition Language) is used to define interfaces for inter-process communication between clients and servers, allowing processes to exchange messages, synchronize states, and share data, thus overcoming the isolation limitations of process address spaces. This application defines the Hardware Abstraction Layer (HAL) interface between the framework layer and the Hardware Abstraction Layer (HAL). The AIDL-based custom HAL interface is independent of the Android display framework, meaning it does not use HWC (Hardware Overlay). The HAL interface converts the processed output frame into a structure recognizable by the kernel driver. The data in this recognizable structure is set according to actual needs and can be image data and control commands recognizable by the kernel driver; no specific limitations are imposed here. For ease of understanding, in the embodiments of this application, the recognizable structure includes coordinates and an RGB565-byte array. The recognizable structure is labeled with the service address to determine its location and size.
[0047] ioctl (Input / Output Control) is a system call used for communication between device kernel drivers and user-space applications, allowing the transmission of control commands and image data. ioctl calls allow user-space programs to interact with device drivers through specific commands, performing control functions that standard read / write operations cannot achieve. Flexible device control is achieved through command codes. Based on ioctl calls, recognizable structures are sent to the kernel driver to obtain the target image data.
[0048] The target image data is sent to a non-standard physical display screen via the kernel driver to display the processed output frame. In this embodiment, the kernel driver copies the target image data, adjusts its byte order, and places it in a sending queue. Based on the sending queue, the target image data is sequentially sent to the non-standard physical display screen via its SPI interface to display the processed output frame. It's important to understand that after sending the target image data, the hardware buffer is discarded into the recycle bin to facilitate the sending of subsequent target image data. The communication interface between the AIDL-defined framework layer and the hardware abstraction layer is defined, and image data is transmitted between the hardware abstraction layer and the kernel driver layer via ioctl calls. This bypasses the limitations of the Android standard display framework HWC and achieves short-path data transmission, enabling efficient and reliable display of the image using simple interfaces such as the SPI interface.
[0049] In embodiments of this application, the display screen creation module 210 includes: The identifier acquisition submodule is used to create virtual displays and obtain the display identifier of the virtual displays; The intent object construction submodule is used to construct the intent object corresponding to the target Android application; The Android application launcher submodule is used to launch a target Android application onto a virtual display screen based on a display identifier and an intent object.
[0050] Specifically, ActivityOptions refers to the options in Android used to specify the launch method of an Activity (application). For ease of understanding, in this embodiment of the application, the standard Android application is directed to a virtual display screen using ActivityOptions.setLaunchDisplayId. Specifically, a virtual display screen is created, and the display identifier (displayId) of the virtual display screen is obtained.
[0051] `ActivityOptions.setLaunchDisplayId` is a standard API (Application Programming Interface) used to set the display screen ID on which an Activity is launched. In scenarios with multiple displays, it allows specifying which display screen the Activity will be displayed on. An Intent object corresponding to the target Android application is constructed. Based on the display identifier and the Intent object, the Intent for launching the target Android application is executed, launching the target Android application onto the virtual display screen. In this embodiment, `ActivityOptions.setLaunchDisplayId` is used to launch the target Android application with the package name `SUB_APP_PACKAGE` and the ACTIVITY name `SUB_APP_ACTIVITY` onto the virtual display screen.
[0052] The target Android application does not need to be aware of whether it is running on a virtual display screen. Its image can be transmitted to the display screen without modifying its code. By directing the target Android application's rendering to an ImageReader, HWC limitations are bypassed, allowing non-standard physical displays to display images even if they do not meet HAL standard requirements. This achieves efficient and reliable display on non-standard physical displays while maintaining development simplicity.
[0053] In embodiments of this application, the output frame transmission module 240 includes: The synchronization signal acquisition submodule is used to acquire the preset synchronization signal; The output frame synchronization transmission submodule is used to transmit the processed output frame to a non-standard physical display screen through the hardware abstraction layer interface and kernel driver according to the preset synchronization signal, so that the processed output frame can be displayed on the non-standard physical display screen.
[0054] Tearing Effect (TE) is a phenomenon that occurs when the display refresh and content update are out of sync. In this embodiment, the preset synchronization signal is a TE signal, used to prevent screen tearing. The target device in this embodiment also includes a kernel driver, which receives image buffer data and controls the physical display screen for display. Based on the preset synchronization signal, the processed output frame is transmitted to a non-standard physical display screen via the hardware abstraction layer interface for display. For ease of understanding, in this embodiment, the non-standard physical display screen interface is an SPI interface. The SPI interface transmits one screen of image data before transmitting a new screen of image data. By using the TE signal synchronization transmission mechanism and managing multiple buffers and data transmission, the display efficiency is improved, and display anomalies are avoided.
[0055] In embodiments of this application, the output frame transmission module 240 includes: The attribute value retrieval submodule is used to retrieve the attribute values corresponding to the processed output frame; The post-processing transmission submodule is used to transmit the processed output frame to a non-standard physical display screen through the hardware abstraction layer interface and kernel driver, provided that the attribute value is the target attribute value, so that the processed output frame can be displayed on the non-standard physical display screen.
[0056] The attribute values corresponding to the processed output frames are obtained. These attribute values are set according to actual needs and are not limited here. For ease of understanding, in the embodiments of this application, the attribute value is last_prop_open_overlay_value (the last supported open overlay value), and it is determined whether the attribute value is the target attribute value.
[0057] When the attribute value is the target attribute value, the processed output frame is transmitted to a non-standard physical display screen via the Hardware Abstraction Layer (HAL) interface for display. When the attribute value is not the target attribute value, the processed output frame can be used to update the interface of another Activity, or no transmission processing can be performed on the output frame; this will not be elaborated upon here. Conditional display of the screen based on attribute values increases the flexibility of the Android system's display content.
[0058] In the embodiments of this application, the preset processing includes at least one of rotation, scaling, color conversion, space conversion, and format conversion.
[0059] The output frame is pre-processed according to the characteristics of non-standard physical displays, such as wrapping the HardwareBuffer into a Bitmap to obtain the processed output frame. In this embodiment, the pre-processing includes at least one of rotation, scaling, color conversion, spatial conversion, and format conversion. It should be understood that the pre-processing may also include other processing, which is set according to actual needs and may be image smoothing, etc., which are not limited here.
[0060] When the image on a non-standard physical display is tilted, rotation can correct the image. Scaling can compress the output frame size to match the dimensions of the non-standard physical display. In this embodiment, format conversion converts the RGBA_8888 format output frame to RGB565 format, providing a recognizable output frame for non-standard physical displays, thus efficiently and reliably displaying the target Android application's image.
[0061] This application provides an Android application running device, including: a display creation module for creating a virtual display and launching a target Android application onto the virtual display; an output frame acquisition module for acquiring the output frame of the virtual display; an output frame processing module for performing preset processing on the output frame according to the characteristics of a non-standard physical display to obtain a processed output frame, wherein the non-standard physical display is a physical display that does not support the Android display framework; and an output frame transmission module for transmitting the processed output frame to the non-standard physical display through a hardware abstraction layer interface and a kernel driver, so as to display the processed output frame on the non-standard physical display, wherein the hardware abstraction layer interface does not use the Android display framework. By using a virtual display and a defined hardware abstraction layer interface that does not use the Android display framework, the image screen of the Android application can be transmitted to a physical display that does not support the Android standard display framework, which can efficiently and reliably display the screen content of the Android application, thereby realizing multi-screen display. In addition, it significantly reduces the amount of Android system driver code and development cycle, and avoids the resource consumption of complex HWC.
[0062] Example 2 Please see Figure 2 , Figure 2 A flowchart of the Android application running method provided in the embodiments of this application is shown. Figure 2 The methods for running Android applications include: S110 creates a virtual display screen and launches the target Android application onto the virtual display screen; S120, Obtain the output frame of the virtual display screen; S130 performs preset processing on the output frame according to the characteristics of the non-standard physical display screen to obtain the processed output frame. The non-standard physical display screen is a physical display screen that does not support the Android display frame. S140 transmits the processed output frame to a non-standard physical display screen through the Hardware Abstraction Layer (HAL) interface and kernel driver, so as to display the processed output frame on the non-standard physical display screen. The HAL interface does not use the Android display framework.
[0063] In the embodiments of this application, obtaining the output frame of the virtual display screen includes: Create an ImageReader based on the characteristics of the virtual display screen; Bind the ImageReader's image to the virtual display screen, and obtain the output frames of the virtual display screen through the ImageReader.
[0064] In the embodiments of this application, the processed output frame is transmitted to a non-standard physical display screen through a hardware abstraction layer interface and a kernel driver, so as to display the processed output frame on the non-standard physical display screen, including: The hardware abstraction layer interface between the framework layer and the hardware abstraction layer is defined based on AIDL. The hardware abstraction layer interface converts the processed output frame into a structure that the kernel driver can recognize. The target image data is obtained by sending a recognizable structure to the kernel driver via an ioctl call. The target image data is sent to a non-standard physical display via the kernel driver so that the processed output frame can be displayed on the non-standard physical display.
[0065] In the embodiments of this application, creating a virtual display screen and launching the target Android application onto the virtual display screen includes: Create a virtual display screen and obtain its display identifier; Construct the intent object corresponding to the target Android application; Launch the target Android application onto a virtual display screen based on the display identifier and intent object.
[0066] In the embodiments of this application, the processed output frame is transmitted to a non-standard physical display screen through a hardware abstraction layer interface and a kernel driver, so as to display the processed output frame on the non-standard physical display screen, including: Obtain the preset synchronization signal; Based on the preset synchronization signal, the processed output frame is transmitted to a non-standard physical display screen through the hardware abstraction layer interface and kernel driver so that the processed output frame can be displayed on the non-standard physical display screen.
[0067] In the embodiments of this application, the processed output frame is transmitted to a non-standard physical display screen through a hardware abstraction layer interface and a kernel driver, so as to display the processed output frame on the non-standard physical display screen, including: Obtain the attribute values corresponding to the processed output frame; When the attribute value is the target attribute value, the processed output frame is transmitted to a non-standard physical display screen through the hardware abstraction layer interface and kernel driver so that the processed output frame can be displayed on the non-standard physical display screen.
[0068] In the embodiments of this application, the preset processing includes at least one of rotation, scaling, color conversion, space conversion, and format conversion.
[0069] This application embodiment also provides a computing device, including: The memory is configured to store instructions; The processor is configured to retrieve instructions from memory and, when executing those instructions, to implement the aforementioned Android application execution methods.
[0070] In this embodiment, the display creation module 210, output frame acquisition module 220, output frame processing module 230, and output frame transmission module 240 are all stored in the memory as program units, and the processor executes the above-mentioned program units stored in the memory to realize the corresponding functions.
[0071] The processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured, and the aforementioned sequential land partitioning method can be implemented by adjusting kernel parameters.
[0072] The memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.
[0073] This application also provides a machine-readable storage medium storing instructions that cause a machine to execute the above-described Android application running method.
[0074] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0075] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0076] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0077] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0078] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.
[0079] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, like read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.
[0080] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.
[0081] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.
[0082] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.
Claims
1. An Android application running device, characterized in that, The Android application running device includes: The display creation module is used to create a virtual display and launch the target Android application onto the virtual display; The output frame acquisition module is used to acquire the output frame of the virtual display screen; The output frame processing module is used to perform preset processing on the output frame according to the characteristics of the non-standard physical display screen to obtain the processed output frame, wherein the non-standard physical display screen is a physical display screen that does not support the Android display framework. An output frame transmission module is used to transmit the processed output frame to the non-standard physical display screen through a hardware abstraction layer interface and a kernel driver, so as to display the processed output frame on the non-standard physical display screen, wherein the hardware abstraction layer interface does not use the Android display framework.
2. The Android application running device according to claim 1, characterized in that, The output frame acquisition module includes: The ImageReader creation submodule is used to create an ImageReader based on the characteristics of the virtual display screen; The display output frame acquisition submodule is used to bind the image of the ImageReader to the virtual display screen and acquire the output frame of the virtual display screen through the ImageReader.
3. The Android application running device according to claim 1, characterized in that, The output frame transmission module includes: The Hardware Abstraction Layer Interface Definition submodule is used to define the Hardware Abstraction Layer interface between the framework layer and the Hardware Abstraction Layer based on AIDL. The output frame conversion submodule is used to convert the processed output frame into a structure that can be recognized by the kernel driver at the hardware abstraction layer interface. The structure sending submodule is used to send the recognizable structure to the kernel driver based on an ioctl call to obtain the target image data; The image data sending submodule is used to send the target image data to the non-standard physical display screen through the kernel driver, so as to display the processed output frame on the non-standard physical display screen.
4. The Android application running device according to claim 1, characterized in that, The display screen creation module includes: The identifier acquisition submodule is used to create a virtual display screen and acquire the display identifier of the virtual display screen; The intent object construction submodule is used to construct the intent object corresponding to the target Android application; The Android application launch submodule is used to launch the target Android application to the virtual display screen based on the display identifier and the intent object.
5. The Android application running device according to claim 1, characterized in that, The output frame transmission module includes: The synchronization signal acquisition submodule is used to acquire the preset synchronization signal; The output frame synchronization transmission submodule is used to transmit the processed output frame to the non-standard physical display screen through the hardware abstraction layer interface and kernel driver according to the preset synchronization signal, so as to display the processed output frame through the non-standard physical display screen.
6. The Android application running device according to claim 1, characterized in that, The output frame transmission module includes: The attribute value acquisition submodule is used to acquire the attribute values corresponding to the processed output frame. The post-processing transmission submodule is used to transmit the processed output frame to the non-standard physical display screen through the hardware abstraction layer interface and the kernel driver when the attribute value is the target attribute value, so as to display the processed output frame on the non-standard physical display screen.
7. The Android application running device according to claim 1, characterized in that, The preset processing includes at least one of rotation, scaling, color conversion, space conversion, and format conversion.
8. A method for running an Android application, characterized in that, The method for running the Android application includes: Create a virtual display screen and launch the target Android application onto the virtual display screen; Obtain the output frame of the virtual display screen; The output frame is pre-processed according to the characteristics of the non-standard physical display screen to obtain the processed output frame, wherein the non-standard physical display screen is a physical display screen that does not support the Android display framework. The processed output frame is transmitted to the non-standard physical display screen through the Hardware Abstraction Layer (HAL) interface and kernel driver, so as to display the processed output frame on the non-standard physical display screen. The HAL interface does not use the Android display framework.
9. A computing device, characterized in that, include: The memory is configured to store instructions; The processor is configured to retrieve the instructions from the memory and, when executing the instructions, to implement the Android application running method according to claim 8.
10. A machine-readable storage medium, characterized in that, The machine-readable storage medium stores instructions for causing the machine to execute the Android application running method according to claim 8.