Screen sharing method and system between open source gap and Android application, terminal and storage medium
By constructing a shared memory pool and target layer, screen sharing between open-source HarmonyOS and Android applications was achieved, solving the problem that existing technologies could not achieve screen sharing, and realizing cross-platform screen sharing compatibility and performance stability.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- 深圳开鸿数字产业发展有限公司
- Filing Date
- 2025-12-26
- Publication Date
- 2026-05-15
AI Technical Summary
Existing technologies cannot achieve screen sharing between open-source HarmonyOS applications and Android applications, thus failing to meet users' screen sharing needs.
By obtaining screen sharing requests from Android applications, memory allocation is performed, a shared memory pool is built, and the host device's desktop graphics data is obtained. The callback interface is determined, the desktop graphics data is written into the shared memory pool, the target layer is built and cached, and finally screen sharing is achieved.
It enables screen sharing between open-source HarmonyOS applications and Android applications, with good compatibility, stable performance, and cross-platform screen sharing support, solving the compatibility issues of existing technologies.
Smart Images
Figure CN122044713A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer technology, and in particular to a method, system, terminal, and storage medium for screen sharing between open-source HarmonyOS and Android applications. Background Technology
[0002] Screen sharing is an important feature of Android applications, allowing users to share their device screen content with other applications or users in real time. It is a key technology for connecting digital scenarios and has good practicality.
[0003] Existing screen sharing methods mostly rely on the SurfaceFlinger service of the Android operating system to create virtual screens and layer composite functions, and obtain the current desktop's graphical data to render to the other end. However, this screen sharing method cannot achieve screen sharing between open-source HarmonyOS applications and Android applications, and cannot meet users' screen sharing needs. The SurfaceFlinger service is a system service in the Android system, which is mainly responsible for managing and compositing all visible content of the application interface.
[0004] Therefore, existing technologies still need to be improved and developed. Summary of the Invention
[0005] The main objective of this invention is to provide a screen sharing method, system, terminal, and storage medium between open-source HarmonyOS and Android applications, aiming to solve the problem that existing screen sharing methods cannot achieve screen sharing between open-source HarmonyOS applications and Android applications, and cannot meet users' screen sharing needs.
[0006] To achieve the above objectives, this invention provides a screen sharing method between open-source HarmonyOS and Android applications, comprising the following steps: Obtain the screen sharing request from the Android application, perform memory allocation processing based on the screen sharing request to obtain a shared memory pool, obtain the desktop graphics data of the host machine, determine the callback interface, and write the desktop graphics data into the shared memory pool through the callback interface to obtain multiple shared graphics data. The target layer is obtained by performing layer construction processing based on multiple shared graphic data; The target layer is cached and written to obtain a target graphics cache. The Android application is then rendered based on the target graphics cache to obtain a screen sharing result.
[0007] Optionally, the screen sharing method between open-source HarmonyOS and Android applications, wherein obtaining the screen sharing request from the Android application, performing memory allocation processing based on the screen sharing request to obtain a shared memory pool, obtaining the desktop graphics data of the host machine, determining a callback interface, and writing the desktop graphics data into the shared memory pool through the callback interface to obtain multiple shared graphics data, specifically includes: Obtain the screen sharing request from the Android application, perform memory allocation processing based on the screen sharing request to obtain a shared memory pool, and perform virtual screen creation processing on the host machine based on the screen sharing request to obtain the host machine virtual screen; The desktop graphics data of the host machine is obtained, and the desktop graphics data is combined into the virtual screen of the host machine to obtain the initial graphics data; Determine the callback interface, obtain multiple timestamps, and write the initial graphics data into the shared memory pool according to the multiple timestamps through the callback interface to obtain multiple shared graphics data.
[0008] Optionally, the screen sharing method between open-source HarmonyOS and Android applications, wherein the step of performing layer construction processing based on multiple shared graphic data to obtain a target layer specifically includes: Obtain the current timestamp, and filter multiple shared graphic data based on the current timestamp to obtain the peer graphic data; The target layer is obtained by performing layer construction processing based on the graphics data from the other end.
[0009] Optionally, the screen sharing method between open-source HarmonyOS and Android applications, wherein the step of performing layer construction processing based on the peer graphics data to obtain the target layer specifically includes: The initial layer is obtained by performing layer initialization processing based on the aforementioned end-to-end graphic data; Obtain the screen display attributes, configure the initial layer according to the screen display attributes, and obtain the target layer.
[0010] Optionally, the screen sharing method between open-source HarmonyOS and Android applications, wherein obtaining screen display attributes and configuring the initial layer according to the screen display attributes to obtain the target layer specifically includes: Obtain screen display attributes, and perform scaling configuration processing on the initial layer according to the screen display attributes to obtain the first intermediate layer; The first intermediate layer is centered to obtain the second intermediate layer; Obtain the rendering attribute configuration, process the rendering configuration of the second intermediate layer, and obtain the target layer.
[0011] Optionally, in the aforementioned screen sharing method between open-source HarmonyOS and Android applications, the screen display attributes include host machine display attributes and Android application display attributes; The step of obtaining screen display attributes and scaling the initial layer according to the screen display attributes to obtain the first intermediate layer specifically includes: Obtain the host device display attributes and the Android application display attributes, and calculate the scaling ratio based on the host device display attributes and the Android application display attributes to obtain the target scaling ratio; The initial layer is scaled according to the target scaling ratio to obtain the first intermediate layer.
[0012] Optionally, the screen sharing method between open-source HarmonyOS and Android applications, wherein the step of performing cache writing processing based on the target layer to obtain a target graphics cache, and performing screen rendering processing on the Android application based on the target graphics cache to obtain a screen sharing result, specifically includes: Based on the screen sharing request, the Android application performs virtual screen creation processing to obtain the peer virtual screen; The target graphics cache is obtained by performing cache writing processing on the peer virtual screen according to the target layer; The Android application is rendered based on the target graphics cache to obtain the screen sharing result.
[0013] Furthermore, to achieve the above objectives, the present invention also provides a screen sharing system between open-source HarmonyOS and Android applications, wherein the screen sharing system between open-source HarmonyOS and Android applications includes: The data sharing module is used to obtain screen sharing requests from Android applications, perform memory allocation processing based on the screen sharing requests to obtain a shared memory pool, obtain desktop graphics data from the host machine, determine the callback interface, and write the desktop graphics data into the shared memory pool through the callback interface to obtain multiple shared graphics data. The layer construction module is used to perform layer construction processing based on multiple shared graphic data to obtain the target layer; The screen rendering module is used to perform cache writing processing based on the target layer to obtain the target graphics cache, and to perform screen rendering processing on the Android application based on the target graphics cache to obtain the screen sharing result.
[0014] Furthermore, to achieve the above objectives, the present invention also provides a terminal, wherein the terminal includes: a memory, a processor, and a screen sharing program between open-source HarmonyOS and Android applications stored on the memory and executable on the processor, wherein when the screen sharing program between open-source HarmonyOS and Android applications is executed by the processor, it implements the steps of the screen sharing method between open-source HarmonyOS and Android applications as described above.
[0015] Furthermore, to achieve the above objectives, the present invention also provides a computer-readable storage medium, wherein the computer-readable storage medium stores a screen sharing program between open-source HarmonyOS and Android applications, and when the screen sharing program between open-source HarmonyOS and Android applications is executed by a processor, it implements the steps of the screen sharing method between open-source HarmonyOS and Android applications as described above.
[0016] In this invention, a screen sharing request from an Android application is obtained. Memory allocation is performed based on the request to obtain a shared memory pool. Desktop graphics data from the host machine is also obtained, and a callback interface is determined. The desktop graphics data is written into the shared memory pool through the callback interface, resulting in multiple shared graphics data sets. Layer construction is performed based on these shared graphics data sets to obtain a target layer. A cache write operation is performed on the target layer to obtain a target graphics cache. Finally, screen rendering is performed on the Android application based on the target graphics cache to obtain the screen sharing result. This invention constructs a target layer based on the host machine's desktop graphics data and builds a graphics cache based on the target layer, sharing the host machine's desktop with the Android application, thus achieving screen sharing between open-source HarmonyOS applications and Android applications. Attached Figure Description
[0017] Figure 1 This is a flowchart of a preferred embodiment of the screen sharing method between open-source HarmonyOS and Android applications of the present invention; Figure 2 This is a flowchart illustrating the specific implementation process of step S10 in a preferred embodiment of the screen sharing method between open-source HarmonyOS and Android applications of the present invention. Figure 3 This is a flowchart illustrating the specific implementation process of step S20 in a preferred embodiment of the screen sharing method between open-source HarmonyOS and Android applications of the present invention. Figure 4 This is a flowchart illustrating the specific implementation process of step S30 in a preferred embodiment of the screen sharing method between open-source HarmonyOS and Android applications of the present invention. Figure 5 This is a system overall flowchart of a preferred embodiment of the screen sharing method between open-source HarmonyOS and Android applications of the present invention; Figure 6 This is a flowchart illustrating the layer construction process of a preferred embodiment of the screen sharing method between open-source HarmonyOS and Android applications of the present invention. Figure 7 This is a structural diagram of a preferred embodiment of the screen sharing system between open-source HarmonyOS and Android applications of the present invention; Figure 8 This is a structural diagram of a preferred embodiment of the terminal of the present invention. Detailed Implementation
[0018] To make the objectives, technical solutions, and advantages of this invention clearer and more explicit, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.
[0019] Screen sharing is an important feature of Android applications, allowing users to share their device screen content with other applications or users in real time. It is a key technology for connecting digital scenarios and has good practicality.
[0020] Existing screen sharing methods mostly rely on the SurfaceFlinger service of the Android operating system to create virtual screens and layer composite functions, and then obtain the current desktop's graphical data to render to the other end. However, this screen sharing method cannot achieve screen sharing between open-source HarmonyOS applications and Android applications, and cannot meet users' screen sharing needs.
[0021] To address the aforementioned issues, this invention proposes a screen sharing method between open-source HarmonyOS and Android applications. A target layer is constructed based on the host machine's desktop graphics data, and a graphics cache is built based on the target layer. The host machine's desktop is then shared with the Android application, thus achieving screen sharing between open-source HarmonyOS applications and Android applications.
[0022] The screen sharing method between open-source HarmonyOS and Android applications described in the preferred embodiment of the present invention, such as... Figure 1 As shown, the screen sharing method between the open-source HarmonyOS and Android applications includes the following steps: Step S10: Obtain the screen sharing request from the Android application, perform memory allocation processing based on the screen sharing request to obtain a shared memory pool, obtain the desktop graphics data of the host machine, determine the callback interface, and write the desktop graphics data into the shared memory pool through the callback interface to obtain multiple shared graphics data.
[0023] SurfaceFlinger, as one of the core services of the Android operating system, primarily has the following responsibilities: 1. Allocate a graphics buffer to store graphics data; 2. Combine the graphic data into the buffer; 3. Manage vertical synchronization (VSync) events.
[0024] On the Android platform, each application window has a corresponding drawing surface, and its corresponding graphics buffer is allocated by SurfaceFlinger. SurfaceFlinger manages these surfaces in the form of layers. When the VSync event arrives, all the rendered visible Surfaces are consumed by SurfaceFlinger, composited, and finally displayed on the Android desktop.
[0025] In addition, both Android and the open-source Harmony OS obtain the current desktop graphics data by creating a virtual screen.
[0026] Therefore, as explained above, Android applications share screens using the virtual screen and layer composition functions provided by SurfaceFlinger, which provides the basis for this invention.
[0027] like Figure 2 As shown, step S10 specifically includes: Step S11: Obtain the screen sharing request from the Android application, perform memory allocation processing based on the screen sharing request to obtain a shared memory pool, and perform virtual screen creation processing on the host machine based on the screen sharing request to obtain the host machine virtual screen.
[0028] Specifically, step S11 is implemented as follows: The first step is to develop a desktop sharing service for the host machine using the open-source HarmonyOS operating system.
[0029] When an Android application enables screen sharing, it notifies the desktop sharing service on the host machine via the SurfaceFlinger service.
[0030] Step S12: Obtain the desktop graphics data of the host machine, and synthesize the desktop graphics data into the virtual screen of the host machine to obtain the initial graphics data.
[0031] Specifically, step S12 is implemented as follows: After receiving the notification, the host desktop sharing service first allocates a shared memory pool for transmitting screen data, then requests the host to create a virtual screen, and sets up a callback interface to receive screen graphics data.
[0032] like Figure 5 As shown, when the host desktop refreshes, the host synthesis service will synthesize the host desktop graphics data into the virtual screen on the host side. The host desktop graphics data is an image of the entire host desktop in RGBA8888 format.
[0033] Specifically, the OpenHarmony operating system is used to composite desktop graphics data onto the virtual screen. First, a virtual screen is created by calling the OpenHarmony interface. Then, a compositing function is set. When screen data is refreshed, the set compositing function is called to composite the screen data onto the host machine's virtual screen.
[0034] Step S13: Determine the callback interface, obtain multiple timestamps, and write the initial graphic data into the shared memory pool according to the multiple timestamps through the callback interface to obtain multiple shared graphic data.
[0035] Specifically, step S13 is implemented as follows: like Figure 5 As shown, when the host desktop refreshes, a callback interface call to the desktop sharing service is also triggered. The callback interface receives the relevant desktop graphics data and writes it into the shared memory pool, while simultaneously notifying SurfaceFlinger to perform forced compositing. The purpose of notifying forced compositing is to prevent SurfaceFlinger from not performing layer compositing when the Android system is not updating the application.
[0036] Each time the desktop refreshes, the desktop graphics data and the corresponding timestamp are written to the shared memory pool via a callback interface, resulting in multiple shared graphics data sets.
[0037] Step S20: Perform layer construction processing based on multiple shared graphic data to obtain the target layer.
[0038] like Figure 5 As shown, when a VSync or host notification of a forced compositing event occurs, SurfaceFlinger calculates the required layer array LayerSettings.
[0039] like Figure 3 As shown, step S20 specifically includes: Step S21: Obtain the current timestamp, and filter the multiple shared graphic data according to the current timestamp to obtain the peer graphic data.
[0040] Specifically, step S21 is implemented as follows: like Figure 5 As shown, the ScreenManager in SurfaceFlinger selects the host desktop graphics data closest to the timestamp of the previous frame of screen data recorded in the Android application from the shared memory pool.
[0041] Double buffering is a graphics rendering technique. This invention uses a shared memory pool with double buffering to eliminate screen tearing and flickering.
[0042] Specifically, regarding the issue of screen tearing, in single-buffered applications, while the monitor is reading frame data from memory, the graphics processor may be writing the next frame's data to the same memory block. This causes the monitor to see the old frame in the upper half and the new frame in the lower half within a single frame refresh cycle, resulting in a misaligned tearing effect. In contrast, dual-buffered applications always draw in the background buffer, while the monitor always reads data from the foreground buffer and displays it. These two processes physically operate on two different memory blocks, so there is no conflict.
[0043] Regarding screen flickering, in single-buffered mode, the application draws directly in the foreground buffer. During the transition between clearing the old frame and drawing the new frame, the buffer may be in an invalid state, either partially cleared or partially drawn. If the screen refresh reads this intermediate state at this time, it will display a fragmented or chaotic image, resulting in flickering under continuous refresh. In double-buffered mode, however, all drawing operations are completed in a background buffer invisible to the user. Before final submission, the content on the screen (from the foreground buffer) remains absolutely stable. After the swap operation is completed, the entire new screen is presented all at once; the user is unaware of the drawing process and only sees the final complete static or coherent dynamic result.
[0044] Step S22: Perform layer construction processing based on the obtained end graphic data to obtain the target layer.
[0045] Specifically, step S22 is implemented as follows: like Figure 5 As shown, the filtered peer graphics data is used to construct a LayerSettings object (which contains only one Layer corresponding to the host desktop graphics data).
[0046] Further, layer initialization processing is performed based on the aforementioned end-to-end graphic data to obtain an initial layer.
[0047] After the peer's graphics data is sent to the Android application, it is constructed into a GraphicBuffer object, and then a LayerSettings object is constructed through the GraphicBuffer object. SurfaceFlinger also calculates the scaling ratio between the host screen size and the GraphicBuffer size set by the Android application, and configures the scaling ratio and LayerSettings coordinates and other properties into the LayerSettings object variable created earlier.
[0048] Specifically, such as Figure 6As shown, when the data obtained by the Android application is a virtual screen target, a LayerSettings object is created to obtain the host device's screen texture buffer from ScreenCaptureManager. Then, it checks whether the obtained texture buffer is a null pointer (nullptr). If it is, the geometric calculation is skipped; otherwise, the next geometric calculation is performed.
[0049] Further, the host device display attributes and the Android application display attributes are obtained, and a scaling ratio is calculated based on the host device display attributes and the Android application display attributes to obtain a target scaling ratio; the initial layer is scaled and configured according to the target scaling ratio to obtain a first intermediate layer.
[0050] like Figure 6 As shown, the source texture size of the host machine and the target viewport size of the Android application are obtained respectively. The aspect ratio is calculated based on the source texture size of the host machine and the target viewport size of the Android application to obtain the scaling ratio. The scaling transformation is then applied according to the scaling ratio to ensure that the content of the host machine is fully displayed on the Android application and the aspect ratio is maintained.
[0051] Furthermore, the first intermediate layer is centered to obtain the second intermediate layer.
[0052] like Figure 6 As shown, the horizontal and vertical offsets of the content displayed on the screen are calculated to center the content, and the layer boundaries are set to complete the geometric calculations.
[0053] Further, the rendering attribute configuration is obtained, and the second intermediate layer is processed to obtain the target layer.
[0054] like Figure 6 As shown, set the layer properties, and then set rendering properties such as color space, transparency, and texture filtering to obtain the target layer.
[0055] Step S30: Perform cache writing processing based on the target layer to obtain the target graphics cache, and perform screen rendering processing on the Android application based on the target graphics cache to obtain the screen sharing result.
[0056] like Figure 5 As shown, after configuring the LayerSettings object, the original logic of the Android device calls the rendering structure to render LayerSettings onto the GraphicBuffer of the Android application's virtual screen, and then screen sharing is completed based on the rendered virtual screen.
[0057] like Figure 4 As shown, step S30 specifically includes: Step S31: Perform virtual screen creation processing on the Android application according to the screen sharing request to obtain the peer virtual screen.
[0058] Specifically, step S31 is implemented as follows: When an Android application enables screen sharing, it also calls the SurfaceFlinger interface to create a virtual screen.
[0059] Step S32: Perform cache writing processing on the peer virtual screen according to the target layer to obtain the target graphics cache.
[0060] Specifically, step S32 is implemented as follows: like Figure 6 As shown, the created LayerSettings object is rendered onto the GraphicBuffer object of the Android application's virtual screen.
[0061] Step S33: Perform screen rendering processing on the Android application based on the target graphics cache to obtain the screen sharing result.
[0062] Specifically, step S33 is implemented as follows: After the Android application obtains the GraphicBuffer object of the virtual screen, it executes the original logic of the SurfaceFlinger service to share the host desktop with the Android application.
[0063] When Android apps turn off screen sharing, SurfaceFlinger and the host desktop sharing service clean up resources.
[0064] By repeating the above steps, screen sharing between a host machine using the open-source HarmonyOS operating system and Android applications can be achieved. For performance stability, double buffering or multi-buffering can be used to optimize the shared memory pool. For smoothness, timestamps can be used to number data, preventing frame skipping and other issues.
[0065] The technical effects of this invention include: 1. This invention constructs a LayerSettings object using the host machine's graphics data between the host machine and the peer machine. Through this invention, applications using the open-source HarmonyOS operating system can be quickly ported to the new version of the Android system, ensuring compatibility with the latest applications, effectively reusing the development results of the open-source HarmonyOS native applications, and helping developers seamlessly access the vast Android ecosystem.
[0066] 2. When implementing screen sharing, this invention does not make many intrusive modifications to the original application. The ported application has high stability and can achieve a high performance experience when running on hardware platforms that support Android.
[0067] 3. The host machine of this invention is not limited to applications using the open-source HarmonyOS operating system. For example, it can also be an application based on the Linux operating system. Through this invention, Android applications can run stably on the Linux desktop in a multi-window manner, solving the problem of the lack of application ecosystem in the current Linux operating system and becoming the most critical link in the commercialization of related technologies.
[0068] This invention constructs a target layer based on the host machine's desktop graphics data, and builds a graphics cache based on the target layer, sharing the host machine's desktop with Android applications, thus realizing screen sharing between open-source HarmonyOS applications and Android applications.
[0069] Furthermore, such as Figure 7 As shown, based on the above-mentioned screen sharing method between open-source HarmonyOS and Android applications, this invention also provides a screen sharing system between open-source HarmonyOS and Android applications, wherein the screen sharing system between open-source HarmonyOS and Android applications includes: The data sharing module 51 is used to obtain the screen sharing request of the Android application, perform memory allocation processing according to the screen sharing request to obtain a shared memory pool, obtain the desktop graphics data of the host machine, determine the callback interface, and write the desktop graphics data into the shared memory pool through the callback interface to obtain multiple shared graphics data. Layer construction module 52 is used to perform layer construction processing based on multiple shared graphic data to obtain a target layer; The screen rendering module 53 is used to perform cache writing processing based on the target layer to obtain a target graphics cache, and to perform screen rendering processing on the Android application based on the target graphics cache to obtain a screen sharing result.
[0070] Furthermore, such as Figure 8 As shown, based on the above-mentioned screen sharing method and system between open-source HarmonyOS and Android applications, the present invention also provides a terminal, which includes a processor 10, a memory 20 and a display 30. Figure 4 Only some of the terminal components are shown; however, it should be understood that it is not required to implement all of the components shown, and more or fewer components may be implemented instead.
[0071] In some embodiments, the memory 20 may be an internal storage unit of the terminal, such as a hard drive or memory. In other embodiments, the memory 20 may be an external storage device of the terminal, such as a plug-in hard drive, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Further, the memory 20 may include both internal and external storage devices. The memory 20 is used to store application software and various types of data installed on the terminal, such as the program code installed on the terminal. The memory 20 can also be used to temporarily store data that has been output or will be output. In one embodiment, the memory 20 stores a screen sharing program 40 between open-source HarmonyOS and Android applications. This screen sharing program 40 can be executed by the processor 10 to implement the screen sharing method between open-source HarmonyOS and Android applications in this application.
[0072] In some embodiments, the processor 10 may be a central processing unit (CPU), a microprocessor, or other data processing chip, used to run program code stored in the memory 20 or process data, such as executing the screen sharing method between the open-source HarmonyOS and Android applications.
[0073] In some embodiments, the display 30 may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, or an OLED (Organic Light-Emitting Diode) touchscreen. The display 30 is used to display information on the terminal and to display a visual user interface.
[0074] In one embodiment, when the processor 10 executes the screen sharing program 40 between the open-source HarmonyOS and Android applications stored in the memory 20, the following steps are performed: Obtain the screen sharing request from the Android application, perform memory allocation processing based on the screen sharing request to obtain a shared memory pool, obtain the desktop graphics data of the host machine, determine the callback interface, and write the desktop graphics data into the shared memory pool through the callback interface to obtain multiple shared graphics data. The target layer is obtained by performing layer construction processing based on multiple shared graphic data; The target layer is cached and written to obtain a target graphics cache. The Android application is then rendered based on the target graphics cache to obtain a screen sharing result.
[0075] Specifically, the process of obtaining the screen sharing request from the Android application, performing memory allocation based on the screen sharing request to obtain a shared memory pool, obtaining the host device's desktop graphics data, determining the callback interface, and writing the desktop graphics data into the shared memory pool through the callback interface to obtain multiple shared graphics data includes: Obtain the screen sharing request from the Android application, perform memory allocation processing based on the screen sharing request to obtain a shared memory pool, and perform virtual screen creation processing on the host machine based on the screen sharing request to obtain the host machine virtual screen; The desktop graphics data of the host machine is obtained, and the desktop graphics data is combined into the virtual screen of the host machine to obtain the initial graphics data; Determine the callback interface, obtain multiple timestamps, and write the initial graphics data into the shared memory pool according to the multiple timestamps through the callback interface to obtain multiple shared graphics data.
[0076] Specifically, the step of performing layer construction processing based on multiple shared graphic data to obtain the target layer includes: Obtain the current timestamp, and filter multiple shared graphic data based on the current timestamp to obtain the peer graphic data; The target layer is obtained by performing layer construction processing based on the graphics data from the other end.
[0077] Specifically, the step of performing layer construction processing based on the peer graphics data to obtain the target layer includes: The initial layer is obtained by performing layer initialization processing based on the aforementioned end-to-end graphic data; Obtain the screen display attributes, configure the initial layer according to the screen display attributes, and obtain the target layer.
[0078] The step of obtaining screen display attributes and configuring the initial layer according to the screen display attributes to obtain the target layer specifically includes: Obtain screen display attributes, and perform scaling configuration processing on the initial layer according to the screen display attributes to obtain the first intermediate layer; The first intermediate layer is centered to obtain the second intermediate layer; Obtain the rendering attribute configuration, process the rendering configuration of the second intermediate layer, and obtain the target layer.
[0079] The screen display attributes include host machine display attributes and Android application display attributes; The step of obtaining screen display attributes and scaling the initial layer according to the screen display attributes to obtain the first intermediate layer specifically includes: Obtain the host device display attributes and the Android application display attributes, and calculate the scaling ratio based on the host device display attributes and the Android application display attributes to obtain the target scaling ratio; The initial layer is scaled according to the target scaling ratio to obtain the first intermediate layer.
[0080] Specifically, the step of performing cache writing processing based on the target layer to obtain a target graphics cache, and then performing screen rendering processing on the Android application based on the target graphics cache to obtain a screen sharing result, includes: Based on the screen sharing request, the Android application performs virtual screen creation processing to obtain the peer virtual screen; The target graphics cache is obtained by performing cache writing processing on the peer virtual screen according to the target layer; The Android application is rendered based on the target graphics cache to obtain the screen sharing result.
[0081] The present invention also provides a computer-readable storage medium, wherein the computer-readable storage medium stores a screen sharing program between open-source HarmonyOS and Android applications, and when the screen sharing program between open-source HarmonyOS and Android applications is executed by a processor, it implements the steps of the screen sharing method between open-source HarmonyOS and Android applications as described above.
[0082] In summary, this invention provides a screen sharing method, system, and terminal between open-source HarmonyOS and Android applications. The method includes: obtaining a screen sharing request from an Android application; performing memory allocation processing based on the screen sharing request to obtain a shared memory pool; obtaining desktop graphics data from the host machine; determining a callback interface; writing the desktop graphics data into the shared memory pool through the callback interface to obtain multiple shared graphics data; performing layer construction processing based on the multiple shared graphics data to obtain a target layer; performing cache writing processing based on the target layer to obtain a target graphics cache; and performing screen rendering processing on the Android application based on the target graphics cache to obtain a screen sharing result. This invention constructs a target layer based on the host machine's desktop graphics data and constructs a graphics cache based on the target layer, sharing the host machine's desktop to the Android application, thus realizing screen sharing between open-source HarmonyOS applications and Android applications.
[0083] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal. 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 terminal that includes that element.
[0084] Of course, those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware (such as a processor, controller, etc.). The program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The computer-readable storage medium can be a memory, magnetic disk, optical disk, etc.
[0085] It should be understood that the application of the present invention is not limited to the examples above. Those skilled in the art can make improvements or modifications based on the above description, and all such improvements and modifications should fall within the protection scope of the appended claims.
Claims
1. A screen sharing method between open-source HarmonyOS and Android applications, characterized in that, The screen sharing method between open-source HarmonyOS and Android applications includes: Obtain the screen sharing request from the Android application, perform memory allocation processing based on the screen sharing request to obtain a shared memory pool, obtain the desktop graphics data of the host machine, determine the callback interface, and write the desktop graphics data into the shared memory pool through the callback interface to obtain multiple shared graphics data. The target layer is obtained by performing layer construction processing based on multiple shared graphic data; The target layer is cached and written to obtain a target graphics cache. The Android application is then rendered based on the target graphics cache to obtain a screen sharing result.
2. The screen sharing method between open-source HarmonyOS and Android applications according to claim 1, characterized in that, The process of obtaining the screen sharing request from the Android application, performing memory allocation based on the screen sharing request to obtain a shared memory pool, obtaining the host device's desktop graphics data, determining the callback interface, and writing the desktop graphics data into the shared memory pool through the callback interface to obtain multiple shared graphics data, specifically includes: Obtain the screen sharing request from the Android application, perform memory allocation processing based on the screen sharing request to obtain a shared memory pool, and perform virtual screen creation processing on the host machine based on the screen sharing request to obtain the host machine virtual screen; The desktop graphics data of the host machine is obtained, and the desktop graphics data is combined into the virtual screen of the host machine to obtain the initial graphics data; Determine the callback interface, obtain multiple timestamps, and write the initial graphics data into the shared memory pool according to the multiple timestamps through the callback interface to obtain multiple shared graphics data.
3. The screen sharing method between open-source HarmonyOS and Android applications according to claim 1, characterized in that, The step of constructing a layer based on multiple shared graphic data to obtain a target layer specifically includes: Obtain the current timestamp, and filter multiple shared graphic data based on the current timestamp to obtain the peer graphic data; The target layer is obtained by performing layer construction processing based on the graphics data from the other end.
4. The screen sharing method between open-source HarmonyOS and Android applications according to claim 3, characterized in that, The step of performing layer construction processing based on the peer graphics data to obtain the target layer specifically includes: The initial layer is obtained by performing layer initialization processing based on the aforementioned end-to-end graphic data; Obtain the screen display attributes, configure the initial layer according to the screen display attributes, and obtain the target layer.
5. The screen sharing method between open-source HarmonyOS and Android applications according to claim 4, characterized in that, The step of obtaining screen display attributes and configuring the initial layer according to the screen display attributes to obtain the target layer specifically includes: Obtain screen display attributes, and perform scaling configuration processing on the initial layer according to the screen display attributes to obtain the first intermediate layer; The first intermediate layer is centered to obtain the second intermediate layer; Obtain the rendering attribute configuration, process the rendering configuration of the second intermediate layer, and obtain the target layer.
6. The screen sharing method between open-source HarmonyOS and Android applications according to claim 5, characterized in that, The screen display attributes include host machine display attributes and Android application display attributes; The step of obtaining screen display attributes and scaling the initial layer according to the screen display attributes to obtain the first intermediate layer specifically includes: Obtain the host device display attributes and the Android application display attributes, and calculate the scaling ratio based on the host device display attributes and the Android application display attributes to obtain the target scaling ratio; The initial layer is scaled according to the target scaling ratio to obtain the first intermediate layer.
7. The screen sharing method between open-source HarmonyOS and Android applications according to claim 1, characterized in that, The step of performing cache writing processing based on the target layer to obtain a target graphics cache, and then performing screen rendering processing on the Android application based on the target graphics cache to obtain a screen sharing result, specifically includes: Based on the screen sharing request, the Android application performs virtual screen creation processing to obtain the peer virtual screen; The target graphics cache is obtained by performing cache writing processing on the peer virtual screen according to the target layer; The Android application is rendered based on the target graphics cache to obtain the screen sharing result.
8. A screen sharing system between open-source HarmonyOS and Android applications, characterized in that, The screen sharing system between the open-source HarmonyOS and Android applications includes: The data sharing module is used to obtain screen sharing requests from Android applications, perform memory allocation processing based on the screen sharing requests to obtain a shared memory pool, obtain desktop graphics data from the host machine, determine the callback interface, and write the desktop graphics data into the shared memory pool through the callback interface to obtain multiple shared graphics data. The layer construction module is used to perform layer construction processing based on multiple shared graphic data to obtain the target layer; The screen rendering module is used to perform cache writing processing based on the target layer to obtain the target graphics cache, and to perform screen rendering processing on the Android application based on the target graphics cache to obtain the screen sharing result.
9. A terminal, characterized in that, The terminal includes: a memory, a processor, and a screen sharing program between open-source HarmonyOS and Android applications stored on the memory and executable on the processor. When the screen sharing program between open-source HarmonyOS and Android applications is executed by the processor, it implements the steps of the screen sharing method between open-source HarmonyOS and Android applications as described in any one of claims 1-7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a screen sharing program between open-source HarmonyOS and Android applications, which, when executed by a processor, implements the steps of the screen sharing method between open-source HarmonyOS and Android applications as described in any one of claims 1-7.