A method for running a lightweight OpenHarmony system UI framework on an Android system

Abstract

The present invention discloses a method for running a lightweight OpenHarmony system UI framework on an Android system, wherein the ACE core code maintains the native implementation of HarmonyOS unchanged, that is, the native MVVM data hijacking framework, JS language runtime and UI back-end rendering engine framework are not modified, and modifications are made to the final hardware adaptation layer, in which the RGB888 image data after the original image rendering is sent to the screen FrameBuffer, and is instead sent to the NativeWindow corresponding to the Android native SurfaceView component. Based on a small amount of code modification, the HarmonyOS lightweight UI framework is enabled to run on the Android system, which saves the time for redeveloping the UI engine and thus improves development efficiency.

Description

Technical Field

[0001] The present invention relates to the technical field of embedded platform application development, and in particular to a method for running a lightweight OpenHarmony system UI framework on an Android system. Background Art

[0002] OpenHarmony is a full-scenario system designed by Huawei that supports a wide range of devices. To adapt to different hardware, OpenHarmony uses different kernels, such as LiteOS and Linux, and builds different system types based on these kernels. A unified set of system capabilities is formed in these systems. Currently, OpenHarmony mainly includes three system types: L0 (lightweight system), L1 (small system), and L2 (standard system).

[0003] Among them, the UI framework running on the lightweight OpenHarmony system is called ACELite. It uses a web-like development model of JavaScript+CSS+HTML and supports the classic MVVM development model. However, compared with ArkUI, an application development framework on the standard system, ACELite does not natively design its cross-platform UI adaptation capabilities. The application UI developed based on ACELite cannot be directly displayed and interacted on the Android system.

[0004] In contrast, the current mainstream cross-platform mobile application UI framework solutions are mainly divided into two categories:

[0005] 1) Based on the web technology stack, leveraging the cross-platform nature of the web to adapt applications to different platforms, using the target platform's WebKit and WebView browser environment to achieve cross-platform UI operation. However, this solution suffers from inconsistent development experience and operational results, and may cause performance issues during application operation. It is also not compatible with ACE_Lite, a terminal UI development framework that does not fully comply with web standards.

[0006] 2) There are two main types of native rendering frameworks based on the target platform. One is the Flutter solution that uses its own rendering engine to implement UI rendering on different target platforms, and the other is React- Solutions that implement an independent bridging layer to connect UI components to UI frameworks on different platforms offer significant performance and compatibility advantages over solutions using a web technology stack. However, Flutter and React-Native frameworks are not compatible with ACELite because Flutter uses its own Dart language, and React-Native's bridge mechanism is not compatible with rendering frameworks like ACE_Lite, which use direct UI component connections. Summary of the Invention

[0007] To solve the above problems, the purpose of the present invention is to propose a method for running a lightweight OpenHarmony system UI framework on the Android system, so as to realize the adaptation of the lightweight Hongmeng UI framework on the Android platform without changing the core source code structure, and realize the one-time development and multi-platform deployment of lightweight OpenHarmony applications.

[0008] In order to achieve the above technical objectives, the technical solution adopted by the present invention is:

[0009] A method for running a lightweight OpenHarmony system UI framework on an Android system, keeping the ACE core code unchanged from the native Hongmeng implementation, that is, the native MVVM data hijacking framework, JS language runtime, and UI backend rendering engine framework are all unchanged. Modifications are made to the final hardware adaptation layer, and the original RGB888 image data after image rendering is sent to the screen FrameBuffer is changed to be sent to the NativeWindow corresponding to the Android native SurfaceView component.

[0010] As a possible implementation, further, the method of running the lightweight OpenHarmony system UI framework on the Android system includes:

[0011] 1) UI rendering framework adaptation: Adapting the application's UI drawing is achieved by linking to the Android system's native UIView;

[0012] 2) IMS input framework adaptation: The adaptation of IMS on the Android system is achieved by associating it with the InputDeviceManager of the Android system.

[0013] As a possible implementation, further, the UI drawing adaptation of the application is achieved by associating with the native UIView of the Android system. The specific steps are as follows:

[0014] 1.1): Create a LiteSurfaceView object in the Java layer that inherits from the Android native SurfaceView type; the layout of the LiteSurfaceView occupies the entire application page, and the SurfaceView is abstracted as the upper screen window after the ACELite framework draws a frame of image, that is, ACELite uses the SurfaceView as the target screen for the final image output;

[0015] 1.2): The SurfaceView object is passed to the native layer through the Android system's jni mechanism, and converted into a NativeWindow local window object through the Android system's ANativeWindow_fromSurface method; this step converts the Java layer's SurfaceView object into a native layer window and obtains its image cache buffer;

[0016] 1.3): Use the NativeWindow size obtained in step 1.2) as the UI screen size. After the OpenHarmony native UI framework completes drawing a frame of image, it calls the modified Flush method in DisplayDevice. The modified Flush method associates the video memory of the single-frame page with the NativeWindow window object in step 1.2) through the ANativeWindow_lock method. Finally, the incoming RGB888 image is refreshed to the NativeWindow buffer cache through the ANativeWindow_unlockAndPost method, so that it is displayed on the device screen.

[0017] As a possible implementation method, further adaptation of IMS on the Android system is achieved by associating it with the InputDeviceManager of the Android system. The specific steps are as follows:

[0018] 2.1) In the LiteActivity class at the Java layer, declare the onTouchEvent method to obtain the corresponding user touch screen event MotionEvent. When the device user taps or slides on the Android device screen, the program directly obtains the X and Y coordinates of the original touch screen point through the getX() and getY() methods of the MotionEvent object.

[0019] 2.2): Based on the user click coordinates in step 2.1), the rawdata event required by IMS (i.e., the user click location) is constructed. The IMS service obtains the user input event by querying the background for the existence of rawdata and notifies the UI to update.

[0020] 2.3): For the onBack / onMenu / onHome event callbacks of the system function keys, the event is passed to the IMS framework for processing by constructing rawdata in the same way.

[0021] By adopting the above technical solution, the present invention has the following beneficial effects compared with the prior art:

[0022] 1) Aiming at the cross-platform adaptation of the ACELite framework, the present invention fully considers the design features of its lightweight UI library and core framework sinking, and proposes a fast UI adaptation solution on the Android system platform without changing the core source code structure, thereby realizing the adaptation of the lightweight Hongmeng UI framework on the Android platform and achieving one-time development and multi-platform deployment of lightweight OpenHarmony applications.

[0023] 2) This invention solves the UI framework adaptation problem on Android by associating it with the Android system's SurfaceView. Compared to other solutions such as React-Native's bridging solution and Flutter's self-rendering solution, the method of this invention quickly solves the UI adaptation problem. Compared with the React-Native bridging solution, this invention ensures the consistency of the display effect, and compared with Flutter's self-rendering solution, this invention saves the time of redeveloping the UI engine, thereby improving development efficiency.

[0024] In the UI framework adaptation solution, by making modifications to the UI image on-screen link, the image data drawn by the ACE framework is associated with the SurfaceView object of the Android system for display, thus realizing the UI framework adaptation solution for running lightweight HarmonyOS applications on the Android system; this innovation ensures the consistency of display effects, while avoiding the work of redeveloping the UI engine and improving development efficiency.

[0025] The IMS input framework adaptation solution is implemented using the Android-based InputDeviceManager. Touchscreen events are captured in the Java layer through MotionEvent and corresponding rawdata events are constructed for the UI framework. This innovation ensures consistency between the user input experience on Android and HarmonyOS, improving app operability. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0027] Figure 1 Adapt the diagram to the UI framework. DETAILED DESCRIPTION

[0028] The present invention will be described in further detail below with reference to the accompanying drawings and examples. It is particularly noted that the following examples are intended only to illustrate the present invention and are not intended to limit the scope of the present invention. Similarly, the following examples are only some embodiments of the present invention and are not intended to be exhaustive. All other embodiments obtained by those of ordinary skill in the art without creative effort are intended to fall within the scope of protection of the present invention.

[0029] The overall design diagram of the UI framework adaptation solution (see attached) Figure 1 As shown in the figure, it can be mainly divided into the ACE Framework layer and the ACE Engine layer. The ACE Framework layer provides the core JS runtime frame, and the ACE Engine layer provides the graphics drawing engine function responsible for the final image display on the screen.

[0030] The design of this invention keeps the ACE core code and the native implementation of Hongmeng unchanged, that is, the native MVVM data hijacking framework, JS language runtime, and UI backend rendering engine framework are not modified. The final hardware adaptation layer is modified to send the RGB888 image data after the image rendering is completed to the screen FrameBuffer instead of sending it to the NativeWindows corresponding to the Android native SurfaceView component. Based on a small amount of code modification, the Hongmeng lightweight UI framework can be run on the Android system. The specific implementation can be divided into two parts:

[0031] 1) UI rendering framework adaptation:

[0032] For the application UI drawing adaptation, it is achieved by linking to the native UIView of the Android system. The specific steps are as follows:

[0033] 1.1): Create a LiteSurfaceView object in the Java layer that inherits from the Android native SurfaceView type. The layout of this LiteSurfaceView occupies the entire application page. This design abstracts SurfaceView as the upper screen window after the ACELite framework draws a frame of image. In other words, ACELite uses this SurfaceView as the target screen for the final image output;

[0034] 1.2): Pass the SurfaceView object to the native layer through the Android system's jni mechanism, and convert it into a NativeWindow local window object through the Android system's ANativeWindow_fromSurface method. This step converts the Java layer's SurfaceView object into a native layer window and obtains its image cache buffer;

[0035] 1.3): Use the NativeWindow size obtained in step 1.2) as the UI screen size. After the OpenHarmony native UI framework completes drawing a frame of image, it calls the modified Flush method in DisplayDevice. The modified Flush method associates the video memory of the single-frame page with the NativeWindow window object in step 1.2) through the ANativeWindow_lock method. Finally, the passed RGB888 image is refreshed to the NativeWindow buffer cache through the ANativeWindow unlockAndPost method, so that it is displayed on the device screen.

[0036] In the prior art, after the OpenHarmony native UI framework completes drawing a frame, it calls the Flush method in DisplayDevice to refresh the RGB888 image data of the single-frame page to the hardware screen's buffer cache. The present invention modifies the Flush method in DisplayDevice, associates the single-frame page's video memory with the NativeWindow window object in step 1.2) via the ANativeWindow_lock method, and finally flushes the incoming RGB888 image to the NativeWindow buffer cache via the ANativeWindow_unlockAndPost method, allowing it to be displayed on the device screen.

[0037] Through the above design, ACELite's UI drawing is associated with the Android system's SurfaceView object, so that images can be displayed on Android devices without changing the ACELite core framework code. And because Android's native UI components are used, the Android system's native window management service can be reused in UI window management to implement window scheduling.

[0038] 2) IMS input framework adaptation:

[0039] The service used to handle user input events in the ACELite framework is called the IMS service (Input ManagerService). It is responsible for polling and listening to customer click events on the screen in the system background and notifying the corresponding UI to update. To adapt IMS to the Android system, it is designed to be associated with the Android system's inputDeviceManager to achieve this. The specific steps are as follows:

[0040] 2.1) In the Java-level LiteActivity class, declare the onTouchEvent method to retrieve the corresponding MotionEvent. When the user taps or slides on the Android device's screen, the program uses the getX() and getY() methods of the MotionEvent object to directly retrieve the X and Y coordinates of the original touchscreen point.

[0041] 2.2) Based on the user click coordinates from step 2.1), the rawdata event required by IMS (i.e., the user click location) is constructed. The IMS service obtains the user input event by querying the background for the existence of rawdata and notifies the UI to update.

[0042] 2.3) For the onBack / onMenu / onHome event callbacks of the system function keys, the event is passed to the IMS framework for processing by constructing rawdata in the same way.

[0043] Based on a deep understanding of the ACE_Lite framework and the Android system design, the present invention proposes an adaptation scheme for the ACELiteUI framework on the Android platform, which mainly achieves the following design goals: to ensure that the page logic and UI controls of the application running on the Android system are completely consistent with those running on the lightweight OpenHarmony system, and to ensure the execution performance of the UI. Compared with the react-native solution, the UI framework adaptation scheme proposed in the present invention avoids docking UI components through a bridge layer through an innovative design, and instead completely reuses the native UI framework code of ACE_Lite to ensure the consistency of the UI effect. Under the premise of ensuring UI performance, there is no need to rewrite the UI rendering engine of the target platform like the Flutter solution. This design not only avoids a lot of workload, but also can keep synchronized iterations with the community version, providing convenience for subsequent maintenance work.

[0044] The above descriptions are only some embodiments of the present invention and do not limit the scope of protection of the present invention. Any equivalent device or equivalent process transformation made by using the contents of the description and drawings of the present invention, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present invention.

Claims

1. A method for running a lightweight OpenHarmony system UI framework on an Android system, characterized by maintaining the ACE core code unchanged from the native Hongmeng implementation, that is, the native MVVM data hijacking framework, JS language runtime, and UI backend rendering engine framework are all unchanged. A modification is made to the final hardware adaptation layer, where the RGB888 image data after image rendering is sent to the screen FrameBuffer instead of being sent to the NativeWindow corresponding to the Android native SurfaceView component; The method comprises: 1) UI rendering framework adaptation: Adapting the application's UI drawing is achieved by linking to the Android system's native SurfaceView; 2) IMS input framework adaptation: Adapting IMS on the Android system is achieved by associating it with the Android system's InputDeviceManager; For the application UI drawing adaptation, it is achieved by linking to the native SurfaceView of the Android system. The specific steps are as follows: 1.1): Create a LiteSurfaceView object in the Java layer that inherits from the Android native SurfaceView type; the layout of the LiteSurfaceView occupies the entire application page, and the SurfaceView is abstracted as the upper screen window after the ACELite framework draws a frame of image, that is, ACELite uses the SurfaceView as the target screen for the final image output; 1.2): Pass the SurfaceView object to the navie layer through the Android system's jni mechanism, and convert it into a NativeWindow local window object through the Android system's ANativeWindow_fromSurface method; this step converts the SurfaceView object of the Java layer into a window of the native layer and obtains its image cache buffer; 1.3): Use the NativeWindow size obtained in step 1.2) as the UI screen size. After the OpenHarmony native UI framework completes drawing a frame of image, it calls the modified Flush method in DisplayDevice. The modified Flush method associates the video memory of the single-frame page with the NativeWindow window object in step 1.2) through the ANativeWindow_lock method. Finally, the incoming RGB888 image is refreshed to the NativeWindow buffer cache through the ANativeWindow_unlockAndPost method, so that it is displayed on the device screen. To adapt IMS to the Android system, you can associate it with the InputDeviceManager of the Android system. The specific steps are as follows: 2.1): In the LiteActivity class of the Java layer, declare the onTouchEvent method to obtain the corresponding user touch screen event MotionEvent; when the device user taps or slides on the screen of the Android device, the program directly obtains the X and Y coordinates of the original touch screen point through the getX() and getY() methods of the MotionEvent object; 2.2): Based on the user click coordinates in step 2.1), the rawdata event required by IMS is constructed. The IMS service obtains the user input event by querying whether rawdata exists in the background and notifies the UI to update; 2.3): For the onBack / onMenu / onHome event callback of the system function keys, the event is passed to the IMS framework for processing by constructing rawdata in the same way.

Images