A heterogeneous closed-source driver compatible running method based on dynamic symbol redirection

Abstract

The application discloses a heterogeneous closed-source driver compatible running method based on dynamic symbol redirection, modifies and adapts source code of a layer to adapt to a Harmony system, builds a dynamic symbol redirection engine to establish a mapping table, and compiles to generate a dynamic library; an Android hardware abstraction layer container process is created by the system, and a system sandbox is configured, an Android running directory structure is simulated to complete mapping, the dynamic library is loaded, and the dynamic symbol redirection engine is started; the system loads heterogeneous closed-source drivers to the sandbox, completes symbol preprocessing according to a dependent function type, builds a rendering resource pool, and completes hardware-level GPU context creation; device registration and service binding are completed by the driver registering hardware information, the layer responds according to the function type, cross-platform Binder communication is completed through a virtual Binder driver and an agent process to call a Harmony system service, frame buffer data is pushed to a display controller after rendering is completed by the driver, and the compatible running of the Android heterogeneous closed-source driver in the Harmony environment is realized.

Description

Technical Field

[0001] This invention belongs to the field of computer software development technology, specifically relating to a method for compatible operation of heterogeneous closed-source drivers based on dynamic symbol redirection. Background Technology

[0002] As a core tool for reusing Android HAL components in traditional Linux systems, libhybris's design heavily relies on Linux ecosystem features, such as the glibc library, Wayland or X11 graphics stack, and Android native driver loading logic. Directly migrating it to the OpenHarmony system requires addressing multiple underlying compatibility issues. Existing technical solutions mainly suffer from the following problems:

[0003] First, the source code-level dependencies of libhybris cause serious conflicts. The native libhybris code makes a large number of calls to glibc-specific functions (such as gnu_get_libc_version for obtaining the libc version and dladdr1 for symbol address resolution), Linux-specific system calls (such as timerfd_create for timer creation), and Wayland graphics interfaces (such as wl_display_connect for display connections). However, OpenHarmony uses the musl C library, its self-developed RenderService graphics framework, and the HDF (Hardware Driver Framework) driver framework, which makes the libhybris source code unable to be compiled directly, and even results in compilation errors such as undefined functions and symbol conflicts.

[0004] Secondly, the symbol adaptation logic is rigid and lacks sufficient coverage. The original symbol mapping mechanism of libhybris relies on a manually maintained static configuration table (such as bionic_symbols.h), which can only adapt to functions with fixed behavior (such as strlen) and cannot cope with the dynamic function behavior differences of Android HAL components in OpenHarmony. For example, the camera HAL of Android 10 requires 16 bytes of memory alignment for malloc, while the video HAL of Android 13 requires 32 bytes of alignment for malloc. The static table cannot adjust the adaptation logic in real time, causing some HAL components to crash due to memory access errors.

[0005] Third, the graphics modules are redundant and the interfaces are incompatible. The Wayland or X11 adapter modules built into libhybris (such as libhybris-wayland.so) are completely useless in OpenHarmony, and instead increase the compilation size and runtime memory usage. At the same time, its EGL (Embedded-System Graphics Library) interface (such as eglGetDisplay) calls the Linux display driver interface by default, which cannot be connected to OpenHarmony's HDF GPU driver, causing the Android graphics HAL (such as the GPU rendering driver) to be unable to output rendering results to the OpenHarmony window.

[0006] Fourth, the driver loading logic is incompatible with the HDF framework. libhybris searches for the Android HAL library through fixed paths (such as / vendor / lib, / system / lib) and depends on the Android native device node naming rules (such as / dev / video0 corresponding to the camera), while OpenHarmony's HDF driver library is located in the / system / lib / hdf path, and the device node is named / dev / hdf / <device_type> / <device_id> (e.g., / dev / hdf / camera / 0), causing libhybris to be unable to find and load the hardware driver managed by HDF;

[0007] Fifth, it lacks runtime monitoring and fault self-healing capabilities. The existing solution does not consider the resource contention issues of multiple rendering tasks (such as game 3D rendering, video decoding, and camera preview) within a single device of OpenHarmony, nor does it provide an adaptation effect monitoring mechanism. When problems such as GPU context contention and insufficient frame buffer occur, it cannot dynamically adjust the resource allocation strategy, resulting in rendering stuttering or even system crashes.

[0008] Therefore, it is urgent to establish dynamic adaptation logic and runtime guarantee mechanism for the migration of libhybris to OpenHarmony, so as to ensure that libhybris is upgraded from compatible operation to deep integration into the OpenHarmony architecture, and realize the efficient and stable reuse of Android HAL components. Summary of the Invention

[0009] In view of this, the present invention provides a method for compatible operation of heterogeneous closed-source drivers based on dynamic symbol redirection. By modifying the libhybris source code and the dynamic symbol redirection mechanism, the invention achieves the porting of libhybris to the HarmonyOS system and the efficient reuse of closed-source drivers of Android Hardware Abstraction Layer (HAL).

[0010] This invention provides a method for compatible operation of heterogeneous closed-source drivers based on dynamic symbol redirection, which specifically includes the following steps:

[0011] Modify the adaptation layer source code to make it compatible with HarmonyOS, refactor the build script, build a dynamic symbol redirection engine, establish a service mapping table between Android and HarmonyOS, a permission mapping table between Android permissions and HarmonyOS capabilities, and an interface adaptation table between the adaptation layer interface and HarmonyOS interface; compile the adaptation layer to generate the first core dynamic library.

[0012] HarmonyOS creates an Android hardware abstraction layer container process, configures an independent file system sandbox for it (referred to as the first sandbox), and creates a directory structure in the general way of Android system; maps the HarmonyOS hardware driver library to the first sandbox, mounts the system hardware to the first sandbox, reserves memory for rendering resources; loads the first core dynamic library, starts the dynamic symbol redirection engine, and loads the function behavior feature library, interface adaptation table, service mapping table and permission mapping table.

[0013] HarmonyOS loads heterogeneous, closed-source drivers into the first sandbox. The driver triggers the dynamic symbol redirection engine to retrieve functions from the function behavior feature library. If the function is statically compatible, it returns the address of the HarmonyOS standard library function; if it is dynamically mutated or proprietary, it records the function information and returns a placeholder. HarmonyOS builds a rendering resource pool, encapsulates the display device handle and display parameters into a standard display object, and returns it to the driver. The driver creates a hardware-level GPU context. The driver registers hardware information with HarmonyOS to complete device registration and marks it as ready. Through the adaptation layer, it associates and binds with HarmonyOS services according to the service mapping table and enters the running state.

[0014] When the driver calls a dependent function, the adaptation layer performs native mapping, dynamic adaptation logic injection, or dedicated simulation replication adaptation according to the function type. After the driver initiates a Binder communication request, the virtual Binder driver and the Binder proxy process complete the cross-platform conversion of service ID, method identifier, and parameter format according to the service mapping table, call the HarmonyOS target service, and return the processing result. After the driver completes single-frame rendering, the adaptation layer retrieves the frame buffer data from the rendering resource pool and pushes it to the system display controller to complete the screen output.

[0015] Furthermore, the method for establishing the permission mapping table between Android permissions and HarmonyOS system capabilities is as follows:

[0016] Determine all native permissions required for driver operation, including hardware access, graphics rendering, inter-process communication, and low-level device operation. Based on the scope of Android permission control, calling scenarios, and usage purposes, match system capability identifiers with completely consistent functions and control boundaries in the HarmonyOS system. For Android permissions that do not have matching system capabilities, combine multiple HarmonyOS system capabilities to achieve equivalent substitution. The correspondence between Android permission identifiers and HarmonyOS system capability IDs constitutes a permission mapping table.

[0017] Furthermore, graphics modules unrelated to the HarmonyOS system are trimmed, specifically:

[0018] The adaptation code for graphics modules related to the desktop graphics system in the adaptation layer has been trimmed, and the corresponding header file dependencies have been removed. The display type of the graphics module has been associated with the GPU device handle of the HarmonyOS hardware driver framework, enabling the graphics module to directly access the GPU hardware. The window type of the graphics module has been associated with the HarmonyOS window object. The calls to the system display driver in the graphics module have been replaced with calls to the HarmonyOS hardware driver framework and graphics window interface. The graphics context creation interface has been modified to create a hardware-level graphics context through the HarmonyOS GPU-related interface. The frame buffer exchange interface has been modified to directly submit the rendered frame data to the HarmonyOS display controller.

[0019] Furthermore, during the driver registration phase, when the driver has preset permissions, the adaptation layer triggers capability permission verification to check the system capabilities allocated to the first sandbox container process. If the verification passes, the driver is allowed to enter the running state; if the permissions are insufficient, the driver is intercepted and prohibited from running. Among these, hardware functional capabilities refer to the hardware control services, graphics processing capabilities, and hardware operation interface range provided by the driver.

[0020] Furthermore, the dynamic adaptation logic injection method is as follows: dynamically generate adaptation logic, compile and inject it into the driver process and correct the program link table entries, and complete real-time symbol redirection. The adaptation logic is a process used to perform parameter conversion, process correction, behavior consistency adaptation and result translation between the driver and HarmonyOS native functions to shield the differences in interface implementation between platforms.

[0021] Furthermore, the exclusive simulation replication and adaptation method is as follows: the interface behavior is completely restored by independently customized simulation logic to achieve cross-platform functional compatibility. The independent simulation logic is the processing process of completely simulating the function and behavior of the original interface by maintaining private state, data structure and calculation logic.

[0022] Furthermore, when the driver executes timer and event management low-level operations, the adaptation layer intercepts incompatible system calls, extracts parameter features, corrects them, and then forwards them to the system kernel; for the missing calling capabilities of the HarmonyOS system, equivalent logic simulation processing is performed by combining existing system interfaces.

[0023] Furthermore, the allocation method of the rendering resource pool is as follows: when the driver requests rendering resources, it inputs the resource type and the current task priority. The HarmonyOS system allocates resources according to the priority. When the current task priority is greater than the threshold, it prioritizes acquiring idle resources. When resources are insufficient, it preempts the unlocked resources of tasks with lower priorities than the current task. When resources are exhausted, tasks with priorities less than the threshold enter the waiting queue and are blocked and suspended until tasks with priorities greater than the threshold release resources and are awakened for execution. The recycling method is as follows: a dual recycling mechanism of reference counting and least recently used is adopted. When the driver releases resources, the corresponding reference count is decremented. When the count reaches zero, it is marked as idle. The system periodically scans the rendering resource pool globally. When the utilization rate is less than the threshold or the idle time of idle resources is greater than the threshold, redundant memory is reclaimed.

[0024] Furthermore, when the Binder proxy process queries the Android permissions required by the target service, it triggers a permission check to see if the sandbox container process has obtained the corresponding HarmonyOS system capability. If it has, it directly returns that the verification passed; if it has not, it initiates a permission request to the user, sets an effective period after authorization, and automatically revoks the permission after the timeout. Subsequent calls will require a new request.

[0025] Furthermore, a hot-plug event listener is established in the adaptation layer, and the listener is registered to obtain hardware hot-plug events of the HarmonyOS hardware driver framework in real time. A callback function is registered with the device change callback mechanism. The callback function receives the event type and core device information passed by the HarmonyOS hardware driver framework. The event types include device addition and device removal.

[0026] When a hardware device is connected, a hot-plug event is triggered, sending a device addition notification to the sandbox container process. The process queries the device information of the new device, including the driver library path, device node, and hardware identifier. It establishes a path mapping between the Android hardware library and the HarmonyOS hardware driver framework's driver library, mapping the device node of the HarmonyOS hardware driver framework to a node name compatible with the Android Hardware Abstraction Layer (HAL), and binding the path to complete the adaptation. The driver library name requested by the driver is redirected to the corresponding driver library path in the HarmonyOS hardware driver framework, obtaining the library handle. The dynamic dependencies of the driver library are checked; if the dependent HarmonyOS library is not loaded, it is loaded. The entry function of the Android Hardware Abstraction Layer is obtained, completing the driver registration in the adaptation layer and the HarmonyOS hardware driver framework, establishing the association between the driver and the hardware device.

[0027] When a hardware device is removed, the hot-plug listener captures the device removal event, sends a device removal notification to the sandbox container process, triggers the HarmonyOS hardware driver framework to close the device handle, and releases driver library resources.

[0028] Beneficial effects:

[0029] This invention modifies and compiles the libhybris source code to generate the core dynamic library of the adaptation layer, initializes the function feature library, interface adaptation table, service mapping table, and permission mapping table, and configures the rendering resource scheduling template. The HarmonyOS system creates an isolated first sandbox through the sandbox manager, simulating the Android directory environment, binding the hardware driver path and device information directory, reserving rendering memory, loading the core library and various mapping tables, and starting the dynamic symbol redirection engine. Heterogeneous closed-source drivers are loaded in the sandbox container process, completing the classification and identification of three types of dependency functions—statically compatible, dynamically mutated, and dedicated simulation types—and symbol preprocessing. Simultaneously, the graphics module is initialized, and multi-partition rendering is constructed. The resource pool completes GPU device enumeration and hardware context creation; the driver sequentially completes hardware device registration, HarmonyOS system service association binding, and container process permission compliance verification to complete registration and enter the running state; during operation, the adaptation layer achieves cross-platform compatibility adaptation of different types of functions based on symbol redirection, completes bidirectional protocol conversion, parameter adaptation, and data exchange between Android Binder communication and HarmonyOS services through the virtual Binder driver and Binder proxy process, and completes frame buffer scheduling using the rendering resource pool to submit the rendering frame data to the system display controller, ultimately achieving stable and compatible operation of Android closed-source hardware drivers in the HarmonyOS environment. Attached Figure Description

[0030] Figure 1 This is a flowchart illustrating a heterogeneous closed-source driver compatibility operation method based on dynamic symbol redirection provided by the present invention. Detailed Implementation

[0031] The present invention will be described in detail below with reference to the accompanying drawings and embodiments.

[0032] This invention provides a method for compatible operation of heterogeneous closed-source drivers based on dynamic symbol redirection. The core idea is as follows: Based on the libhybris source code, modify and compile to generate the core dynamic library of the adaptation layer; initialize the function feature library, interface adaptation table, service mapping table, and permission mapping table; configure the rendering resource scheduling template; the HarmonyOS system creates an isolated first sandbox through the sandbox manager, simulating the Android directory environment, binding the hardware driver path and device information directory, reserving rendering memory, loading the core library and various mapping tables, and starting the dynamic symbol redirection engine; load the heterogeneous closed-source driver in the sandbox container process, and complete the classification and identification of three types of dependent functions—statically compatible, dynamically mutated, and dedicated simulation types—and symbol preprocessing. The process involves synchronously initializing the graphics module, building a multi-partition rendering resource pool, and completing GPU device enumeration and hardware context creation. The driver sequentially completes hardware device registration, HarmonyOS system service association binding, and container process permission compliance verification to complete registration and enter the running state. During operation, the adaptation layer achieves cross-platform compatibility adaptation of different types of functions based on symbol redirection. It completes bidirectional protocol conversion, parameter adaptation, and data exchange between Android Binder communication and HarmonyOS services through the virtual Binder driver and Binder proxy process. The rendering resource pool is used to complete frame buffer scheduling and submit the rendering frame data to the system display controller. Ultimately, this achieves stable and compatible operation of Android closed-source hardware drivers in the HarmonyOS environment.

[0033] This invention provides a method for heterogeneous closed-source driver compatibility based on dynamic symbol redirection, the processing flow of which is as follows: Figure 1 As shown, the specific steps include:

[0034] Step 1: Analyze and modify the libhybris source code of the adaptation layer, replacing library interfaces and system calls incompatible with HarmonyOS, and trimming graphics modules unrelated to HarmonyOS; refactor the build script to adapt to the HarmonyOS compilation toolchain, dependent libraries, and compilation options, enabling position-independent code compilation and supporting dynamic loading; add a dynamic symbol redirection module to implement the dynamic symbol redirection engine, and build related interfaces such as engine initialization, function classification, resource pool initialization, and resource allocation; establish a rendering resource scheduling parameter template, which includes parameters such as frame buffer specifications, supported image data formats, graphics context priority, and resource idle reclamation threshold; establish and maintain a service mapping table between Android services and HarmonyOS SAMGR services, supporting subsequent dynamic updates; establish a permission mapping table between Android permissions and HarmonyOS capabilities, and record the mapping relationship between the adaptation layer interfaces and HarmonyOS interfaces as an interface adaptation table; compile the modified adaptation layer to generate the first core dynamic library.

[0035] The method for establishing the permission mapping table between Android permissions and HarmonyOS system capabilities is as follows:

[0036] All native permissions required for the operation of heterogeneous closed-source drivers are determined, including permissions for hardware access, graphics rendering, inter-process communication, and low-level device operation. Based on the scope of Android permission control, calling scenarios, and usage purposes, system capability identifiers with completely consistent functions and control boundaries are matched in the HarmonyOS system. For Android permissions that do not have matching system capabilities, multiple HarmonyOS system capabilities are combined to achieve equivalent substitution. The correspondence between Android permission identifiers and HarmonyOS system capability IDs constitutes a permission mapping table.

[0037] Furthermore, the graphics module (OpenGLESEGL) of the adaptation layer is modified for the platform, removing graphics modules unrelated to the HarmonyOS system, removing irrelevant platform dependencies, and connecting to the underlying graphics interface of the HarmonyOS system. Specifically:

[0038] Cut out the graphics module adaptation code related to the existing desktop graphics system in the adaptation layer, remove the corresponding header file dependencies, and simplify redundant code;

[0039] Modify the relevant definitions of the graphics module platform and redefine the native type of the graphics module to bind it to the HarmonyOS graphics object. This includes: associating the display type of the graphics module with the GPU device handle of the HarmonyOS hardware driver framework so that the graphics module can directly access the GPU hardware; and associating the window type of the graphics module with the HarmonyOS window object to ensure that the rendering results can be output to the system window normally.

[0040] The core interfaces of the graphics module have been rewritten, replacing the original calls to the traditional system display driver with calls to the HarmonyOS hardware driver framework and graphics window interfaces. This includes: rewriting the display acquisition interface to open the GPU device and return the corresponding display handle through the HarmonyOS hardware driver framework; rewriting the graphics context creation interface to create a hardware-level graphics context through the HarmonyOS GPU-related interfaces; and rewriting the frame buffer exchange interface to directly submit rendered frame data to the HarmonyOS display controller.

[0041] Step 2: HarmonyOS uses a sandbox manager to create an Android Hardware Abstraction Layer container process and configures an independent file system sandbox as a hardware driver sandbox, designated as the first sandbox. The root directory of the first sandbox is the memory file system, and a directory structure is created in the root directory using the common Android system method to simulate the Android system's runtime environment. Through directory binding, the path where the HarmonyOS hardware driver library is located is mapped to the driver loading path within the first sandbox, meeting the driver loading path adaptation requirements. The system hardware information directory is mounted to the corresponding location in the first sandbox in read-only mode, ensuring that components within the first sandbox can correctly read the device's underlying information. A set amount of memory is reserved by the HarmonyOS rendering resource management module as reserved memory for rendering resources. The first core dynamic library is loaded into this driver loading path, the dynamic symbol redirection engine is started, and the function behavior feature library describing the Android Bionic function behavior characteristics and the interface adaptation table are loaded, along with the service mapping table and permission mapping table.

[0042] Step 3: HarmonyOS loads the heterogeneous closed-source driver, i.e., the Android Hardware Abstraction Layer driver, into the first sandbox container process through the adaptation layer. The heterogeneous closed-source driver initiates a request to obtain the address of the dependent function through the dynamic symbol lookup interface, triggering the dynamic symbol redirection engine to search the function behavior feature library according to the function name in the request, and obtain the basic attributes, calling conventions, compatibility tags and function types of the function. The function types include statically compatible, dynamically mutated and dedicated emulation types. If it is a statically compatible type, the address of the corresponding function in the HarmonyOS standard library is returned to the driver. If it is a dynamically mutated or dedicated emulation type, the function information is recorded and the placeholder or proxy address is returned to the driver, completing the generation and storage of function classification information and writing it into the memory dynamic symbol table.

[0043] The graphics module of the adaptation layer is initialized, and resources are requested from the HarmonyOS rendering resource management module. The HarmonyOS system uniformly allocates and constructs a rendering resource pool containing three functional partitions: a frame buffer pool, a GPU context pool, and a synchronization signal area. The driver obtains the default display device, and the HarmonyOS hardware driver framework opens the GPU device to obtain the device handle and display parameters, encapsulates them into a standard display object, and returns it to the driver. The driver creates a hardware-level GPU context and obtains the context handle to get the context object.

[0044] Specifically, dynamically mutated functions refer to interfaces that maintain consistent basic functionality across platforms, but exhibit platform-specific differences in parameter formats, execution flows, return rules, or resource management behaviors. These functions cannot be directly mapped and called natively; instead, the adaptation layer dynamically generates adaptation logic and injects it into the process. Real-time symbol redirection is used to complete behavior patching and cross-platform compatibility adaptation. The adaptation logic is used to perform parameter conversion, flow correction, behavior consistency adaptation, and result translation between the driver and HarmonyOS native functions to mask the differences in interface implementation between platforms.

[0045] Dedicated simulation functions refer to interfaces unique to the Android system, for which there are no equivalent native functions available in the HarmonyOS system. These functions use independent simulation logic to simulate and reproduce the functionality and behavior of the native interface. Specifically, the independent simulation logic maintains private states, data structures, and computational logic to completely simulate the functionality and behavior of the original interface.

[0046] The frame buffer pool consists of buffers of a specified specification that support various common pixel formats. Each buffer is assigned a unique identifier and its usage status, assigned task information, and idle duration are recorded. The GPU context pool consists of multiple independent GPU contexts, configured with different priorities and optimization levels according to task requirements, to adapt to high-load rendering and regular rendering scenarios respectively. The synchronization signal area is a shared memory used to store resource occupancy status flags. Multi-threaded synchronization is achieved through atomic operations to avoid exceptions caused by resource contention.

[0047] Step 4: The heterogeneous closed-source driver enters the registration phase, registering its hardware identifier, hardware capabilities, and device instance information with the HarmonyOS hardware management framework. This completes the hardware device registration and identifies the device as ready for use. It also configures the hardware operating mode, binds the underlying control handle, and initializes the basic cache and synchronization components. The driver initiates a service registration request through the adaptation layer. The adaptation layer converts the target service name in the request into the HarmonyOS SAMGR service ID based on the service mapping table, thus associating the driver with the system service. If the driver has preset permissions, the adaptation layer triggers capability permission verification, checking the system capabilities allocated to the first sandbox container process. If the verification passes, the driver is allowed to enter the running state; otherwise, it is intercepted and prohibited from running. Hardware capabilities typically include the hardware control services, graphics processing capabilities, and hardware operation interface range that the driver can provide.

[0048] Step 5: The heterogeneous closed-source driver enters the runtime phase. The driver calls dependent functions, and the adaptation layer obtains the determined function classification information. If the currently called dependent function is a statically compatible function, it is mapped to the corresponding function native to the HarmonyOS system. If it is a dynamically mutated function, the adaptation logic is dynamically generated, compiled and injected into the driver process, and the program link table entries are corrected to complete real-time symbol redirection. If it is a dedicated simulation function, the interface behavior is fully restored through independently customized simulation logic to achieve cross-platform functional compatibility.

[0049] When the driver performs low-level operations such as timers and event management, the adaptation layer intercepts incompatible system calls, extracts parameter features, and corrects and forwards them to the system kernel according to rules; for the missing calling capabilities of the HarmonyOS system, logic simulation is performed by combining existing system interfaces to ensure that the original business logic of the driver is executed normally.

[0050] The driver sends a Binder communication interface call request containing the target service name, method number, and parameter buffer. The adaptation layer forwards the request to the virtual Binder driver. The virtual Binder driver encapsulates the request into a standard data structure and forwards it to the user-space Binder proxy process. This triggers the Binder proxy process to parse the request data, query the service mapping table based on the target service name to obtain the service ID of the corresponding service in the HarmonyOS system, convert the method number into a method identifier supported by the HarmonyOS system service management mechanism, and convert the parameter buffer into a serialization format supported by the HarmonyOS system, thus completing the cross-platform adaptation of the parameters.

[0051] The Binder proxy process obtains the proxy object of the target service through the HarmonyOS system service management mechanism, sends the converted method identifier and serialization parameters to the proxy object, blocks and waits for the service to process the response, and the target service returns the response data after processing. The Binder proxy process deserializes the response data into the Android Binder standard format and then sends it back to the adaptation layer through the virtual Binder driver. The adaptation layer passes the response data to the driver. After the driver completes the single-frame rendering calculation, it initiates the screen submission. The adaptation layer reads the current frame buffer data from the rendering resource pool and pushes the data to the system display controller.

[0052] Among them, the virtual Binder driver is a cross-platform communication compatibility component deployed in the adaptation layer. It fully simulates the interaction interface and communication protocol of the native Android Binder device and intercepts standard Binder call requests issued by heterogeneous closed-source drivers. As an intermediate forwarding hub between Android Binder and HarmonyOS SAMGR cross-process communication mechanism, the virtual Binder driver uniformly encapsulates the communication data format, completes the protocol transfer and data transmission from Android Binder transactions to HarmonyOS system service calls, and realizes cross-platform bidirectional IPC communication.

[0053] Furthermore, when sensitive permission calls are triggered during driver operation, the adaptation layer permission mapping module performs real-time permission verification; permission requests are initiated as needed for unauthorized items, and the validity period of permissions is constrained by the timeout eviction policy to avoid excessive use and abuse of permissions.

[0054] Furthermore, the allocation method of the rendering resource pool in this invention is as follows: when the driver requests rendering resources, it inputs the resource type and task priority. The resource pool manager allocates resources according to the priority. Tasks with a priority greater than the threshold can obtain idle resources first. When resources are insufficient, the non-locked resources of lower priority tasks can be preempted. The recycling method is as follows: a dual recycling mechanism of reference counting and least recently used (LRU) is adopted. When the driver releases resources, the corresponding reference count is decremented. When the count reaches zero, it is marked as idle. The system periodically performs a global scan of the rendering resource pool. When the utilization rate is less than the threshold or the idle time of idle resources is greater than the threshold, redundant memory is reclaimed to reduce the overall resource overhead.

[0055] To further address the incompatibility issue between Android permissions and HarmonyOS capabilities, this invention triggers a permission verification when the Binder proxy process queries the Android permissions required by the target service. It checks whether the sandbox container process has already obtained the corresponding HarmonyOS capability. If it has, the verification is returned as successful. If it has not, a permission request is initiated to the user. After authorization, a validity period is set, and the permission is automatically revoked after the timeout. Subsequent calls require a new request.

[0056] Furthermore, to address the resource contention issue when multiple rendering tasks execute concurrently on a single display device, this invention assigns a unique identifier to each rendering task when the driver starts the rendering task, and classifies tasks into priority levels based on task type, dividing tasks into first performance requirements, second performance requirements, and third performance requirements with progressively decreasing priorities. When multiple rendering tasks simultaneously request rendering resources, resource arbitration is performed according to preset priority rules, prioritizing the allocation of idle resources to higher-priority rendering tasks. When idle resources are insufficient, unlocked resources occupied by lower-priority tasks can be preempted. After preemption, available resources are reallocated to lower-priority tasks. When resources are exhausted, lower-priority tasks enter a waiting queue and are blocked and suspended until they are awakened and executed after higher-priority tasks release resources.

[0057] Furthermore, in order to enable hot-swapping of hardware devices, the present invention performs the following process:

[0058] A hot-plug event listener is established in the adaptation layer. The listener is registered to achieve real-time acquisition of hardware hot-plug events of the HarmonyOS hardware driver framework. A callback function is registered with the device change callback mechanism. The callback function receives the event type and core device information passed by the HarmonyOS hardware driver framework. The event types include device addition and device removal.

[0059] When a hardware device is connected, a hot-plug event is triggered, sending a device addition notification to the sandbox container process. The process queries the device information of the new device, including the driver library path, device node, and hardware identifier. It establishes a path mapping between the Android hardware library and the HarmonyOS hardware driver framework's driver library, mapping the device node of the HarmonyOS hardware driver framework to a node name compatible with the Android Hardware Abstraction Layer (HAL), binding the path to complete the adaptation. The driver library name requested by the driver is redirected to the corresponding driver library path in the HarmonyOS hardware driver framework, obtaining the library handle. The dynamic dependencies of the driver library are checked; if the dependent HarmonyOS-related libraries are not loaded, they are loaded. The entry function of the Android Hardware Abstraction Layer is obtained, the hardware abstraction layer module is initialized, and the driver is registered in the adaptation layer and the HarmonyOS hardware driver framework, establishing the association between the driver and the hardware device.

[0060] When a hardware device is removed, the hot-plug listener captures the device removal event and sends a device removal notification to the sandbox container process; this triggers the HarmonyOS hardware driver framework to close the device handle, release driver library resources, avoid memory leaks, and ensure system stability.

[0061] Example:

[0062] This embodiment employs a heterogeneous closed-source driver compatibility method based on dynamic symbol redirection provided by the present invention. Through in-depth modification of the libhybris source code, dynamic symbol redirection mechanism, and single-device rendering resource scheduling architecture, it achieves complete porting of libhybris to the OpenHarmony system and efficient reuse of Android hardware abstraction layer components. It is suitable for hardware driver extension in OpenHarmony single-device multi-scenario scenarios (such as multi-window rendering, multi-application GPU sharing, and plug-and-play external hardware), and can cover high-performance device scenarios such as smartphones, smart TVs, and in-vehicle terminals. The specific process includes:

[0063] S1. Build the basic runtime environment for OpenHarmony-libhybris, providing basic support for libhybris to run on OpenHarmony through process sandboxing, source code modification, and compilation and deployment, and solving the compilation dependencies and runtime environment issues of libhybris.

[0064] S1.1, Android HAL container process sandbox configuration.

[0065] Create a dedicated Android HAL container process named android_hal_container using the OpenHarmony SandboxManager interface, and configure an independent file system sandbox for this process:

[0066] Mount the tmpfs file system as the sandbox root directory, and create the standard Android directory structure ( / vendor, / system, / data) under the root directory to simulate the Android runtime environment;

[0067] The `mount --bind` command binds the OpenHarmony HDF driver library path (` / system / lib / hdf`) to the ` / vendor / lib` path within the sandbox. By default, the driver library path dependencies are searched from ` / vendor / lib`.

[0068] Mount the OpenHarmony / proc and / sys file systems (read-only) to the corresponding paths within the sandbox to ensure that the Android HAL component can obtain hardware information through / proc / cpuinfo and / sys / class / gpu.

[0069] Request 256MB of reserved memory from RenderResourceManager for subsequent initialization of the rendering resource pool, avoiding competition for memory resources with native OpenHarmony applications (such as ArkUI applications).

[0070] S1.2 Initialization of the dynamic adaptation engine and configuration table.

[0071] Load the dynamic symbol redirection engine, whose dynamic library is libdyn_sym_morph.so. This engine includes the following core components and configurations:

[0072] The function behavior feature library stores the basic behavioral features of over 500 common Android bionic functions in JSON format (such as the default alignment range of malloc and the thread attribute mask of pthread_create), as shown in the following example:

[0073] {

[0074] "function": "malloc",

[0075] "default_align_range": [8, 32],

[0076] "memory_op_type": "allocate",

[0077] "return_type": "void*"

[0078] }

[0079] The libhybris adaptation configuration table records the interface mapping relationship of libhybris after modification, such as hybris_eglGetDisplay corresponding to OpenHarmony's ohos_eglGetDisplay, and hybris_dlsym corresponding to ohos_dlsym, to ensure that interface calls do not conflict.

[0080] The rendering resource scheduling parameter template defines the frame buffer specifications (4MB per block, supporting RGBA_8888 and YCbCr_420 formats), GPU context priority (high priority 1 and low priority 2), and resource reclamation threshold (idle for more than 500ms).

[0081] S1.3, in-depth modification, compilation and deployment of libhybris source code.

[0082] Source code dependency replacement: Analyze the libhybris native code line by line (version 1.0.0), and replace all dependencies incompatible with OpenHarmony, as follows:

[0083] glibc-specific function replacements: replace gnu_get_libc_version (get libc version) with the OpenHarmony ohos_get_libc_version interface; replace dladdr1 (symbol address resolution, supports additional parameters) with ohos_dladdr (OpenHarmony dynamic link library interface, supplementing parameter adaptation logic);

[0084] Linux system call replacement: Remove the sys / timerfd.h header file dependency and replace it with OpenHarmony's ohos_timer.h. Replace timerfd_create (create timer file descriptor) with a combined call of ohos_timer_create (create timer object) and eventfd (create event file descriptor) to simulate timer notification functionality;

[0085] Wayland interface removal: All modules related to Wayland and X11 in libhybris (such as egl_wayland.c and wl_display.c under src / wayland / directory) were removed, and header file dependencies such as wayland-client.h were deleted, reducing the compilation size by about 30%.

[0086] The build script was refactored, replacing the original Android.mk build script in libhybris with a BUILD.gn script supported by OpenHarmony. Key configurations are as follows:

[0087] Toolchain configuration: Specify the ohos-clang compilation toolchain for OpenHarmony, version 14.0.0, and set the target architecture (arm64-v8a or armeabi-v7a).

[0088] Dependency library configuration: Add OpenHarmony system library dependencies (libc.so, libhdf_base.so, librender_sched.so, libsamgr.so) to ensure that the compilation can link to core interfaces such as HDF and rendering scheduling;

[0089] Compilation option configuration: Add the -DOHOS_ADAPT macro definition to distinguish between OpenHarmony and Linux compilation logic (e.g., #ifdef OHOS_ADAPT uses ohos_dladdr, otherwise dladdr1); enable the -fPIC option to generate position-independent code and support dynamic loading.

[0090] Adding a module and exporting an interface: Add a core adapter module to the libhybris source code and export the interface for Android HAL to call:

[0091] A new dynamic symbol redirection module has been added, implementing interfaces such as hybris_dyn_sym_init (engine initialization) and hybris_dyn_sym_classify (function classification);

[0092] A new rendering resource scheduling module has been added, implementing interfaces such as hybris_render_resource_init (resource pool initialization) and hybris_render_resource_acquire (resource acquisition);

[0093] Add the new interface to the EXPORTED_SYMBOLS list in the libhybris core library (libhybris.so) to ensure that the Android HAL can obtain the interface address through dlsym.

[0094] Compilation and Deployment Verification:

[0095] The OpenHarmony build.sh script is executed to compile and modify the libhybris source code, generating three core dynamic libraries: libhybris.so (core library), libhybris-egl.so (EGL adapter library), and libhybris-hw.so (HAL loading library).

[0096] Deploy the compiled artifacts to the / vendor / lib path of the android_hal_container sandbox, verify the completeness of the dependency libraries using lddlibhybris.so (no missing library errors), and execute the initialization test using . / android_hal_container--test (to verify whether the sandbox mounting and engine loading are successful).

[0097] S2, Dynamic Symbol Redirection Adaptation Mechanism: By modifying the symbol resolution module of libhybris, a dynamic symbol redirection engine is introduced to replace the traditional static mapping table, thus solving the behavior difference between Android bionic functions and the OpenHarmony musl C library.

[0098] S2.1, Modification of the libhybris symbol resolution module.

[0099] Modify libhybris's src / linker / linker_hooks.c (the core file for symbol interception) and rewrite the symbol resolution logic:

[0100] Added hybris_dyn_sym_morph_init interface call: Add this interface call to the libhybris initialization function (hybris_init) to load the function behavior feature library and adaptation rules, ensuring that the dynamic symbol redirection engine is ready before symbol resolution;

[0101] Rewrite the `hybris_dlsym` function: The original function only looks up symbols through a static table. The modified function adds behavior detection triggering logic. When `hybris_dlsym(handle, symbol_name)` is called to look up a bionic function (such as `malloc`), it first queries the function behavior feature library. If the function is marked as a dynamic mutant, the function behavior probe is triggered instead of directly returning the address of the statically mapped function. If it is marked as a statically compatible function (such as `strlen`), the address of the musl function with the same name is directly returned.

[0102] S2.2 Function behavior feature extraction and classification.

[0103] Integrate function behavior probes into libhybris's HAL loading module to achieve real-time detection of function behavior:

[0104] Probe trigger timing: When the Android HAL component is loaded via hybris_dlopen, the probe is attached to the HAL process via the ptrace system call to intercept its first call to the bionic function (such as malloc(1024)).

[0105] Feature extraction content: The probe obtains CPU register values ​​through ptrace_getregs, extracts key features of function calls, and generates a behavioral feature vector containing the following fields:

[0106] Function name (e.g., malloc), parameter type list (e.g., size_t, value range 1024 to 2048), memory alignment requirements (by analyzing memory access instructions, it is determined to be 16-byte aligned), return value constraints (e.g., void*, must be non-NULL), global variable impact flag (e.g., whether pthread_mutex_init modifies the global lock state, marked as no).

[0107] Function classification logic: The probe classifies functions into three categories through the hybris_dyn_sym_classify interface and records the classification results to a dynamic symbol table (a hash table in memory):

[0108] Static compatibility: The behavior characteristics are fixed and completely consistent with musl functions (such as strlen, which takes the address of a string as input and returns the length, with no difference in memory operations), and are directly mapped to musl functions with the same name;

[0109] Dynamically variant: Behavioral characteristics change with the calling scenario (e.g., the alignment requirement of malloc is 16 or 32 bytes in different HALs), requiring dynamic generation of adaptation functions;

[0110] Dedicated simulation type: Bionic-specific functions (such as android_log_print for Android log output) do not have corresponding functions in musl and simulation logic needs to be generated based on features.

[0111] S2.3 Dynamic generation and injection of adaptor functions.

[0112] Real-time generation and injection of adaptor functions are achieved through a function template engine.

[0113] Template definition: Predefined adaptation logic templates for different function types. Placeholder parameters are reserved in the templates (e.g., {{align_size}} represents the memory alignment size). An example malloc adaptation template is shown below:

[0114] void* ohos_malloc_{{align_size}}(size_t size) {

[0115] / / Calculate the aligned memory size

[0116] size_t aligned_size = (size + {{align_size}} - 1) & ~({{align_size}} - 1);

[0117] / / Call musl's malloc

[0118] void* ptr = malloc(aligned_size);

[0119] / / Record alignment offset (for proper freeing).

[0120] if (ptr != NULL) {

[0121] *(size_t*)ptr = aligned_size - size;

[0122] return (char*)ptr + sizeof(size_t);

[0123] }

[0124] return NULL;

[0125] }

[0126] Template filling and code generation: When the probe extracts the characteristics of dynamically mutated functions (such as malloc requiring 16-byte alignment), the template engine replaces the placeholders through the hybris_func_template_fill interface (replacing {{align_size}} with 16) to generate complete adaptation function code (such as ohos_malloc_16).

[0127] Dynamic compilation and injection: The ohos_dlcodegen interface (dynamic code generation interface) of OpenHarmony is called to compile the generated code into a temporary shared library (such as / tmp / libohos_malloc_16.so), which is then loaded into the HAL process address space through the hybris_dlopen_temp interface (modified from libhybris's dlopen) to obtain the address of the adapted function.

[0128] Symbolic redirection: The symbolic redirection trigger finds the PLT (Program Link Table) entry for the function in the HAL process through dladdr, modifies the function address in the entry to the address of the dynamically loaded adapter function, and when HAL calls the function, it will directly execute the adapter function, thus realizing a closed loop from detection to dynamic generation to precise adaptation.

[0129] S2.4 System call level behavior correction.

[0130] A new system call correction module has been added to libhybris to resolve compatibility issues between Linux system calls that Android HAL depends on and OpenHarmony.

[0131] System call interception: Interception rules are registered through seccomp system calls. When the Android HAL calls a Linux-specific system call (such as epoll_ctl), the interception callback function is triggered.

[0132] Parameter feature extraction: In the callback function, obtain the system call parameters (such as epfd, op, and event parameters of epoll_ctl) through ptrace, and extract parameter features (such as op being EPOLL_CTL_ADD, and event containing the EPOLLWAKEUP flag).

[0133] Behavior correction and forwarding: Based on a predefined system call correction rule table, parameters are corrected. For example, the Android-specific EPOLLWAKEUP flag (used to wake up sleeping processes) is converted to the OpenHarmony OHOS_EPOLL_WAKE flag, and then the syscall function is called to forward the corrected parameters to the kernel.

[0134] Simulation of missing system calls: For Linux system calls that are completely missing in OpenHarmony (such as timerfd_create), simulation can be achieved by combining calls. For example, the function of timerfd_create is to create a timer and notify it through a file descriptor. The function of timerfd_create can be simulated by combining ohos_timer_create (creating a timer), eventfd (creating an event file descriptor), and ohos_timer_set_callback (writing eventfd in the timer callback), ensuring that the timing logic of Android HAL runs normally.

[0135] S3 and Binder-SAMGR IPC bidirectional conversion: By modifying the libhybris Binder adapter module, a communication bridge mechanism between Android Binder and OpenHarmony SAMGR (Service Manager) is built to ensure that cross-process calls of AndroidHAL components can be executed normally in OpenHarmony.

[0136] S3.1, modified libhybris Binder module.

[0137] The native Android Binder driver interaction code in libhybris has been trimmed, as it depends on the Android / dev / binder device node and is useless in OpenHarmony; a virtual Binder driver adaptation module has been added.

[0138] A new interface, hybris_vnbinder_init, has been added: it is used to load the vnbinder driver (virtual Binder driver, device node / dev / vnbinder) of the OpenHarmony kernel and establish a communication channel between libhybris and the virtual driver.

[0139] Rewrite the Binder core interface: Rewrite the original interfaces such as binder_open and binder_transact in libhybris into interfaces that call the vnbinder driver (such as vnbinder_open and vnbinder_transact) to ensure that Binder calls can be received by the virtual driver;

[0140] A new interface, hybris_binder_samgr_map, has been added to libhybris to build and maintain a mapping table from Android services to SAMGR services. This table is stored in JSON format, as shown in the example below:

[0141] {

[0142] "android_services": [

[0143] {

[0144] "name": "android.hardware.camera.service",

[0145] "samgr_service_id": "camera_service",

[0146] "permission": "android.permission.CAMERA"

[0147] },

[0148] {

[0149] "name": "android.hardware.audio.service",

[0150] "samgr_service_id": "audio_service",

[0151] "permission": "android.permission.RECORD_AUDIO"

[0152] } ]

[0154] }

[0155] This interface supports dynamic updates to the mapping table (such as adding service mappings when hardware is hot-swapped), ensuring that services on new devices can be correctly routed.

[0156] S3.2 Virtual Binder Driver and Protocol Parsing.

[0157] When an Android HAL component calls a Binder interface (such as binder_transact) through the modified libhybris, the request process is as follows:

[0158] HAL calls the hybris_binder_transact interface (the rewritten Binder call interface), passing in the target service name (such as android.hardware.camera.service), the method number (such as 1 to open the camera), and the parameter buffer (serialized camera ID).

[0159] libhybris sends requests to the vnbinder driver through the hybris_vnbinder_transact interface. The driver encapsulates the request into a binder_transaction_data structure (Android Binder standard format) and forwards it to the user-space Binder proxy service (binder_proxy, an independent process).

[0160] binder_proxy parses binder_transaction_data through the newly added hybris_binder_proto_parse interface:

[0161] Extract the target field (target service handle) and query the corresponding SAMGR service ID (such as camera_service) through the hybris_binder_samgr_map interface.

[0162] Extract the code field (method number) and convert it to a funcId supported by SAMGR (e.g., 1 corresponds to camera_open);

[0163] Extract the data field (parameter buffer), which is serialized in the Android Binder flat_binder_object format. Then, use the newly added ParcelConverter tool to convert it to the OpenHarmony MessageParcel format. For example, convert the handle (service handle) in flat_binder_object to a SAMGR RemoteObject reference, and convert string parameters to UTF-8 encoded StringParcel.

[0164] S3.3, SAMGR request conversion and return.

[0165] After completing protocol parsing, binder_proxy initiates a SAMGR call and processes the response:

[0166] Call the GetService interface of SAMGR to obtain the RemoteProxy of the target service (such as the proxy object of the camera service).

[0167] Call the SendRequest interface of RemoteProxy to send the converted funcId and MessageParcel to the SAMGR service, and block and wait for the service response;

[0168] After the service is completed, it returns response data in MessageParcel format (such as camera opening result: success or failure).

[0169] binder_proxy deserializes the response data into the binder_transaction_data format of Android Binder through ParcelConverter, and then sends it back to libhybris through the vnbinder driver;

[0170] libhybris passes the response data to the Android HAL component, completing a two-way IPC call loop.

[0171] S3.4, Permission Mapping and Security Verification.

[0172] A new permission mapping module has been added to libhybris to resolve the incompatibility issue between Android permissions and OpenHarmony capabilities.

[0173] Permission mapping library integration: The Android permission mapping library (permission_mapping.db) is compiled into a static library and integrated into libhybris. This library contains mapping relationships for more than 500 common permissions (such as android.permission.CAMERA mapping to ohos.permission.CAMERA, and android.permission.RECORD_AUDIO mapping to ohos.permission.MICROPHONE).

[0174] Permission verification triggered: When binder_proxy finds the Android permissions required by the service (such as android.permission.CAMERA required for the camera service), it calls the newly added hybris_perm_check interface to trigger permission verification;

[0175] Permission Request and Revocation: The `hybris_perm_check` interface checks whether the `android_hal_container` process has acquired the corresponding permissions through the `OpenHarmonyPermissionManagerClient` interface.

[0176] If the permission has been obtained, return a successful verification result directly; if not, call the RequestPermissionsFromUser interface to request permission from the user (e.g., a pop-up message prompting the user to allow the Android HAL to access the camera). In addition, to avoid permission abuse, a pre-authorization and timeout revocation mechanism is adopted. For example, the authorization validity period is 5 minutes, and after the timeout, the permission is automatically revoked through the RevokePermission interface, and a new request must be made on the next call.

[0177] S4, Single-device rendering resource scheduling and EGL-HDF direct connection architecture: By deeply modifying the EGL module of libhybris, a rendering resource pool and EGL-HDF direct connection architecture are built to solve the rendering resource contention and interface incompatibility issues of Android graphics HAL, thereby improving rendering performance.

[0178] Modification of S4.1 and libhybris EGL modules.

[0179] The EGL adaptation code related to Wayland and X11 in libhybris was trimmed, and header file dependencies such as wayland-client.h and X11 / Xlib.h were removed, reducing redundant code by approximately 40%.

[0180] Modify src / egl / eglplatform.h (EGL platform definition file) and redefine the EGL native types to bind them to OpenHarmony graphics objects:

[0181] typedef HdfDeviceObject* EGLNativeDisplayType;: Binds the EGL display type to an OpenHarmony HDF GPU device handle, ensuring that EGL can directly access the GPU hardware;

[0182] typedef OHOS::Window* EGLNativeWindowType;: Binds the EGL window type to an OpenHarmony window object, ensuring that the rendering results can be output to the OpenHarmony window;

[0183] Rewrite the libhybris EGL core interface (src / egl / eglapi.c) so that it directly calls the OpenHarmonyHDF GPU and window interface, instead of the Linux display driver:

[0184] Rewrite eglGetDisplay: The original interface calls wl_display_connect or XOpenDisplay, but after modification, it calls the hybris_hdf_device_open interface (newly added) to obtain the HDF GPU device handle and returns it as EGLDisplay;

[0185] Rewrite eglCreateContext: The original interface calls the context creation interface of the Linux GPU driver. After modification, it calls the HDF's GpuCreateContext interface to create a hardware-level GPU context.

[0186] Rewrite eglSwapBuffers: The original interface called the buffer exchange interface of the Linux display driver. After modification, it calls the HDF's GpuSubmitFrame interface to directly submit the frame buffer data to the display controller.

[0187] S4.2 Single-device rendering resource pool construction and management.

[0188] Build a rendering resource pool manager and integrate it into libhybris's EGL tool module to achieve unified management of rendering resources:

[0189] Resource pool initialization: When libhybris is initialized, the resource pool manager requests resources from OpenHarmony's RenderResourceManager through the hybris_render_resource_init interface to build a resource pool containing three partitions:

[0190] The frame buffer pool allocates 16 SurfaceBuffers of 4MB each, supporting two pixel formats: RGBA_8888 (game rendering) and YCbCr_420 (video decoding). Each buffer is assigned a unique ID, which records its usage status (idle or occupied), the assigned task ID (e.g., game task ID=1), and the idle duration.

[0191] The GPU context pool requests two independent GPU contexts, which are configured as high priority (for game rendering, with shader compilation optimization level set to the highest) and low priority (for video decoding or camera preview, with optimization level set to medium).

[0192] The synchronization signal area allocates 64KB of shared memory to store resource occupancy status flags (such as buffer lock flags and context free flags). Multi-threaded synchronization is achieved through atomic operations (such as __sync_bool_compare_and_swap) to avoid deadlocks caused by resource contention.

[0193] Resource allocation and recycling:

[0194] Allocation logic: When Android HAL requests resources through the hybris_render_resource_acquire interface, it passes in the resource type (such as buffer or GPU context) and task priority (such as 1 indicating high). The manager allocates resources according to the priority. For example, high-priority tasks can get free resources first. If resources are insufficient, they can preempt the non-locked resources of low-priority tasks (such as free buffers occupied by low-priority tasks).

[0195] Reclamation logic: A reference counting and LRU (Least Recently Used) strategy is adopted. For example, when HAL calls the hybris_render_resource_release interface to release resources, the reference count is decremented by 1. If the count is 0, it is marked as idle. Idle resources are scanned periodically (every 100ms). If the idle time exceeds 500ms and the resource pool utilization rate is less than 30%, redundant resources are automatically released (such as releasing 8 free buffers) to reduce memory usage.

[0196] S4.3, Android EGL and OpenHarmony HDF GPU interface are directly connected.

[0197] The EGL-HDF direct connection adapter layer enables direct communication between the Android EGL driver and the HDF GPU driver, bypassing the OpenHarmony RenderService intermediate layer and reducing conversion overhead.

[0198] eglGetDisplay direct connection process:

[0199] HAL calls eglGetDisplay(EGL_DEFAULT_DISPLAY) to get the default display;

[0200] The modified eglGetDisplay calls the hybris_hdf_device_open("gpu") interface and obtains the GPU device handle (HdfDeviceObject*) through HDF's HdfDeviceOpen.

[0201] Call the GpuGetDisplayInfo interface (HDF GPU interface) to obtain display parameters (resolution 1920*1080, refresh rate 60Hz), encapsulate the device handle and display parameters into an EGLDisplay and return it to HAL.

[0202] eglCreateContext direct connection process:

[0203] HAL calls eglCreateContext(dpy, config, share_ctx, attrib_list) to create an EGL context, where attrib_list contains EGL_CONTEXT_CLIENT_VERSION=3 (OpenGL ES 3.0).

[0204] The modified eglCreateContext converts attrib_list into configuration parameters supported by the HDF GPU (such as GPU_CONTEXT_VERSION=3, GPU_CONTEXT_SHADER_OPTIMIZE=1).

[0205] Call the GpuCreateContext interface to create a hardware GPU context, obtain the context handle, encapsulate it as an EGLContext and return it.

[0206] eglSwapBuffers direct connection process:

[0207] After HAL completes rendering a frame, it calls eglSwapBuffers(dpy, surface) to trigger buffer swapping.

[0208] The modified eglSwapBuffers obtains the SurfaceBuffer address of the current frame through the hybris_render_resource_get_buffer interface;

[0209] Call the GpuSubmitFrame interface (HDF GPU interface), pass in the buffer address, resolution, and pixel format, and submit it directly to the display controller;

[0210] This process eliminates the intermediate conversion of RenderService (the original conversion took about 8ms), reduces the time of eglSwapBuffers to less than 1ms, and improves the rendering frame rate by about 10%.

[0211] S4.4 Dynamic resource scheduling for multiple rendering tasks.

[0212] A new rendering task scheduler has been added to libhybris to resolve resource contention issues among multiple rendering tasks on a single device:

[0213] Task registration and priority assignment: When Android HAL starts rendering tasks (such as game rendering, video decoding), it registers the tasks through the `hybris_render_task_register` interface. The scheduler assigns a unique task ID to each task and sets its priority based on the task type, for example:

[0214] Priority 1: High-performance tasks such as game rendering and AR rendering;

[0215] Priority 2: Tasks with medium performance requirements, such as video decoding and live streaming;

[0216] Priority 3: Low-performance tasks such as camera preview and desktop widget rendering.

[0217] Resource arbitration logic: When multiple tasks request resources simultaneously, the scheduler arbitrates according to the following rules:

[0218] High-priority tasks are given priority access to available resources: if a game task with priority 1 requests a buffer and there is an available buffer, it will be allocated directly;

[0219] High-priority tasks can preempt low-priority resources: If a priority 1 task has insufficient resources and a priority 2 task occupies an idle buffer (unlocked), the task will preempt the buffer and reallocate other resources to the priority 2 task.

[0220] Low-priority task waiting: If the resource pool is exhausted, low-priority tasks (such as priority 3) enter the waiting queue and are blocked by the condition variable (pthread_cond_t), and will be awakened after the high-priority task releases the resources.

[0221] Dynamic expansion of the resource pool: The scheduler monitors resource utilization in real time (statistics are collected every 50ms). When the utilization of a certain type of resource (such as the frame buffer) exceeds 80% for 3 consecutive seconds, dynamic expansion is triggered.

[0222] Call the hybris_render_resource_expand interface to request expansion from RenderResourceManager. The expansion size is 50% of the current pool size (e.g., if there are currently 16 buffers, expand to 24).

[0223] After expansion, update the resource pool management table to ensure that new resources can be used by task requests and avoid rendering stutters due to insufficient resources.

[0224] S5. HDF hot-plug awareness-based driver loading: By modifying the hardware loading (HW) module of libhybris, it adapts to the driver management logic of the OpenHarmony HDF framework, supports hardware hot-plugging (such as external USB cameras and HDMI displays), and solves the problem of mismatch between driver loading path and device node.

[0225] S5.1 and libhybris HW module modifications.

[0226] Modify the libhybris Android HAL loading core file, rewrite the hw_get_module function, and remove the original Android vendor path lookup logic:

[0227] Original function logic: via / vendor / lib / hw / <module>.so、 / system / lib / hw / <module>Locate the HAL library in the .so file path;

[0228] The modified logic is as follows: HJDF device information parsing is added. First, the device information managed by HDF is obtained through the hybris_hdf_device_query interface, and then the driver library path is determined.

[0229] New core interfaces: Implement the following interfaces in the newly added file src / hw / hdf_hw_adaptor.c to support HDF driver loading:

[0230] hybris_hdf_device_query: Calls the HDF HdfDeviceManager::GetDeviceInfo interface, passing in the device type (such as camera, audio), and obtains the device's driver library path (such as / system / lib / hdf / libcamera_driver.z.so), device node (such as / dev / hdf / camera / 0), and hardware ID (such as vendor.huawei.hardware.camera);

[0231] hybris_hdf_lib_redirect: Based on the mapping rules between Android library names and HDF library paths, redirect the library name requested by Android HAL (such as libcamera_hal.so) to the HDF driver library path;

[0232] hybris_hdf_node_redirect: Maps HDF device nodes (such as / dev / hdf / camera / 0) to node names familiar to Android HAL (such as / dev / video0), and implements path binding through mount --bind.

[0233] S5.2, HDF device hot-plug event monitoring.

[0234] Add a hot-plug event listener to libhybris to enable real-time detection of HDF hardware hot-plugging:

[0235] Listener registration: Register a callback function to HDF's IDeviceChangeCallback via the hybris_hdf_listener_register interface. This function is triggered when hardware is inserted or removed.

[0236] Event type determination: The callback function receives the event type (DEVICE_ADDED / DEVICE_REMOVED) and device information (type, path, node) passed by HDF, and determines whether it is an insertion or removal event;

[0237] Event notification: If it is an insertion event, a device addition notification (signal SIGUSR1) is sent to the android_hal_container process through the hybris_hdf_hotplug_notify interface; if it is a removal event, a device removal notification (signal SIGUSR2) is sent, triggering the resource release logic of the HAL component.

[0238] S5.3 Dynamic Device Mapping Table Update and Driver Loading.

[0239] When the android_hal_container process receives a notification that a device has been added, it triggers the driver loading process:

[0240] Device information update: Call the hybris_hdf_device_query interface to obtain complete information about the new device (such as the driver library path of the external USB camera / system / lib / hdf / libcamera_ext.z.so, device node / dev / hdf / camera / 1);

[0241] Device node mapping: The HDF node / dev / hdf / camera / 1 is mapped to Android's / dev / video1 via the hybris_hdf_node_redirect interface, and the node permissions are set via chmod (0666, to ensure HAL is readable and writable).

[0242] Driver library path redirection: The modified hw_get_module function calls the hybris_hdf_lib_redirect interface to redirect the libcamera_hal.so requested by the Android HAL to / system / lib / hdf / libcamera_ext.z.so.

[0243] Driver library loading and dependency checking:

[0244] Call the hybris_dlopen interface to load the redirected driver library and obtain the library handle;

[0245] The newly added hybris_dlcheck_deps interface checks library dependencies: it iterates through the library's dynamic dependency table (obtained via readelf -d), and if it depends on the OpenHarmony library (such as libhdf_utils.so) and is not loaded, it automatically calls the hybris_lib_auto_load interface to load the dependent library.

[0246] Call dlsym to obtain the entry function of Android HAL (such as HAL_MODULE_INFO_SYM), initialize the HAL module, and complete driver loading.

[0247] If a device removal notification is received, the hybris_hdf_device_close interface is called to close the device handle and release driver library resources (via dlclose) to avoid memory leaks.

[0248] S6. Runtime monitoring and dynamic optimization: A new runtime monitoring and dynamic optimization module has been added to libhybris to achieve real-time monitoring of adaptation effects and performance, as well as fault self-healing, ensuring that Android HAL components run stably on OpenHarmony.

[0249] S6.1 Build the libhybris monitoring module.

[0250] In libhybris, a new feature allows for the registration of key monitoring metrics via the newly added hybris_perf_monitor_init interface, enabling end-to-end data collection.

[0251] Monitoring metric definition:

[0252] Dynamic adaptor function time consumption: Record the time consumption of a single call to each dynamically generated adaptor function (such as ohos_malloc_16), with a target threshold of less than 20μs;

[0253] EGL-HDF direct connection time: Record the call time of eglGetDisplay, eglCreateContext, and eglSwapBuffers, with target thresholds of less than 1ms, less than 2ms, and less than 1ms, respectively;

[0254] Rendering resource utilization: Record the utilization of frame buffer and GPU context, with a target threshold of less than 80%; Hot-plug device loading time: Record the time from device insertion to driver loading completion, with a target threshold of less than 1 second; IPC conversion latency: Record the round-trip time (RTT) of Binder-SAMGR protocol conversion, with a target threshold of less than 2 ms.

[0255] Data collection method:

[0256] Elapsed time metrics: The start time of the function call is recorded using clock_gettime(CLOCK_MONOTONIC, &start), and the time difference (end - start) is calculated after the call ends.

[0257] Utilization metric: Periodically (every 50ms) scan the resource pool management table, calculate the ratio of occupied resources to total resources, and then multiply by 100%.

[0258] Data storage: The collected indicator data is stored in a memory circular buffer (size 1024 records) to support subsequent querying and analysis.

[0259] Log output and alerts:

[0260] The monitoring data is output to the OpenHarmony logging system (OH_LOG) through the hybris_perf_log interface. The log format includes timestamp, metric name, value, and threshold. Example: [1698765432] Dynamic adaptation function time: 25μs (threshold: 20μs);

[0261] When a metric exceeds a threshold, an alarm is triggered: a system notification (e.g., "Dynamic adaptation function time exceeded the limit, please check the adaptation logic") is sent via the ohos_notification_post interface, and an alarm log is recorded to / data / log / hybris_perf_alert.log for easy problem localization.

[0262] S6.2, Adjustment of dynamic adaptation strategy.

[0263] Based on the collected indicator data, the monitoring module triggers a dynamic optimization strategy to achieve self-healing from faults.

[0264] Dynamic adapt function optimization:

[0265] If the time taken by a certain dynamic adaptation function (such as ohos_malloc_16) exceeds 20μs for 5 consecutive times, the newly added hybris_dyn_sym_pregen interface will be triggered.

[0266] This interface pre-generates adaptation functions for common scenarios (such as malloc adaptation functions aligned to 8, 16, or 32 bytes), compiles them into a resident shared library, and subsequent calls directly load this library, avoiding real-time compilation overhead (the time consumption can be reduced from 25μs to 15μs).

[0267] Rendering resource scheduling optimization:

[0268] If the frame buffer usage rate is greater than 80% for 3 consecutive seconds, the hybris_render_resource_expand interface is triggered, and the pool size is expanded by 50% of the current pool size (e.g., from 16 blocks to 24 blocks).

[0269] If the utilization rate is less than 20% for 3 consecutive seconds, the hybris_render_resource_shrink interface is triggered to release 50% of the idle resources (e.g., from 16 blocks to 8 blocks) and reduce memory usage.

[0270] If the number of GPU context contention events exceeds 10 times per second (determined by the lock contention count in the synchronization signal area), add a new low-priority GPU context to distribute the task load.

[0271] IPC conversion optimization: If the IPC conversion delay is greater than 2ms for 5 consecutive times, the newly added hybris_binder_proto_compress interface is triggered to compress the MessageParcel data using LZ4 compression (compression rate of about 30%), reducing the amount of data transmitted and lowering the latency.

[0272] S6.3, automatic version compatibility adaptation.

[0273] A version adaptation module has been added to libhybris to resolve compatibility issues between different Android versions of HAL:

[0274] Version detection: The newly added hybris_hal_version_detect interface is used to parse the ELF file of the Android HAL library and extract the version information (such as Android 13, API Level 33) from the .note.android.build section.

[0275] Policy matching: Match the pre-stored mapping table between the version and the adaptation policy based on the version information (e.g., Android 13 HAL matches the policy_android13_ohos5.1 policy). This policy contains correction logic for specific versions (e.g., the parsing rules for the camera_metadata field added in Android 13).

[0276] Policy loading: The hybris_version_policy_load interface is called to load the matching policy and automatically adjust the adaptation logic (such as enabling camera_metadata field parsing), without the need for manual modification of libhybris code;

[0277] Unknown version compatibility: If an unknown Android version (such as the future Android 15) is detected, compatibility mode will be automatically enabled, which means adopting the strategy of the closest version (such as matching Android 15 with Android 14), and the version information will be recorded in the log for subsequent optimization.

[0278] Experiments have verified that this embodiment, through in-depth modification of the libhybris source code and full-link adaptation to the OpenHarmony architecture, achieves complete porting of libhybris to the OpenHarmony system and efficient reuse of Android HAL components. Compared with existing technical solutions, it has the following technical advantages:

[0279] Breakthroughs in libhybris porting integrity and compatibility: Through source code dependency replacement, module trimming, and interface modification, the dependency conflicts between libhybris and the OpenHarmony C library, system calls, and graphics framework have been completely resolved. The modified libhybris can be stably compiled and run on OpenHarmony and supports multiple versions of HAL components from Android 8 to Android 14, with compatibility coverage increased from 60% to 95%.

[0280] The static symbol adaptation has been dynamically upgraded. The dynamic symbol redirection engine replaces the traditional static mapping table. By detecting function behavior in real time and dynamically generating adaptation functions, it solves the problem of differences in function behavior between different HAL components (such as changes in malloc alignment requirements), avoids HAL crashes caused by memory access errors, and improves runtime stability by 80%.

[0281] The significant leap in graphics rendering performance is achieved by the EGL-HDF direct connection architecture, which skips the RenderService intermediate layer and reduces the eglSwapBuffers latency from 8ms to less than 1ms. The priority arbitration mechanism of the rendering resource pool resolves multi-task resource contention, increasing GPU resource utilization from 40% to 100%, improving game rendering frame rate by approximately 10%, and reducing video decoding stuttering by 90%.

[0282] Plug-and-play support for hot-swapping hardware, based on HDF hot-swapping awareness driver loading logic, enables second-level recognition and driver loading of external hardware (such as USB cameras and HDMI displays), reducing the adaptation response time from minutes to less than 1 second, meeting the expansion needs of OpenHarmony devices.

[0283] Runtime monitoring and fault self-healing capabilities: The newly added performance monitoring module enables full-link metric collection and alarms, and dynamic optimization strategies can automatically solve problems such as excessive time consumption and insufficient resources without manual intervention, reducing system operation and maintenance costs by 70%.

[0284] Automated version compatibility adaptation, through a mapping table between versions and adaptation strategies and compatibility modes, supports automatic adaptation of future Android version HALs, avoiding the need for manual code modification for each version update, and improving adaptation efficiency by 60%.

[0285] This invention provides a complete and efficient technical path for OpenHarmony to reuse Android's vast hardware ecosystem, which can accelerate the application of OpenHarmony in high-performance single-device scenarios such as smartphones, smart TVs, and in-vehicle terminals.

[0286] In summary, the above are merely preferred embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.< / module> < / module>

Claims

1. A method for compatible operation of heterogeneous closed-source drivers based on dynamic symbol redirection, characterized in that, Specifically, the following steps are included: Modify the adaptation layer source code to make it compatible with HarmonyOS, refactor the build script, build a dynamic symbol redirection engine, and establish a service mapping table between Android and HarmonyOS, a permission mapping table between Android permissions and HarmonyOS capabilities, and an interface adaptation table between the adaptation layer interface and HarmonyOS interface. The compilation and adaptation layer generates the first core dynamic library; HarmonyOS creates an Android Hardware Abstraction Layer container process, configures an independent file system sandbox for it (referred to as the first sandbox), and creates a directory structure in the general way of Android system; maps the HarmonyOS hardware driver library to the first sandbox, mounts the system hardware to the first sandbox, and reserves memory for rendering resources; Load the first core dynamic library, start the dynamic symbol redirection engine, and load the function behavior feature library, interface adaptation table, service mapping table, and permission mapping table. HarmonyOS loads heterogeneous, closed-source drivers into the first sandbox. The driver triggers the dynamic symbol redirection engine to retrieve functions from the function behavior feature library. If the function is statically compatible, it returns the address of the HarmonyOS standard library function. If it is dynamically mutated or dedicated to simulation, it records the function information and returns a placeholder. HarmonyOS builds a rendering resource pool, encapsulates the display device handle and display parameters into a standard display object, and returns it to the driver. The driver then creates a hardware-level GPU context. The driver registers hardware information with the HarmonyOS system to complete device registration and marks it as ready. It then associates and binds with HarmonyOS services through the adaptation layer based on the service mapping table and enters the running state. When the driver calls a dependent function, the adaptation layer performs native mapping, dynamic adaptation logic injection, or dedicated simulation replication adaptation according to the function type. After the driver initiates a Binder communication request, the virtual Binder driver and the Binder proxy process complete the cross-platform conversion of service ID, method identifier, and parameter format according to the service mapping table, call the HarmonyOS target service, and return the processing result. After the driver completes single-frame rendering, the adaptation layer retrieves the frame buffer data from the rendering resource pool and pushes it to the system display controller to complete the screen output.

2. The heterogeneous closed-source driver compatible operation method according to claim 1, characterized in that, The method for establishing the permission mapping table between Android permissions and HarmonyOS system capabilities is as follows: Determine all native permissions required for driver operation, including hardware access, graphics rendering, inter-process communication, and low-level device operation. Based on the scope of Android permission control, calling scenarios, and usage purposes, match system capability identifiers with completely consistent functions and control boundaries in the HarmonyOS system. For Android permissions that do not have matching system capabilities, combine multiple HarmonyOS system capabilities to achieve equivalent substitution. The correspondence between Android permission identifiers and HarmonyOS system capability IDs constitutes a permission mapping table.

3. The heterogeneous closed-source driver compatible operation method according to claim 1, characterized in that, The graphics modules that are not related to the HarmonyOS system will be trimmed, specifically: The adaptation code for graphics modules related to the desktop graphics system in the adaptation layer has been trimmed, and the corresponding header file dependencies have been removed. The display type of the graphics module has been associated with the GPU device handle of the HarmonyOS hardware driver framework, enabling the graphics module to directly access the GPU hardware. The window type of the graphics module has been associated with the HarmonyOS window object. The calls to the system display driver in the graphics module have been replaced with calls to the HarmonyOS hardware driver framework and graphics window interface. The graphics context creation interface has been modified to create a hardware-level graphics context through the HarmonyOS GPU-related interface. Modify the frame buffer exchange interface to directly submit rendered frame data to the HarmonyOS system display controller.

4. The heterogeneous closed-source driver compatible operation method according to claim 1, characterized in that, During the driver registration phase, when the driver has preset permissions, the adaptation layer triggers capability permission verification, checks the system capabilities allocated to the first sandbox container process. If the verification passes, the driver is allowed to enter the running state; if the permissions are insufficient, the driver is intercepted and prohibited from running. Among these, hardware functional capabilities refer to the hardware control services, graphics processing capabilities, and hardware operation interface range provided by the driver.

5. The heterogeneous closed-source driver compatible operation method according to claim 1, characterized in that, The dynamic adaptation logic injection method is as follows: dynamically generate adaptation logic, compile and inject it into the driver process and correct the program link table entries, and complete real-time symbol redirection. The adaptation logic is a process used to perform parameter conversion, process correction, behavior consistency adaptation and result translation between the driver and HarmonyOS native functions to shield the differences in interface implementation between platforms.

6. The heterogeneous closed-source driver compatible operation method according to claim 1, characterized in that, The exclusive simulation replication and adaptation method is as follows: the interface behavior is completely restored by independently customized simulation logic to achieve cross-platform functional compatibility. The independent simulation logic is the process of completely simulating the function and behavior of the original interface by maintaining private state, data structure and calculation logic.

7. The heterogeneous closed-source driver compatible operation method according to claim 1, characterized in that, When the driver executes timer and event management low-level operations, the adaptation layer intercepts incompatible system calls, extracts parameter features, corrects them, and forwards them to the system kernel; for the missing calling capabilities of the HarmonyOS system, equivalent logic simulation is performed by combining existing system interfaces.

8. The heterogeneous closed-source driver compatible operation method according to claim 1, characterized in that, The allocation method of the rendering resource pool is as follows: When the driver requests rendering resources, it inputs the resource type and the current task priority. The HarmonyOS system allocates resources according to the priority. When the current task priority is greater than the threshold, it will take priority to obtain idle resources. When resources are insufficient, it will preempt the unlocked resources of tasks with lower priorities than the current task. When resources are exhausted, tasks with priorities less than the threshold will enter the waiting queue and be blocked and suspended until the task with a priority greater than the threshold releases resources and is awakened to execute. The recycling method is as follows: a dual recycling mechanism of reference counting and least recently used is adopted. When the driver releases resources, the corresponding reference count is decremented. When the count reaches zero, it is marked as idle. The system periodically scans the rendering resource pool globally. When the utilization rate is less than the threshold or the idle time of idle resources is greater than the threshold, redundant memory is reclaimed.

9. The heterogeneous closed-source driver compatible operation method according to claim 1, characterized in that, When the Binder proxy process finds the Android permissions required by the target service, it triggers a permission check to see if the sandbox container process has obtained the corresponding HarmonyOS system capability. If it has, it directly returns that the verification passed. If the permission is not granted, a permission request will be sent to the user. After authorization, a validity period will be set. The permission will be automatically revoked after the expiration time, and a new request will be sent for subsequent calls.

10. The heterogeneous closed-source driver compatible operation method according to claim 1, characterized in that, A hot-plug event listener is established in the adaptation layer and the listener is registered to obtain hardware hot-plug events of the HarmonyOS hardware driver framework in real time. A callback function is registered with the device change callback mechanism. The callback function receives the event type and core device information passed by the HarmonyOS hardware driver framework. The event types include device addition and device removal. When a hardware device is connected, a hot-plug event is triggered, a device addition notification is sent to the sandbox container process, the device information of the new device is queried, including the driver library path, device node and hardware identifier, a path mapping is established between the Android hardware library and the HarmonyOS hardware driver framework driver library, the device node of the HarmonyOS hardware driver framework is mapped to a node name compatible with the Android hardware abstraction layer, and the path is bound to complete the adaptation; the driver library name of the driver request is redirected to the driver library path corresponding to the HarmonyOS hardware driver framework, and the library handle is obtained; the dynamic dependencies of the driver library are checked, and if the dependent HarmonyOS library is not loaded, the dependent library is loaded. Obtain the entry function of the Android hardware abstraction layer, complete the registration of the driver in the adaptation layer and the HarmonyOS hardware driver framework, and establish the association between the driver and the hardware device. When a hardware device is removed, the hot-plug listener captures the device removal event, sends a device removal notification to the sandbox container process, triggers the HarmonyOS hardware driver framework to close the device handle, and releases driver library resources.

Images