A HarmonyOS platform compatibility method for heterogeneous closed-source drivers

Abstract

This invention discloses a method for HarmonyOS platform compatibility operation for heterogeneous closed-source drivers. After the HarmonyOS system starts, the system service management framework constructs a service mapping table, protocol parsing logic, and hardware resource pool for heterogeneous closed-source drivers, and allocates independent resource quotas to the drivers. During the driver loading phase, the binary files of heterogeneous closed-source drivers are mapped to the corresponding process address space to complete dynamic linking. The external interfaces of the drivers themselves are connected to system services through protocol parsing, and a dedicated scheduling strategy is allocated to the drivers. During the driver registration process, the interfaces of the drivers themselves are adapted to system services through protocol parsing, service handle conversion and binding are completed, and a communication link between the drivers and system services is established. During the driver running phase, the kernel performs service call permission verification, adopts a DMA-BUF shared memory zero-copy mechanism to realize data transmission, and ensures transmission security through kernel synchronization and mutual exclusion.

Description

Technical Field

[0001] This invention belongs to the field of cross-operating system hardware adaptation and performance optimization technology, specifically involving a method for HarmonyOS platform compatibility operation for heterogeneous closed-source drivers. Background Technology

[0002] Existing heterogeneous binary drivers, taking Android drivers as an example, generally employ the libhybris compatibility layer for HarmonyOS adaptation. As a user-space middleware, libhybris achieves compatibility between bionic, musl, and glibc through symbol interception, dynamic proxies, and multi-process forwarding. However, this compatibility approach typically suffers from the following technical limitations: First, redundant middleware overhead. Libhybris achieves adaptation through user-space symbol interception and multi-process forwarding, requiring driver calls to pass through three layers—driver, libhybris, and then HarmonyOS—increasing call latency by 15% to 20%. For example, GPU rendering frame time increases from 16ms to 19ms, and the middleware itself consumes 10% to 15% of CPU resources. Second, fragmented resource scheduling. Libhybris drivers run in independent container processes, completely independent of the resource scheduling of HarmonyOS's native processes. GPU context switching time exceeds 5ms, and the memory page miss rate is 3 times higher than that of native drivers. 0%, resource deadlocks are prone to occur when multiple drivers run concurrently; third, the security mechanisms are disconnected. libhybris does not integrate the security-enhanced Linux of HarmonyOS, namely SELinux and the Trusted Execution Environment (TEE) mechanism. There are security vulnerabilities when drivers access sensitive hardware, and permission verification relies on user-space mapping, which takes more than 10μs; fourth, the core differences are poorly adapted. There is a lack of performance optimization in handling key differences such as C library memory allocation alignment, graphics buffer format, and IPC protocol conversion. For example, Android Bionic's 16-byte aligned malloc requires additional memory copying when adapting to user space, with a single call taking more than 20μs, and graphics buffer format conversion taking more than 5ms.

[0003] The aforementioned issues may occur during the compatible operation of all heterogeneous closed-source drivers, resulting in compatibility, performance, and stability failing to meet commercial requirements. Summary of the Invention

[0004] In view of this, the present invention provides a HarmonyOS platform compatible operation method for heterogeneous closed-source drivers. Through deep adaptation, native integration at the system layer and real-time performance scheduling, it achieves low-latency and highly stable operation of heterogeneous closed-source drivers on the HarmonyOS platform without relying on the libhybris intermediate layer.

[0005] This invention provides a method for HarmonyOS platform compatibility with heterogeneous closed-source drivers, specifically including the following steps:

[0006] When HarmonyOS starts up, the system service management framework builds a service mapping table between the external services and native system services required by heterogeneous drivers, establishes protocol parsing logic, builds a hardware resource pool, and allocates hardware resource quotas; it assigns a dedicated kernel scheduling group to heterogeneous driver processes, sets CPU core affinity and binds them to the corresponding CPU core, and creates an independent memory isolation zone; it stores the system library symbol information that heterogeneous drivers depend on in the kernel-level symbol cache and establishes a symbol index structure to record the storage location of the system libraries.

[0007] When the heterogeneous driver is loaded, the HarmonyOS system maps its binary file to the virtual address space of the heterogeneous driver process, determines the storage location based on the symbol index structure, and returns it to the dynamic linker; it completes memory allocation alignment and adaptation in kernel mode, and creates hard links in the device directory so that the nodes used by it and the native device nodes of the HarmonyOS system point to the same hardware entity;

[0008] When a heterogeneous driver registers, it sends a registration request to the HarmonyOS hardware driver framework. The protocol parsing logic completes the parsing, converts the heterogeneous driver's external service handle into a remote object reference, generates a HarmonyOS native request based on the parsing result, triggers the HarmonyOS service framework to allocate the target service for it, and updates the service mapping table. It also parses the heterogeneous driver's ELF file to extract features and obtains feature vectors. Based on the feature vectors, it loads the matching performance and security policies and injects the policy parameters into the corresponding system modules.

[0009] When a heterogeneous driver initiates a service call, the kernel verifies the running permissions of the heterogeneous driver process and their matching access permissions with the target service. If the verification fails, the call request is rejected; otherwise, the call is allowed. When transferring data, the heterogeneous driver requests DMA-BUF shared memory and obtains a file descriptor within the hardware resource quota. The system service management framework maps this shared memory to the target service address space and uses the kernel synchronization and mutual exclusion mechanism to achieve zero-copy data transfer.

[0010] Furthermore, when a missing system library that the heterogeneous driver depends on is detected during heterogeneous driver loading, the dynamic linker reads the heterogeneous driver's ELF file to extract the missing dependency symbols, searches for functionally equivalent compatible symbols in the system's compatible interface library, and binds the driver's missing symbols to the compatible symbols through symbol redirection, thus completing automatic dependency repair.

[0011] Furthermore, during heterogeneous driver registration, when multiple heterogeneous drivers compete for the same type of hardware resources, resource arbitration is performed according to driver priority. Drivers with priority greater than the threshold are allocated resources first, and the maximum duration of resource occupation is set.

[0012] Furthermore, during heterogeneous driver registration, for hardware hot-plug scenarios, the device hot-plug callback mechanism is extended. A processing thread is set up to listen for device access and removal events. When a device is accessed, the matching heterogeneous driver is queried based on the device information. The system service management framework dynamically adds mapping entries to update the service mapping table, completes the registration of the new service, and synchronously notifies the upper-layer application to reinitialize the device. When a device is removed, the system service management framework deregisters the corresponding service, uninstalls the heterogeneous driver, and releases related resources.

[0013] Furthermore, when a heterogeneous driver runs and sets up hardware resources, the system service management framework calls the Trusted Execution Environment service to initialize a trusted session for the corresponding heterogeneous driver and build a trusted verification environment. When the heterogeneous driver calls the setting operation, the trusted verification process is triggered to verify the legitimacy of the heterogeneous driver's trusted certificate. After the verification is passed, the heterogeneous driver is allowed to access the set hardware resources, and the relevant data is stored in the trusted memory area.

[0014] Furthermore, the method for completing memory allocation alignment adaptation in kernel mode is as follows:

[0015] Create a memory cache containing cache blocks with the required alignment granularity for various heterogeneous drivers;

[0016] Receive the requested memory size from user space, calculate the aligned size according to the alignment granularity of the heterogeneous driver; allocate a cache block with the corresponding alignment granularity from the memory cache, add alignment information marker to the cache block header, and then return the cache block address to user space;

[0017] When releasing memory, the user-mode address is restored to the actual cache block address, the header flag of the cache block is read to complete the validity check, and then the cache block is returned to the dedicated memory cache area to complete the release.

[0018] Furthermore, the method of loading the matched performance and security policies based on the feature vectors and injecting the policy parameters into the corresponding system modules is as follows:

[0019] A driver version adaptation service is built to run as an independent system service. When heterogeneous drivers are registered and loaded, the driver version adaptation service parses the ELF format file of the heterogeneous driver through the driver file parsing interface, extracts the version feature information, which contains system version, interface level and build identifier in the driver's built-in segment, as well as the hardware feature information, which contains hardware type, hardware capability requirements and security level requirements, and encapsulates the version feature information and hardware feature information into a driver feature vector.

[0020] Based on the driver feature vector, the matching performance adaptation policy and security operation policy are loaded from the system policy configuration directory. The performance parameters corresponding to the performance adaptation policy include the number of pre-allocated frame buffers, data format configuration, and the lower limit of hardware operating frequency. The security parameters corresponding to the security policy include security domain labels, trusted execution environment enabling requirements, and system permission requirements. The performance parameters are input into the hardware rendering and driver management module, and the security parameters are input into the security management module and trusted environment proxy module.

[0021] Furthermore, for the graphics heterogeneous driver, when it receives display parameters during its operation, it first obtains the device handle of the graphics driver in the system hardware driver framework, reads the system display parameters containing resolution, refresh rate, pixel format and display controller identifier, and returns the device handle and system display parameters to the heterogeneous driver; for the graphics context creation interface, it parses the passed configuration attributes, extracts the context version, priority and debug flag, and converts them into configuration parameters that the graphics driver in the system hardware driver framework can recognize, calls the graphics driver interface to create a hardware context and obtain the handle, and returns it to the heterogeneous driver after encapsulation.

[0022] A new context scheduling module is added to the graphics driver of the system hardware driver framework. Different priorities are assigned to heterogeneous drivers according to their application scenarios. During scheduling, contexts with a priority greater than the threshold preempt the unlocked resources of contexts with a lower priority. A time-slice round-robin mechanism is used to limit the maximum single occupancy time of a context. When switching contexts, the texture data of the next context is preloaded into the graphics cache through a cache preloading mechanism.

[0023] When the heterogeneous driver creates a rendering surface, it allocates a buffer managed by the hardware driver framework and adds a compatibility identifier. When creating graphics, it binds the physical memory address of the buffer. When the heterogeneous driver submits a rendering frame, it generates a synchronization signal object and passes it to the heterogeneous driver. When rendering output, it directly submits the frame data rendered by the heterogeneous driver to the display controller to complete the screen output.

[0024] Furthermore, the service mapping table is cached in the service cache area.

[0025] Furthermore, when a fault occurs during the operation of the heterogeneous driver, the call stack information of the heterogeneous driver process is obtained, the abnormal function is identified, the fault type is determined based on the obtained monitoring data, the relevant resources are temporarily expanded when resources are insufficient, and the driver is automatically uninstalled and reloaded and the default configuration is restored when the driver crashes.

[0026] Beneficial effects:

[0027] After the HarmonyOS system boots up, this invention first starts the system service management framework, constructs the service mapping table, protocol parsing logic, and hardware resource pool required by heterogeneous closed-source drivers, allocates independent resource quotas to drivers, and provides basic support for heterogeneous closed-source drivers. During the driver loading phase, the binary files of heterogeneous closed-source drivers are mapped to the corresponding process address space, completing dynamic linking and dependency repair. Through protocol parsing, the external interfaces of the driver itself are connected to system services, and a dedicated scheduling strategy is allocated to the driver. During the driver registration process, the driver's own interfaces are adapted to system services through protocol parsing, completing service handle conversion and binding, and establishing a communication link between the driver and system services. During the driver running phase, resource allocation is optimized through real-time monitoring and dynamic scheduling, combined with security verification and fault self-healing mechanisms, to handle performance fluctuations and anomalies during driver operation, achieving compatibility and adaptation between heterogeneous closed-source drivers and the HarmonyOS system. Attached Figure Description

[0028] Figure 1 This is a flowchart illustrating a method for operating on a HarmonyOS platform with heterogeneous closed-source drivers, as provided by the present invention. Detailed Implementation

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

[0030] This invention provides a method for HarmonyOS platform compatibility operation for heterogeneous closed-source drivers. The core idea is as follows: After HarmonyOS starts, the system service management framework is first activated to construct the service mapping table, protocol parsing logic, and hardware resource pool required by the heterogeneous closed-source drivers. Independent resource quotas are allocated to the drivers, providing basic support. During the driver loading phase, the binary files of the heterogeneous closed-source drivers are mapped to the corresponding process address space, completing dynamic linking and dependency repair. Protocol parsing connects the driver's external interfaces with system services, and a dedicated scheduling strategy is allocated to the drivers. During driver registration, protocol parsing adapts the driver's interfaces to system services, completing service handle conversion and binding, and establishing a communication link between the driver and system services. During driver operation, real-time monitoring and dynamic scheduling optimize resource allocation, combined with security verification and fault self-healing mechanisms, to handle performance fluctuations and anomalies during driver operation, achieving compatibility and adaptation between heterogeneous closed-source drivers and HarmonyOS.

[0031] This invention provides a method for HarmonyOS platform compatibility with heterogeneous closed-source drivers, the processing flow of which is as follows: Figure 1 As shown, the specific steps include:

[0032] Step 1: HarmonyOS starts with a heterogeneous closed-source driver as the heterogeneous driver. The system service management framework starts and builds a service mapping table between the external services required by the heterogeneous driver and the native system services according to the preset external service name and system service ID mapping rules. The table is cached in the service cache area to improve service lookup efficiency and a dynamic update interface is reserved. Protocol parsing logic corresponding to the heterogeneous driver is established to parse the communication-related data structures initiated by the driver and extract key content such as target service identifier, call number, and data information.

[0033] A hardware resource pool is formed by pre-allocating hardware resources, including GPU context, physical contiguous memory and DMA-BUF channel, for heterogeneous drivers. Independent hardware resource quotas are allocated to heterogeneous drivers in the hardware resource pool.

[0034] To run heterogeneous driver processes, a dedicated kernel scheduling group is allocated, the scheduling priority of the kernel scheduling group is set to a value greater than the threshold, the scheduling policy is preemptive real-time scheduling, and the CPU core affinity of the heterogeneous driver is set according to the type of the heterogeneous driver to bind it to different CPU cores and create an independent memory isolation area for it.

[0035] Scan the system library directory of HarmonyOS to extract the symbol information of the system libraries that heterogeneous drivers depend on. Organize the symbol information according to the symbol name hash method and store it in a fixed-size symbol page managed by the kernel cache. This memory area is the kernel symbol cache. Each symbol record contains a hash value, symbol name, symbol address and type identifier. Establish a symbol index structure for each library to record the symbol hash value and the corresponding storage location to accelerate dynamic linking.

[0036] Among them, the kernel symbol cache preloading and fast retrieval mechanism is the core support for enabling heterogeneous closed-source binary drivers to dynamically link, load without modification, and run with low latency in the target operating system. Its role is to shield the symbol differences between different operating systems, eliminate user-mode symbol resolution overhead, and ensure that external closed-source drivers can correctly, efficiently, and stably complete module loading and dependency binding.

[0037] Step 2, Heterogeneous Driver Loading Stage: HarmonyOS maps the binary files of heterogeneous drivers to the virtual address space of the heterogeneous driver process segment by segment, completing the ELF mapping of heterogeneous drivers.

[0038] During symbol resolution in dynamic linking, a hash value is calculated based on the passed symbol name, the corresponding storage location is quickly located through the symbol index structure, the symbol address is read from the kernel symbol cache and returned to the dynamic linker, and dynamic linking is completed.

[0039] In kernel mode, memory allocation alignment and adaptation for heterogeneous drivers are completed, and a hardware module loading interface is built. The kernel creates hard links in the device directory so that the nodes used by the heterogeneous drivers and the native device nodes of the HarmonyOS system point to the same hardware entity, thus completing the loading of heterogeneous drivers.

[0040] Furthermore, when a system library that a heterogeneous driver depends on is missing, the dynamic linker automatically triggers dependency replacement logic. Specifically, this involves: parsing the dynamic segments of the heterogeneous driver's executable and linkable format (ELF) file to extract the target symbols of the missing dependencies; searching for functionally equivalent compatible symbols in the compatible interface library provided by the HarmonyOS system; and binding the missing symbols of the heterogeneous driver to the compatible symbols through symbol redirection, thereby completing automatic dependency repair and reducing loading failures caused by missing dependencies.

[0041] Because heterogeneous closed-source drivers require memory allocation with a larger alignment granularity by default to meet the requirements of hardware acceleration and dedicated instruction sets, while the HarmonyOS standard library has a smaller default alignment granularity, traditional user-space adaptation requires additional memory allocation and address adjustment, resulting in high performance overhead. Therefore, to address the differences in memory allocation alignment rules between heterogeneous closed-source drivers and HarmonyOS, this invention implements memory allocation alignment adaptation in kernel mode, specifically as follows:

[0042] Create a dedicated memory cache area. The cache blocks in the dedicated memory cache area adopt the alignment granularity required by heterogeneous drivers and cover a variety of commonly used memory allocation specifications.

[0043] Receive the requested memory size from user space, calculate the aligned size according to the alignment granularity of the heterogeneous driver; allocate a cache block of the corresponding size from the dedicated memory cache area, add alignment information marker to the cache block header, and then return the cache block address to user space to implement the kernel-mode memory allocation interface;

[0044] When releasing memory, the address passed in from user mode is restored to the actual cache block address, the header mark of the cache block is read to complete the validity check, and then the cache block is returned to the dedicated memory cache area to complete the release process, so as to realize the kernel-mode memory release interface.

[0045] Furthermore, to ensure compatibility, the system in this invention distinguishes between compatible memory and system native memory by using a special identifier preset in the memory block header; when the system native release interface detects this special identifier, it automatically forwards the execution to the constructed kernel-mode memory release interface to avoid memory leaks and abnormal releases.

[0046] Heterogeneous closed-source drivers use a fixed path to find hardware module libraries, while the HarmonyOS driver library is stored in a different path. Traditional user-space adaptation requires path redirection, resulting in additional performance overhead. To address the differences between heterogeneous closed-source drivers and HarmonyOS in hardware module loading paths and lookup mechanisms, this invention implements a hardware module loading interface in kernel space, specifically:

[0047] The hardware module loading interface receives the module name and a pointer to the module information structure as input parameters. It queries the driver mapping relationship maintained by the device manager in the kernel to obtain the system standard storage path of the corresponding hardware module; it calls the kernel symbol extraction interface to obtain the module entry symbol from the driver library and fill it into the module information structure; after completion, it returns to user space to realize the kernel-level loading of the hardware module.

[0048] To further improve access speed, this invention establishes a node cache for device nodes with access frequency greater than a threshold. The kernel cache corresponds to the inode and file structure, and subsequent accesses can directly reuse the cache.

[0049] Furthermore, in response to the namespace isolation feature of higher version drivers, this invention also supports multi-version dependency environment isolation. Specifically, for the differences in dependency versions of different heterogeneous drivers, the dynamic linker creates independent virtual namespaces for different heterogeneous drivers, realizes the isolated loading of dependency libraries of different heterogeneous drivers, avoids conflicts between different version libraries, and ensures the dependency stability when multiple heterogeneous drivers run in parallel.

[0050] Step 3, Heterogeneous Driver Registration Phase: The heterogeneous driver sends a registration request to the HarmonyOS hardware driver framework using its own communication protocol. This triggers the protocol parsing logic, which parses the protocol header, transaction data, and object data in that order. The external service handle of the heterogeneous driver is converted into a remote object reference recognizable by the HarmonyOS system. Based on the parsed information, a native request structure conforming to the HarmonyOS service framework specification is generated, including service identifier, method number, message carrier, and remote object reference. The HarmonyOS service framework assigns the corresponding target service to the heterogeneous driver, completing the interface between the driver and the system service management framework. The heterogeneous driver's ELF file is parsed, extracting features such as version, hardware type, and security level, and encapsulating them into a feature vector for the heterogeneous driver. Matching performance and security policies are dynamically loaded based on the feature vector, and the policy parameters are injected into the corresponding system modules.

[0051] When multiple heterogeneous drivers compete for the same type of hardware resources, resource arbitration is performed according to driver priority. High-priority drivers are allocated resources first, and a maximum resource occupation time is set to prevent blocking and deadlock caused by resource monopoly.

[0052] For hardware hot-swappable scenarios, the device hot-swappable callback mechanism is extended. A dedicated processing thread listens for device access and removal events. When a device is accessed, the system service management framework queries the matching heterogeneous driver based on the device information, dynamically adds mapping entries to update the service mapping table, completes the registration of the new service, and synchronously notifies the upper-layer application to reinitialize the device. When a device is removed, the system service management framework deregisters the corresponding service, uninstalls the heterogeneous driver, and releases related resources.

[0053] Specifically, the process involves parsing the ELF file of heterogeneous drivers, dynamically loading matching performance and security policies based on feature vectors, and injecting policy parameters into the corresponding system modules. This is achieved by adding a driver version adaptation service to the system services and running it as an independent system service. When a heterogeneous driver is registered and loaded, the driver version adaptation service parses the ELF format file of the heterogeneous driver through the driver file parsing interface, extracts version feature information such as system version, interface level, and build identifier from the driver's built-in segments, as well as hardware feature information such as hardware type, hardware capability requirements, and security level requirements, and encapsulates the above information into a unified driver feature vector.

[0054] Based on the driver feature vector, the matching performance adaptation policy and security operation policy are loaded from the system policy configuration directory. The performance adaptation policy includes parameters such as the number of pre-allocated frame buffers, data format configuration, and hardware operating frequency lower limit. The security policy includes configurations such as security domain labels, trusted execution environment enabling requirements, and system permission requirements. The policy parameters are injected into the corresponding system modules, the performance parameters are injected into the hardware rendering and driver management modules, and the security parameters are injected into the security management module and trusted environment proxy module.

[0055] Different systems have different default alignment granularities in their memory allocation functions. Heterogeneous drivers usually need to use larger alignment values ​​to meet the requirements of hardware acceleration and instruction sets. Traditional user-mode adaptation requires additional memory operations, which has a high overhead.

[0056] Step 4, Heterogeneous driver execution phase: When a heterogeneous driver initiates a service call, the kernel checks the execution permissions of the heterogeneous driver process through the system security management interface, and verifies the access permission matching between the heterogeneous driver process and the target service by combining the system's native security label verification mechanism. If the heterogeneous driver's permissions are missing or exceed the resource quota, the call request is rejected; otherwise, the call is allowed.

[0057] For the security-sensitive hardware, the system service management framework calls the Trusted Execution Environment (TEE) related services to initialize a trusted session for the corresponding heterogeneous driver and build a trusted verification environment. When the heterogeneous driver calls the set operation, the TEE trusted verification process is triggered to verify the legitimacy of the heterogeneous driver's trusted certificate. After the verification is passed, the heterogeneous driver is allowed to access the set hardware resources, and the relevant data is stored in the trusted memory area after the verification is passed.

[0058] When heterogeneous drivers perform large data transfers, they request shared memory from the kernel within their own resource quota and obtain the corresponding file descriptor (FD). The system service management framework calls the kernel memory mapping interface to map the shared memory to the address space of the target service, and adopts a shared mapping and memory page locking strategy. A kernel-level synchronization lock mechanism is used instead of traditional semaphores. Both the heterogeneous driver acquiring the lock and the target service releasing the lock are completed by kernel system calls.

[0059] Specifically, shared mapping ensures that multiple processes can share the memory region, and data written by heterogeneous drivers can be directly recognized by the target service without additional data synchronization operations; memory page locking prevents memory from being swapped to disk, significantly reducing memory access latency. After mapping is completed, the system service management framework passes the mapped virtual address to the target service, which can directly operate on this address to complete data reading without data copying through read and write operations, achieving zero-copy transmission.

[0060] Furthermore, this invention adds a check and verification mechanism to the big data transmission. The heterogeneous driver adds check information to the end of the shared memory. After the target service receives the data, it performs the verification to ensure the integrity of the data during cross-process transmission. The verification operation time is controlled within a very low range and does not affect the overall transmission performance.

[0061] This invention significantly reduces the time consumption of cross-process transmission of big data and significantly improves the transmission throughput through memory mapping and synchronization optimization, which can meet the needs of high frame rate and large capacity data transmission scenarios, and thus ensure the stable operation of heterogeneous closed-source drivers in big data interaction scenarios.

[0062] Furthermore, during the heterogeneous driver runtime phase, for graphics-related heterogeneous drivers, the interface is redefined to achieve interfacing with the system hardware driver framework's graphics driver. Combined with graphics context priority scheduling, frame buffer sharing, and end-to-end optimization of multimedia decoding and rendering, hardware rendering performance is released and rendering latency is reduced to meet the needs of various graphics rendering scenarios. The specific process includes:

[0063] After receiving the display parameters, the heterogeneous driver first obtains the device handle of the system hardware driver framework's graphics driver, reads the core display-related parameters including resolution, refresh rate, pixel format, display controller identifier, etc., and encapsulates the device handle and display parameters before returning it to the heterogeneous driver. For the graphics context creation interface, it parses the configuration attributes passed in by the interface, extracts key information such as context version, priority, and debug flag, converts them into configuration parameters that the system hardware driver framework's graphics driver can recognize, calls the graphics driver interface to create a hardware context and obtains the handle, and then encapsulates it before returning it to the heterogeneous driver.

[0064] A new context scheduling module is added to the graphics driver within the system hardware driver framework. Based on the application scenarios of heterogeneous graphics drivers, different priorities are assigned: high priority is allocated to latency-sensitive drivers, medium priority to drivers requiring stable frame rates, and low priority to latency-insensitive drivers. During scheduling, high-priority contexts can preempt the unlocked resources of low-priority contexts. A time-slice round-robin mechanism is used to limit the maximum duration of a single high-priority context's occupation, preventing resource monopoly. During context switching, a cache preloading mechanism is used to load the texture data of the next context into the graphics cache in advance, reducing switching overhead and improving cache hit rate.

[0065] Regarding frame buffer sharing, the system display service is integrated to achieve zero-copy sharing between the graphics buffer of the heterogeneous graphics driver and the system's native buffer. When the driver creates a rendering surface, the system directly allocates a buffer managed by the hardware driver framework and adds a compatibility identifier for the driver to recognize. When the driver creates a graphics image, it directly binds to the physical memory address of the buffer without format conversion. During buffer synchronization, when the driver submits a rendering frame, the system generates a synchronization signal object and passes it to the driver. The driver ensures that the buffer is safe to access by waiting for the synchronization signal, which greatly reduces synchronization time and avoids multi-threaded resource contention.

[0066] For heterogeneous drivers of multimedia decoding, in the format conversion stage, the hardware conversion capability of the system hardware driver framework graphics driver is used to directly convert the decoded video frame format into a renderable format, which greatly shortens the conversion time. In the rendering output stage, the frame data rendered by the graphics driver is directly submitted to the display controller to complete the screen output, further reducing the end-to-end process time.

[0067] Furthermore, for high-resolution video decoding and rendering scenarios, large pages of memory are allocated to video frames to reduce memory address translation errors and improve memory access efficiency. The frame compression function of the graphics driver is enabled, significantly reducing the memory footprint of high-resolution video frames and minimizing memory bandwidth consumption. Through these optimizations, the high-resolution video decoding frame rate is significantly improved, and the end-to-end decoding and rendering time is greatly shortened, meeting the performance requirements of high-resolution video playback. After overall optimization, the rendering latency, interface call time, and end-to-end process time of heterogeneous drivers for graphics and multimedia decoding are significantly reduced, while cache hit rate and memory access efficiency are significantly improved, stably meeting the needs of various graphics rendering and high-resolution multimedia playback scenarios.

[0068] Furthermore, during the heterogeneous driver operation phase, to ensure the stable and efficient operation of the heterogeneous driver under different load scenarios, this invention optimizes resource allocation strategies in real time to address load changes and performance fluctuations during driver operation, promptly handles performance anomalies and faults, and ensures operational stability under high load scenarios. Specifically, this includes:

[0069] A new heterogeneous driver performance monitoring module has been added to the system monitoring service. Running in the system's core process, it enables real-time collection, storage, log output, and alarm generation of multi-dimensional metrics. The monitoring module collects multi-dimensional core metrics at a high sampling frequency, covering two main categories: hardware load and software calls. Hardware load metrics include graphics driver utilization, graphics rendering frame latency, memory page miss rate, and data transmission channel utilization, all with clearly defined operating thresholds. Software call metrics include cross-process call latency, system call latency, and driver function call frequency, ensuring comprehensive coverage of the entire driver runtime performance status. Monitoring data is stored using a circular buffer and memory-mapped files. The circular buffer stores recent real-time metric data and supports fast querying, while the memory-mapped files periodically store historical data, supporting historical data backtracking for a certain period. Simultaneously, real-time monitoring information is output through system logs. When a metric exceeds a preset threshold multiple times consecutively, a system alarm is triggered, sending a notification and recording detailed alarm logs.

[0070] Furthermore, this invention constructs a performance scheduler for heterogeneous drivers, running in the system's core process. Based on collected real-time metrics, it automatically triggers dynamic scheduling strategies to achieve precise resource allocation and efficient utilization. Specifically, the dynamic scheduling strategies are as follows: when driver CPU utilization remains consistently high, the process scheduling strategy is switched and CPU core affinity is adjusted, binding different types of heterogeneous drivers to CPU cores of corresponding performance levels; when the memory page miss rate exceeds a threshold for a set period, large page memory is enabled for heterogeneous driver large memory allocation scenarios; when the graphics rendering frame latency exceeds a threshold for a set period, the graphics driver frequency and voltage are dynamically adjusted to improve performance while meeting temperature thresholds; and when the data transmission channel utilization is too high, the data transmission channel is dynamically expanded. Through these dynamic scheduling strategies, resource allocation can be optimized in real-time according to changes in driver load, significantly improving driver performance and stability.

[0071] Furthermore, to address various performance anomalies and faults during the operation of heterogeneous drivers, this invention implements a fault self-healing mechanism for rapid location, emergency repair, and automatic rollback, ensuring rapid fault resolution without noticeable impact on the user. Specifically, this includes: In the fault location phase, the call stack information of the heterogeneous driver process is obtained through kernel-related mechanisms to identify abnormal functions. Combined with monitoring indicators, the root cause of the fault is determined to identify the fault type, such as insufficient resources or driver loading failure. Corresponding emergency repair operations are performed for different fault types. When resources are insufficient, relevant resources are temporarily expanded, and high-priority drivers are prioritized. When a driver crashes, the driver is automatically unloaded and reloaded, restoring the default configuration. When the tuning strategy is ineffective or a hardware safety threshold is triggered, the system automatically rolls back to the default operating strategy, while adjusting relevant parameters to reduce hardware load, notifying the user of the current operating status, preventing system crashes, and ensuring the stability and reliability of driver operation.

[0072] Example:

[0073] This embodiment takes an Android binary driver as an example, employing a HarmonyOS platform-compatible operation method for heterogeneous closed-source drivers provided by this invention. It achieves low-latency, high-stability, and high-security operation of Android binary drivers, such as core drivers for graphics, multimedia, and camera, on OpenHarmony. This method is suitable for scenarios with stringent hardware performance and security requirements, such as smartphones, in-vehicle terminals, smart TVs, AR and VR devices. The specific process includes:

[0074] S1. Build a high-performance operating environment for Android drivers, providing a runtime platform for Android drivers with resource pre-allocation, security mechanism integration, and dynamic link optimization, avoiding performance loss and security risks caused by insufficient resources, security vulnerabilities, or link delays after driver loading.

[0075] S1.1 Design of Android driver-specific resource domain: In this embodiment, an Android driver resource domain is added to the OpenHarmony process management framework ProcessManager.

[0076] S1.1.1 Hardware resource pre-allocation and kernel-level locking.

[0077] During the system startup phase, specifically the post-fs-data phase executed by the init process, fixed hardware resources are reserved for the resource domain through the kernel resource_reserve interface. The resource list and allocation logic are as follows:

[0078] GPU context: One high-priority context is used for games and AR rendering, and the other low-priority context is used for video decoding and camera preview. It is locked through the GpuContextReserve interface of HDF GPU driver to prevent other processes from occupying it. The context creation time has been reduced from 8ms to 2ms.

[0079] Physical contiguous memory: 256MB, divided into 4 blocks of 64MB each, used for frame buffer, texture buffer, decoded data, and shared memory respectively, allocated through the dma_alloc_coherent interface, reducing memory access latency from 100ns to 50ns;

[0080] DMA-BUF channels: Four channels are built to support zero-copy data transfer between the GPU, camera, video decoder, and display controller. They are reserved through the dma_buf_reserve interface, and the channel switching time is less than 100ns.

[0081] Each Android driver is allocated an independent resource quota within the resource domain. For example, the GPU driver occupies a high-priority context and 64MB of memory, while the camera driver occupies a DMA-BUF channel and 32MB of memory. The upper limit of resource usage is limited through the kernel resource_quota interface to avoid resource abuse by a single driver. For example, OOM protection is triggered when the GPU driver's memory usage exceeds the quota.

[0082] S1.1.2, CPU scheduling priority binding and core affinity.

[0083] Set up a dedicated scheduling group SCHED_ANDROID_HAL for the process running the Android driver. The kernel scheduler uses preemptive real-time scheduling SCHED_FIFO for the processes in this group. The scheduling priority is set to 90. The default priority of the OpenHarmony native process is 50. The CPU response latency is reduced from 10ms to 3ms.

[0084] Configure CPU core affinity based on driver type: bind GPU drivers and game drivers to large cores, and bind video decoders and camera preview drivers to medium cores to avoid cache invalidation and loss due to cross-core scheduling.

[0085] S1.1.3 Multi-driver memory isolation: Create an independent memory isolation zone MAP_PRIVATE | MAP_ANONYMOUS for each Android driver through the kernel mmap interface. The isolation zones are controlled by page table permissions, which allows only the current driver process to read and write, preventing memory out-of-bounds access. When multiple drivers are running concurrently, the memory conflict rate is reduced to below 0.1%.

[0086] Specific example: For the Android Mali-G710 GPU driver in the game scenario, the resource domain allocates a high-priority GPU context value of 1, 64MB of physical contiguous memory, and binds 2 large cores. The game rendering frame time is stable at about 13ms, which is 40% faster than without resource pre-allocation.

[0087] S1.2, Android dynamic linker performance optimization, integrates the native Android linker64 dynamic linker, and makes deep modifications for OpenHarmony.

[0088] S1.2.1 Kernel-level symbol cache preloading and access.

[0089] When the system starts, the init process calls the ohos_sym_cache_init interface to initialize the kernel-level symbol cache: scan the OpenHarmony system library path and extract the symbol tables of high-frequency dependent libraries of the Android driver, such as libc.so, libhdf_gpu.so, and libbionic_compat.so; store the symbol tables in the symbol pages of the kernel slab cache according to the symbol name hash, each page is 4KB and contains 128 symbol entries, the entry structure is {hash: uint32_t, name: char

[32] , addr: void*,type: uint8_t}; create a symbol index page for each library, store the hash value and page offset of all symbols in the library, accelerate symbol lookup, and the binary search time complexity is O (log n);

[0090] When linker64 resolves symbols, it triggers a kernel lookup via syscall(SYS_ohos_sym_cache_lookup, symbol_name):

[0091] The kernel calculates the symbol name hash and traverses the symbol index page to locate the symbol page containing the symbol.

[0092] Extract the symbol address and return it to linker64. Without linker64 needing to traverse the user-space symbol table, the symbol resolution time is reduced from 50μs to 8μs.

[0093] S1.2.2 Automatic dependency conflict repair and version compatibility.

[0094] When the Android driver depends on libcutils.so and liblog.so, which are missing, linker64 automatically triggers the dependency replacement logic:

[0095] Read the .dynamic section of the driver ELF file to obtain the dependency symbols of missing libraries, such as cutils_strdup and __android_log_print;

[0096] Locate the corresponding compatibility symbols in the user-space interface library libbionic_compat.so of the kernel-level bionic compatibility module, such as ohos_cutils_strdup and ohos_android_log_print;

[0097] By redirecting the missing symbols of the driver to compatible symbols, dependency repair takes less than 10μs.

[0098] Linker64 supports different Android versions: For the namespace isolation feature of Android 11+, linker64 creates a virtual namespace android_namespace in OpenHarmony to isolate the dependency libraries of different drivers and avoid version conflicts. For example, driver A depends on libc.so version 2.35 and driver B depends on version 2.37, which can coexist.

[0099] Example: When loading the Android camera driver libcamera_hal.so, it is necessary to parse the symbols hw_get_module and cutils_strdup.

[0100] hw_get_module searches the kernel symbol cache of libbionic_compat.so, taking 7μs;

[0101] The cutils_strdup triggers dependency replacement, which is bound to ohos_cutils_strdup and takes 9μs.

[0102] The overall driver loading time was reduced from 200ms to 80ms, and the startup speed was improved by 60%.

[0103] S1.3, Android driver version adaptation service.

[0104] S1.3.1 Add an Android driver version adaptation service, AndroidHalVersionService, to the OpenHarmony system services, which runs in the system_server process.

[0105] Version feature extraction and analysis:

[0106] When the Android driver registers via HdfAndroidHalRegister, the service calls the ohos_elf_parse interface to parse the driver's ELF file: extracting version information from the .note.android.build section, such as Android 13, API Level 33, Build ID: TQ3A.230901.001; extracting the HAL type and hardware requirements from the .note.android.hal section, such as hal_type: camera, gpu_require: OpenGL ES 3.2, secure_level: high (high security level requires TEE support); and generating a version feature vector {version: 13, api: 33, hal_type: camera, secure_level: high}.

[0107] Dynamic loading of adaptation and security policies:

[0108] Based on the version feature vector, the corresponding performance optimization and security policies are loaded from the path / system / etc / android_hal_policies: Example of a performance optimization policy: {"frame_buffer_prealloc": 3, "format": "YCbCr_420", "gpu_freq_min": 500}, pre-allocates 3 frame buffers, default format YCbCr_420, minimum GPU frequency 500MHz; Example of a security policy: {"selinux_label": "u:r:android_camera_hal:s0", "tee_required": true, "permission": "ohos.permission.CAMERA_SECURE"}, SELinux label, requires TEE environment, secure camera permissions;

[0109] Inject strategy parameters into the corresponding system modules: performance parameters are passed to RenderService and HdfGpuDriver, and security parameters are passed to SecurityManager and TEEProxyService.

[0110] S1.3.2 Performance data: Version feature extraction takes less than 5ms, strategy loading takes less than 15ms, and overall version adaptation takes less than 20ms, which is 5 times faster than static configuration and supports all versions of Android from 8 to 14.

[0111] Security Case: When the Android payment-grade camera driver libsecure_camera_hal.so is loaded, the service loads a high-security policy for it. SecurityManager automatically sets the SELinux label u:r:android_camera_hal:s0 for the driver process. TEEProxyService initializes the TEE session. When the driver accesses the camera sensor, it needs to pass TEE verification to prevent data leakage.

[0112] S2 addresses kernel-level bionic compatibility and system call performance adaptation, resolving core differences between the Android bionic library and the OpenHarmony musl library, as well as compatibility issues between Android-specific system calls and the OpenHarmony kernel. It eliminates the forwarding overhead of user-space adaptation at the kernel level, improving the performance of underlying driver calls.

[0113] S2.1, native implementation of kernel-level bionic functions.

[0114] A new kernel module, bionic_compat, is added to the OpenHarmony kernel and compiled as bionic_compat.ko. It is loaded during the early_init phase and directly implements Android bionic-specific functions by modifying the kernel symbol table and extending the slab allocator.

[0115] S2.1.1 Memory allocation alignment adaptation between bionic malloc and musl malloc.

[0116] Difference Analysis: Android Bionic's malloc is aligned to 16 bytes by default, which meets the requirements of GPU texture memory and SIMD instruction set. OpenHarmony musl's malloc is aligned to 8 bytes by default. Traditional user-space adaptation requires additional memory allocation and address adjustment, and a single call takes more than 20μs.

[0117] Kernel-level implementation scheme:

[0118] Extend the kernel slab allocator to create a dedicated bionic memory cache, bionic_slab_cache, for the bionic_compat module. The cache block size is designed to be aligned to 16 bytes and supports 13 sizes: 16B, 32B, 64B, 128B, 256B, 512B, 1KB, 2KB, 4KB, 8KB, 16KB, 32KB, and 64KB.

[0119] Implementing the kernel system call sys_bionic_malloc (system call number 384) specifically includes:

[0120] Receive the size parameter passed from user space, calculate the size after 16-byte alignment; allocate a cache block of the corresponding size from bionic_slab_cache, and obtain the physical address and virtual address; add an alignment information marker (4 bytes) to the header of the cache block, storing aligned_size - size, for proper release during free; return the address to user space as the virtual address of the cache block and the 4-byte marker, ensuring that the address seen by user space is 16-byte aligned;

[0121] Implement the sys_bionic_free system call (system call number 385): Receive the user-space address, calculate the actual cache block address (block_addr = user_addr - 4); read the header flags to verify the address's validity; return the cache block to bionic_slab_cache to complete the release.

[0122] Compatibility Guarantee: The bionic marker in the memory block header, specifically 0x42494F4E (BION), distinguishes between bionic memory and musl memory. If the bionic marker is detected during a musl_free call, it is automatically forwarded to sys_bionic_free to avoid memory leaks. Performance Data: A single sys_bionic_malloc call takes 5μs, which is 75% faster than user-space adaptation, and memory allocation throughput is improved by 30%.

[0123] S2.1.2, Bionic logging function implementation: android_log_print vs OH_LOG.

[0124] Difference Analysis: Android's `android_log_print` supports log levels and tags, while OpenHarmony's `OH_LOG` requires level and format conversion. Traditional user-space adaptation needs to forward to `OH_LOG_Print`, a process that takes 15μs. Log levels include DEBUG, INFO, WARN, and ERROR.

[0125] Kernel-level implementation scheme:

[0126] Implement the kernel system call sys_android_log_print (system call number 386), which accepts parameters including log level, label, format string, and variable arguments; add a log level mapping table to the kernel.

[0127] The kernel printk interface is called to output logs in the format [Android-HAL] [Tag] [Level] log content, without the need for user-space forwarding; performance data: sys_android_log_print takes 3μs per call, which is 80% faster than user-space adaptation, and the log output throughput is increased by 4 times.

[0128] S2.1.3, the bionic hardware module loading function implementation hw_get_module, is the key function for loading the driver.

[0129] Difference analysis: Android's hw_get_module searches for the HAL library through the path / vendor / lib / hw, while OpenHarmony's HDF driver library is located at / system / lib / hdf / android. Traditional adaptation requires path redirection, which will take 20μs.

[0130] Kernel-level implementation scheme:

[0131] The kernel system call `sys_hw_get_module` (system call number 387) is implemented, receiving the module name and a pointer to module information `hw_module_t*` as parameters. The kernel queries the Android driver mapping table in the HDF device manager to obtain the HDF driver library path corresponding to the module, such as ` / system / lib / hdf / android / libcamera_hal.so`. The kernel dlsym interface `kernel_dlsym` is called to extract the `HAL_MODULE_INFO_SYM` symbol from the driver library and populate it into the `hw_module_t` structure. The process returns to user space, completing the module loading.

[0132] Performance data: The single call to sys_hw_get_module takes 8μs, which is 60% faster than the user-space adaptation, and the module loading speed is improved by 2.5 times.

[0133] S2.2 Kernel-level simulation of Android-specific system calls: Extends the OpenHarmony kernel system call table sys_call_table to provide low-latency simulation of Linux-specific system calls that Android depends on, such as timerfd_create, epoll_pwait2, and inotify_init1.

[0134] S2.2.1, timerfd_create simulation, Android multimedia driver dependency.

[0135] Difference Analysis: Android multimedia drivers such as libstagefright.so rely on timerfd_create to implement timed decoding. The OpenHarmony kernel does not have this system call. Traditional user-space combined calls to ohos_timer_create and eventfd take more than 10μs.

[0136] Kernel-level simulation solution:

[0137] A new system call, sys_timerfd_create (system call number 388), has been added. Parameters include clock type CLOCK_MONOTONIC or CLOCK_REALTIME and flags TFD_NONBLOCK or TFD_CLOEXEC. The simulation process is as follows: Initialize the high-precision timer hrtimer by calling the kernel hrtimer_init interface, with the clock type set according to the parameters and a precision of 1ms; create an event file descriptor eventfd by calling the kernel eventfd_create interface for timer timeout notifications; bind hrtimer to eventfd and register the timeout callback function timerfd_timeout_handler; the callback function writes the timeout count to eventfd via eventfd_signal, triggering a user-space readable event; and add system calls sys_timerfd_settime (system call number 389) and sys_timerfd_gettime (system call number 390) to set timer parameters and retrieve remaining time, respectively, fully compatible with the Linux interface.

[0138] Performance data: The single call to sys_timerfd_create takes 2μs, which is 80% faster than user-mode combined calls, and the timer precision error is <100μs.

[0139] S2.2.2, epoll_ctl parameter correction, Android network driver dependency:

[0140] Difference analysis: The epoll_ctl call in the Android driver contains the EPOLLWAKEUP flag to wake up a sleeping process. The OpenHarmony kernel does not have this flag. Traditional user-mode adaptation requires interception and correction, which takes 8μs.

[0141] Kernel-level fixes:

[0142] Add parameter correction logic to the entry function of the sys_epoll_ctl system call: extract the events field from the epoll_event structure; if the EPOLLWAKEUP flag is detected, replace it with the OpenHarmony OHOS_EPOLL_WAKE flag value of 0x80000000; clear the EPOLLWAKEUP flag and execute the original epoll_ctl logic; the correction takes less than 1μs and requires no user-space intervention.

[0143] Specific example: When the Android network driver libnet_hal.so calls epoll_ctl(epfd, EPOLL_CTL_ADD, sockfd, &event) (event.events = EPOLLIN | EPOLLWAKEUP), the kernel automatically replaces EPOLLWAKEUP with OHOS_EPOLL_WAKE, reducing the call time from 10μs to 3μs.

[0144] S2.3, User-space - Kernel-space lightweight interface library libbionic_compat.so.

[0145] The libbionic_compat.so user-space interface library was developed, occupying less than 10KB of memory. It only contains kernel system call encapsulations and has no additional adaptation logic. The core interface implementation includes:

[0146] malloc package:

[0147] void* malloc(size_t size) {

[0148] return syscall(SYS_bionic_malloc, size); / / Directly triggers a kernel system call

[0149] }

[0150] android_log_print wrapper:

[0151] int android_log_print(int prio,const char* tag, const char* fmt, ...){

[0152] va_list args;

[0153] va_start(args, fmt);

[0154] int ret = syscall(SYS_android_log_print, prio, tag, fmt, args);

[0155] va_end(args);

[0156] return ret;

[0157] }

[0158] hw_get_module wrapper:

[0159] int hw_get_module(const char* id, const struct hw_module_t** module){

[0160] return syscall(SYS_hw_get_module, id, module);

[0161] }

[0162] Library compilation and deployment: Compile via OpenHarmony BUILD.gn and deploy to the / system / lib path. Dependencies of Android drivers, such as libcutils.so, can be automatically linked via linker64, with a loading time of less than 5ms.

[0163] Specific example: When the Android GPU driver calls malloc(1024), it directly triggers sys_bionic_malloc through libbionic_compat.so. There is no user-space logic throughout the process, and the time taken for a single memory allocation is stable at around 5μs, which is 75% faster than the user-space adaptation of libhybris.

[0164] S3 natively loads Android binary drivers using HDF, extending the OpenHarmony HDF framework to achieve zero-modification loading of Android drivers, automatic dependency resolution, multi-driver concurrency isolation, and hot-plug adaptation. This reduces driver loading time, resolves multi-driver concurrency resource conflicts, and improves hardware plug-and-play performance.

[0165] S3.1, HDF-Android driver adaptation layer implementation, including driver encapsulation and dependencies, adds an Android driver adaptation layer HdfAndroidHalAdaptor to the HDF framework, which is integrated into the HDF device manager hdf_device_manager.

[0166] S3.1.1 Driver Descriptor Extension and Android Driver Encapsulation.

[0167] Modify the HDF's HdfDriverDescriptor structure, which is defined in hdf_device_descriptor.h, and add a new android_hal_attr field. The data structure is as follows:

[0168] struct AndroidHalAttr {

[0169] const char* hal_type; / / Android HAL type, such as camera, GPU

[0170] const char* entry_sym; / / Entry symbol, such as HAL_MODULE_INFO_SYM

[0171] const char** deps_libs; / / List of dependency libraries, such as ["libhdf_gpu.so", "libbionic_compat.so"]

[0172] uint32_t resource_quota; / / Resource quota (MB)

[0173] uint8_t priority; / / Driver priority, 1 for high, 2 for medium, 3 for low

[0174] bool need_tee; / / Whether TEE support is needed

[0175] };

[0176] Android drivers are registered via the HdfAndroidHalRegister interface, and the adaptation layer automatically completes the encapsulation:

[0177] The `hdf_dlopen` function loads Android driver libraries such as `libcamera_hal.so`.

[0178] Call hdf_dlsym to extract the entry function HAL_MODULE_INFO_SYM corresponding to entry_sym;

[0179] Parse the deps_libs list and automatically load missing dependency libraries such as libhdf_gpu.so using hdf_dlopen;

[0180] Create an HDF driver object HdfDeviceObject and bind android_hal_attr to the entry function;

[0181] Calling HdfDeviceManager::AddDevice registers the driver to HDF, completing the encapsulation;

[0182] S3.1.2 Dependency conflict detection and automatic repair.

[0183] The adaptation layer detects version conflicts through the dependency library version database / system / etc / hdf_deps_versions.db. The database records the version information of the OpenHarmony library, such as libhdf_gpu.so version 2.1.0, and the list of supported interfaces. If the version of the library that the Android driver depends on is lower than the current system version, such as the driver depends on libhdf_gpu.so 1.0.0, while the system version is 2.1.0, the adaptation layer automatically loads the version compatibility plugin, such as libhdf_gpu_compat_1.0.so, to provide compatibility with the old interfaces.

[0184] Example: The Android 11 camera driver depends on libhdf_gpu.so 1.0.0, while the OpenHarmony system is version 2.1.0. The adaptation layer loads libhdf_gpu_compat_1.0.so, mapping the GpuCreateContextV1 interface of version 1.0 to the GpuCreateContext of version 2.1. The dependency fix takes less than 15ms.

[0185] Android driver registration time has been reduced from 500ms to 100ms, which is 80% faster than libhybris driver loading; dependency conflict resolution time is less than 20ms, which is 10 times faster than manual configuration.

[0186] S3.2, Automatic mapping of Android standard device nodes.

[0187] The device node naming convention for OpenHarmony HDF is / dev / hdf / <device_type> / <id>For example, / dev / hdf / camera / 0, while the Android driver depends on standard nodes such as / dev / video0 and / dev / graphics / fb0. Traditional adaptation requires mount -bind, which takes 20ms. This embodiment achieves zero-latency mapping through kernel-level symbolic links.

[0188] S3.2.1 Kernel-level symbolic link creation and permission synchronization.

[0189] During HDF driver initialization, the adapter layer calls the hdf_devnode_create_symlink interface, triggering the kernel vfs_symlink system call:

[0190] The parameters include the target node / dev / hdf / camera / 0, the link node / dev / video0, and permissions 0666. The kernel creates a symbolic link in the / dev directory. The link type is a hard link to avoid the path resolution overhead of soft links. The link creation time is less than 1ms.

[0191] Automatic permission synchronization mechanism:

[0192] The HDF driver's permission configuration is stored in the i_mode field of the inode structure;

[0193] Symbolic link inodes directly reuse the target node's i_mode through permission inheritance, without requiring additional chmod operations;

[0194] S3.2.2 Node access performance optimization.

[0195] When the Android driver accesses the device via open( / dev / video0, O_RDWR), the kernel VFS layer directly resolves the path to / dev / hdf / camera / 0, without traversing the directory entry dentry, reducing the device opening time from 30ms to 5ms;

[0196] For frequently accessed nodes, such as / dev / video0 and / dev / graphics / fb0, a node cache is created. The kernel VFS layer caches the inode and file structure of this node, and subsequent open operations directly reuse the cache, further reducing the time to 2ms.

[0197] Specific example: When the Android camera driver libcamera_hal.so accesses / dev / video0, the kernel VFS directly resolves it to / dev / hdf / camera / 0, and the open call takes 5ms, which is 83% faster than the mount --bind method; for 10 consecutive open operations, due to the existence of node caching, the average time is reduced to 2ms.

[0198] S3.3, concurrent resource isolation and hot-swappable adaptation for multiple Android drivers.

[0199] S3.3.1, Multi-Driver Concurrent Resource Isolation:

[0200] The adaptation layer allocates an independent resource isolation unit for each Android driver, including: an independent HDF device context HdfDeviceContext to store driver-private data, such as camera parameters and GPU texture handles; dedicated resource quotas, such as one context and 64MB of memory for the GPU driver, and one DMA-BUF channel and 32MB of memory for the camera driver; and a memory isolation area based on the kernel mmap MAP_PRIVATE flag to prevent memory overflow by multiple drivers.

[0201] Resource scheduling arbitration:

[0202] When multiple drivers simultaneously request the same type of resource, such as GPU texture units, the adaptation layer arbitrates according to driver priority: high-priority drivers, such as games, acquire resources first, while low-priority drivers, such as camera previews, enter a waiting queue and are blocked by the condition variable pthread_cond_t, and are woken up after the resource is released;

[0203] To prevent high-priority drivers from monopolizing resources, the adaptation layer sets a maximum resource occupancy time, such as a maximum GPU context occupancy of 100ms. After the timeout, the resources are automatically released and allocated to low-priority drivers in the waiting queue.

[0204] S3.3.2 Real-time loading optimization for hot-swappable drivers.

[0205] The hot-plug callback mechanism of HDF is extended by adding a new Android driver hot-plug handling thread, which runs in the hdf_device_manager process. The process is as follows:

[0206] When external Android-compatible hardware such as a USB camera or HDMI display is connected, HDF triggers the HDF_DEVICE_ADDED event to transmit device information, including type, manufacturer ID, and product ID.

[0207] The processing thread calls the HdfAndroidHalQuery interface to query the / system / etc / android_hal_hotplug.db database to obtain the Android driver information for the new device, such as the driver library path / system / lib / hdf / android / libusb_camera_hal.so and the entry symbol HAL_MODULE_INFO_SYM;

[0208] Call HdfAndroidHalRegister to load the driver and automatically create device nodes, such as / dev / video1;

[0209] The AndroidHalVersionService notifies Android application processes, such as the camera app, to trigger the hal_device_reopen interface to reinitialize the device.

[0210] If the device is unplugged, the HDF_DEVICE_REMOVED event is triggered. The processing thread calls HdfAndroidHalUnregister to uninstall the driver, delete the device node, and release resources.

[0211] Performance data: The hot-plug driver takes less than 300ms from detection to loading completion, which is 40% faster than libhybris' hot-plug mechanism; the resource conflict rate is reduced to below 0.1% when multiple drivers are running concurrently, and the deadlock rate is 0.

[0212] S4 and SAMGR-Binder native protocol bridging resolve the differences in IPC protocols between Android Binder and OpenHarmony SAMGR. By natively parsing the Binder protocol and performing kernel-level security verification through SAMGR, it eliminates intermediate layer forwarding, reduces cross-process call latency, and integrates OpenHarmony security mechanisms.

[0213] S4.1 and SAMGR's native Binder protocol parsing module.

[0214] A new Binder Protocol Parser module, BinderProtocolParser, is added to the system_server process running the SAMGR service in OpenHarmony.

[0215] S4.1.1, Binder protocol stack integration and data structure parsing.

[0216] The core parsing logic of the Android Binder protocol is integrated into SAMGR based on Android 13 binder.h, supporting the parsing of key data structures such as binder_transaction_data, flat_binder_object, and binder_ptr_cookie.

[0217] binder_transaction_data parsing: Extracts the target service handle target, method number code, transaction flags flags, data length data_size, and data buffer pointer data.ptr.buffer; flat_binder_object parsing: Distinguishes between object types BINDER_TYPE_BINDER, BINDER_TYPE_HANDLE, or BINDER_TYPE_FD, and converts the service handle handle to a SAMGR RemoteObject reference.

[0218] Protocol parsing process:

[0219] The Android driver sends a Binder request via ioctl(fd, BINDER_WRITE_READ, &bwr). The OpenHarmony kernel adds a / dev / binder device driver that forwards the request to BinderProtocolParser.

[0220] The parsing module parses the request in the order from protocol header to transaction data and then to object data, generating a SAMGR request structure SamgrRequest. SamgrRequest contains the target service ID serviceId, the method number funcId, the MessageParcel object parcel, and the RemoteObject reference remoteObj.

[0221] S4.1.2 Dynamic generation and caching of service mapping tables.

[0222] When SAMGR starts, the mapping rules from Android service names to SAMGR service IDs are configured in / system / etc / samgr_binder_map.json and an automatic mapping table is generated.

[0223] {

[0224] "android_services": [

[0225] {

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

[0227] "samgr_service_id": "camera_service",

[0228] "func_map": {

[0229] "openCamera": 1,

[0230] "closeCamera": 2,

[0231] "startPreview": 3

[0232] }

[0233] },

[0234] {

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

[0236] "samgr_service_id": "audio_service",

[0237] "func_map": {

[0238] "openMicrophone": 1,

[0239] "closeMicrophone": 2

[0240] }

[0241] } ]

[0243] }

[0244] The service cache of the mapping table in SAMGR is implemented based on lru_cache, which reduces the service lookup time from 10μs to 2μs; it supports dynamic updates. When a new service is registered to SAMGR, such as a hot-plug camera service, the mapping table is automatically added with a new entry without restarting SAMGR.

[0245] Specific example: When the Android audio driver libaudio_hal.so calls the openMicrophone method of IAudioService, the Binder request contains target=1 as the service handle, code=1 as the method number, and data=microphone ID; the parsing module maps target=1 to samgr_service_id=audio_service and code=1 to funcId=1; it generates SamgrRequest and sends it to the SAMGR audio service, reducing the protocol parsing time from 15μs to 3μs.

[0246] S4.2, Zero-copy cross-process data transfer, for large data transfer scenarios in Android drivers, such as camera preview streams, 4K video frames, and game texture data, implements direct memory mapping to avoid copying user-space data.

[0247] S4.2.1, Shared Memory Creation and Mapping.

[0248] The Android driver passes the shared memory file descriptor (fd) through binder_transaction_data and obtains the DMA-BUF file descriptor (fd) through dup;

[0249] SAMGR calls the kernel mmap interface to directly map the shared memory to the address space of the target service. MAP_SHARED | MAP_LOCKED: MAP_SHARED means that multiple processes can share this memory, and the data written by the driver is directly visible to the service; MAP_LOCKED locks the memory page to prevent it from being swapped to disk, and the memory access latency is reduced from 100ns to 50ns.

[0250] After the mapping is complete, SAMGR passes the mapped virtual address to the target service, which can then directly operate on that address without needing to perform read / write copying.

[0251] S4.2.2 Synchronization mechanism optimization.

[0252] The kernel-level DistributedMutex implemented by OpenHarmony based on futex is used to replace the Android Binder semaphore: When the Android driver acquires the lock, it calls the sys_futex system call FUTEX_LOCK_PI, which takes 2μs; when the service releases the lock, it calls FUTEX_UNLOCK_PI, and the driver directly accesses memory after being woken up.

[0253] Add checksum verification for large data transmission: The driver adds a CRC32 checksum to the end of the shared memory, which is verified by the service after receiving the data to ensure data integrity. The verification time is less than 100μs.

[0254] Performance data: The cross-process transmission time of the 1MB camera preview stream was reduced from 2ms to 0.3ms, and the data transmission throughput was increased by 567%; the transmission time of 4K video frames was reduced from 30ms to 4.5ms, meeting the requirements of 60FPS video transmission.

[0255] S4.3, Native Integration of Security Mechanisms. Traditional libhybris's permission verification relies on user-space mapping and does not integrate OpenHarmony's SELinux and TEE mechanisms. This embodiment integrates security verification into the kernel and SAMGR.

[0256] S4.3.1 Kernel-level permission verification: Add permission verification logic to the OpenHarmony kernel binder driver:

[0257] When an Android driver initiates a Binder call, the kernel checks the OpenHarmony capabilities of its process, such as ohos.permission.CAMERA, through the security_check_capability interface, the SecurityManager kernel interface.

[0258] Capability verification verifies SELinux tags, such as whether the driver process tag u:r:android_camera_hal:s0 is allowed to access the service tag u:r:samgr_camera:s0, through the kernel's selinux_check_access interface.

[0259] The verification takes less than 1μs, and BR_PERMISSION_DENIED is returned directly when permissions are missing, without the need for user-space interception.

[0260] S4.3.2, TEE Trusted Environment Integration.

[0261] For sensitive hardware drivers, such as payment-grade cameras and fingerprint sensors, SAMGR calls TEEProxyService to initialize the TEE session:

[0262] When the Android driver calls sensitive methods such as captureSecureImage, SAMGR triggers TEE verification through the tee_invoke_command interface.

[0263] The trusted certificate for the TEE verification driver is stored in / system / etc / tee_certs. Once verified, it allows access to the hardware, preventing malicious drivers from forging data.

[0264] Specific example: When the Android payment-level camera driver calls captureSecureImage, the TEE verifies the validity period and signature of the driver certificate. After successful verification, the security mode of the camera sensor is unlocked, and the captured image is directly stored in the TEE memory and cannot be accessed by the user space, thus ensuring payment security.

[0265] Performance data: Kernel-level permission verification takes less than 1μs, which is 10 times faster than libhybris's user-space adaptation; TEE verification takes less than 50μs, meeting real-time requirements.

[0266] S5, EGL-HDF direct connection and graphics rendering performance optimization: For Android graphics drivers, GPU, multimedia decoding, and game drivers, through direct connection between EGL and HDF GPU, GPU context priority scheduling, and frame buffer sharing optimization, hardware rendering performance is released and rendering latency is reduced.

[0267] S5.1, Redefining the EGL interface for Android graphics driver.

[0268] Modify the underlying source code of Android graphics drivers, such as the Qualcomm Adreno 740 driver and the ARM Mali-G720 driver, and redefine their EGL interface so that they can directly call the HDF GPU driver and skip the OpenHarmony RenderService intermediate layer.

[0269] S5.1.1, eglGetDisplay direct connection implementation.

[0270] Difference Analysis: The traditional adaptation of Android GPU driver eglGetDisplay requires forwarding to RenderService through libhybris, while this embodiment directly interfaces with HDF GPU;

[0271] Direct connection process:

[0272] Rewrite the eglGetDisplay interface with the parameter EGL_DEFAULT_DISPLAY;

[0273] Calling the HdfDeviceOpen(gpu) interface to obtain the HDF GPU device handle HdfDeviceObject* takes less than 1ms;

[0274] Call the GpuGetDisplayInfo interface of the HDF GPU driver to obtain display parameters:

[0275] Resolution, such as 1920×1080, 3840×2160;

[0276] Refresh rate, such as 60Hz, 120Hz;

[0277] Pixel formats, such as RGBA_8888 and XRGB_8888;

[0278] Display controller ID, such as DSI0, HDMI0;

[0279] The device handle and display parameters are encapsulated into an EGLDisplay, with the structure {hdfDev:HdfDeviceObject*, info: GpuDisplayInfo}, and returned to the driver.

[0280] Performance data: The time taken for eglGetDisplay calls has been reduced from 10ms to 1ms, which is 90% faster than intermediate layer forwarding.

[0281] S5.1.2, eglCreateContext hardware direct connection.

[0282] Difference Analysis: Traditional Android EGL context creation requires forwarding to RenderService, while this embodiment directly calls the HDF GPU driver to create the hardware context;

[0283] Direct connection process:

[0284] Override the eglCreateContext interface with parameters dpy (EGLDisplay), config (EGL configuration), share_ctx (shared context), and attrib_list (attribute list).

[0285] Parse attrib_list and extract key attributes:

[0286] EGL_CONTEXT_CLIENT_VERSION, such as 3, corresponds to OpenGL ES 3.0;

[0287] EGL_CONTEXT_PRIORITY_LEVEL_IMG, such as 1, indicates high priority;

[0288] EGL_CONTEXT_FLAGS_KHR, EGL_CONTEXT_OPENGL_DEBUG_BIT_KHR;

[0289] Convert the attributes into HDF GPU configuration parameters:

[0290] GPU_CONTEXT_VERSION=3;

[0291] GPU_CONTEXT_PRIORITY=1;

[0292] GPU_CONTEXT_FLAGS=GPU_CONTEXT_DEBUG;

[0293] Call the GpuCreateContext interface of the HDF GPU driver to create a hardware context and obtain the context handle GpuContextHandle;

[0294] The context handle is encapsulated as an EGLContext and returned to the driver.

[0295] Performance data: The time taken for eglCreateContext calls has been reduced from 8ms to 2ms, which is 75% faster than intermediate layer forwarding; the time taken for context switching has been reduced from 5ms to 1ms.

[0296] S5.2, GPU context priority scheduling and frame buffer sharing.

[0297] S5.2.1 Implementation of GPU context priority scheduling mechanism.

[0298] The HDF GPU driver adds a new context scheduling module, GpuContextScheduler, which assigns priorities based on the Android driver type.

[0299] High priority, i.e., level 1: Game drivers, AR and VR drivers, which require low-latency rendering;

[0300] Medium priority, i.e., level 2: video decoding driver and live streaming driver, requiring a stable frame rate;

[0301] Low priority, i.e., level 3: camera preview driver, desktop widget driver, which are not sensitive to latency.

[0302] Scheduling strategy:

[0303] High-priority contexts can preempt the unlocked resources of low-priority contexts, such as idle texture units and vertex buffers; a time-slice round-robin mechanism is adopted: the maximum time a high-priority context occupies at one time is 100ms, and the resources are automatically released after the timeout and allocated to low-priority contexts in the waiting queue; when switching contexts, cache preloading is used, that is, the texture data of the next context is loaded into the GPU cache in advance, reducing switching overhead, and the L2 cache hit rate is improved from 60% to 85%.

[0304] Native frame buffer sharing mechanism:

[0305] The SurfaceFlinger service, integrated into OpenHarmony, enables zero-copy sharing between the Android graphics buffer and the OpenHarmony SurfaceBuffer: When the Android driver calls eglCreateWindowSurface to create the rendering surface, SurfaceFlinger directly allocates the SurfaceBuffer managed by HDF, supporting RGBA_8888, YCbCr_420, and RGB_565 formats; an Android compatibility flag ANDROID_BUFFER_FLAG=0x1 is added to the SurfaceBuffer's metadata, which the driver can read through eglQuerySurface; when the driver calls eglCreateImageKHR to create an EGL Image, it directly binds to the SurfaceBuffer's physical memory address without requiring format conversion.

[0306] Buffer synchronization optimization: When eglSwapBuffers is called, SurfaceFlinger generates an OpenHarmony Fence object based on dma_fence and passes it to the driver; the driver waits for the Fence signal to indicate that the buffer is accessible through eglClientWaitSyncKHR, avoiding multi-threaded contention; the Fence signal triggering time is less than 100μs, which is 50% faster than Android's SyncFence.

[0307] Specific example: When the high-priority (level 1) Android game driver libgame_hal.so runs concurrently with the low-priority (level 3) camera preview driver libcamera_hal.so:

[0308] After the game driver occupies the GPU context for 100ms, the scheduling module automatically releases the resources, and the camera preview driver acquires the resources to render the preview frame. The game driver's EGL Image is bound to the physical memory of the SurfaceBuffer, and the rendering frame time is stable at 13ms, while the camera preview frame time is stable at 15ms, with no stuttering.

[0309] S5.3, End-to-end optimization of multimedia decoding and rendering: For Android video decoding drivers, such as libstagefright.so and libmediacodec.so, the end-to-end process from decoding to format conversion to rendering is optimized.

[0310] S5.3.1, Direct rendering of decoded frames.

[0311] The decoded video frames are usually in NV12 format, i.e. YUV 4:2:0, and need to be converted to RGBA format before rendering. Traditional user-space conversion takes 5ms.

[0312] This embodiment implements hardware-level conversion through the GpuConvertFormat interface of the HDF GPU driver:

[0313] The driver stores the decoded NV12 frame in DMA-BUF and passes it to the HDF GPU; GpuConvertFormat calls the GPU's format conversion unit, such as ARM's Texture Filtering Unit, to convert NV12 to RGBA_8888 format; the conversion takes 0.8ms, which is 84% ​​faster than user-space conversion;

[0314] S5.3.2, The rendering result skips the RenderService composition and is output directly.

[0315] Traditional adaptations require passing the rendering results to the RenderService for compositing; this embodiment submits them directly to the display controller.

[0316] After the GPU rendering is complete, the GpuSubmitFrame interface of the HDF GPU driver is called;

[0317] GpuSubmitFrame directly submits frame data to the display controller, such as the frame buffer interface FBI of the DSI or HDMI controller;

[0318] The display controller scans the frame buffer according to the refresh rate to complete the output.

[0319] End-to-end process time: Decoding 5ms + Hardware format conversion 0.8ms + GPU rendering 5ms + Direct output 1.2ms = 12ms, which is 52% faster than the traditional process of 25ms.

[0320] S5.3.3, 4K and 8K video optimization.

[0321] Allocate 2MB of large page memory per page for 4K and 8K video frames to reduce TLB (Translation Lookaside Buffer) failures, increasing TLB hit rate from 70% to 95%.

[0322] Enabling GPU frame compression features such as ARM's Frame Buffer Compression reduces 4K video frame size from 16MB to 4MB, decreasing memory bandwidth usage by 75%.

[0323] Performance data: 4K video decoding frame rate increased from 30FPS to 45FPS, and 8K video decoding frame rate increased from 15FPS to 25FPS, meeting the requirements for high-resolution video playback; end-to-end decoding and rendering time decreased from 25ms to 12ms, which is 52% faster than libhybris.

[0324] S6 features real-time performance monitoring and dynamic scheduling, building a closed loop from real-time monitoring to performance bottleneck identification, dynamic optimization, and fault self-healing. It optimizes resource allocation in real time for load changes and performance fluctuations in Android driver operation, ensuring stability under high load scenarios.

[0325] S6.1, End-to-End Performance Monitoring Module.

[0326] A new Android driver performance monitoring module has been added to the SystemMonitor service in OpenHarmony, running in the system_server process.

[0327] S6.1.1 Multi-dimensional indicator collection, sampling frequency 1ms:

[0328] Hardware load metrics:

[0329] GPU utilization: Collected via the GpuGetUsage interface of the HDF GPU driver, with a target threshold of less than 80%;

[0330] GPU rendering frame time: calculated using timestamps before and after eglSwapBuffers calls, with a target threshold of less than 16ms;

[0331] Page miss rate: Collected via the kernel vm_stat interface, target threshold < 5%;

[0332] DMA-BUF channel utilization: collected via the DmaBufGetUsage interface driven by HDF DMA-BUF, with a target threshold of less than 70%;

[0333] Software usage metrics:

[0334] IPC call latency: collected via SAMGR's GetIpcLatency interface, with a target threshold of less than 2ms;

[0335] System call time: collected via the kernel trace_event interface, such as the time of sys_bionic_malloc, with a target threshold of less than 3μs;

[0336] Driver function call frequency: collected via the perf_event interface, such as the number of eglCreateContext calls per second.

[0337] S6.1.2 Monitoring data storage and query.

[0338] A storage scheme using a circular buffer and memory-mapped files is adopted:

[0339] The circular buffer has a size of 1024 rows, storing the most recent 1024 real-time indicator data, and supports fast querying;

[0340] The memory-mapped file / data / log / android_hal_perf.dat, with a size of 10MB, periodically writes data from the circular buffer to the file, supports historical data backtracking, and retains data from the most recent hour.

[0341] Data structure design: Each indicator data includes a timestamp uint64_t, indicator type uint8_t, value uint64_t, threshold uint64_t, and driver PID uint32_t. The size of a single data is 32 bytes, and 1024 data only occupy 32KB, with extremely low memory usage.

[0342] S6.1.3 Log Output and Alarms:

[0343] Real-time monitoring logs are output via OH_LOG, in the format [YYYY-MM-DD HH:MM:SS.ms] [Android-HAL] [PID:xxx] Metric Name: Value (Threshold:Threshold) [Status]. Example:

[0344] [2024-05-20 14:30:00.123] [Android-HAL] [PID:1234] GPU utilization: 85% (threshold: 80%) [Alert]

[0345] [2024-05-20 14:30:00.124] [Android-HAL] [PID:1234] Rendering frame time: 17ms (threshold: 16ms) [Alert]

[0346] An alarm is triggered when the metric exceeds the threshold three times consecutively.

[0347] Send a system notification via NotificationManager to inform the user that "Android driver performance is abnormal and optimization has been initiated";

[0348] Record alarm logs to / data / log / android_hal_alert.log, including call stack information;

[0349] Performance data: The monitoring module itself has a CPU usage of less than 1% and a memory usage of less than 100KB, which has no impact on system performance; the indicator acquisition accuracy is 1μs, which meets the requirements of real-time monitoring.

[0350] S6.2 Load-based dynamic resource scheduling.

[0351] Develop an Android driver performance scheduler, AndroidHalPerfScheduler, which runs in the system_server process and triggers the following tuning strategies based on monitoring metrics:

[0352] S6.2.1 CPU Scheduling Policy Switching and Core Binding: When the CPU utilization of the Android driver exceeds 70% for three consecutive times:

[0353] Switch the process scheduling policy from preemptive real-time SCHED_FIFO to polling real-time SCHED_RR, and set the time slice to 10ms to avoid a single process monopolizing the CPU.

[0354] Adjust CPU core affinity: bind GPU drivers and game drivers to all large cores such as Cortex-X3, and bind video decoding drivers to medium cores such as Cortex-A715, to reduce cache invalidation in cross-core scheduling;

[0355] CPU response latency decreased from 3ms to 2.4ms, and CPU utilization decreased from 75% to 65%.

[0356] S6.2.2 Memory Page Caching Optimization and Large Page Activation: When the memory page miss rate is greater than 5% for three consecutive times:

[0357] The kernel's vm_cache_shrink interface is called to increase the page cache size of the Android driver process from 2MB to 4MB;

[0358] To drive large memory allocations such as frame buffers and texture buffers, large page memory of 2MB per page is enabled, increasing TLB hit rate from 70% to 95%.

[0359] The memory page miss rate decreased from 6% to below 3%, and the memory access latency decreased from 100ns to 60ns.

[0360] S6.2.3, Dynamic Adjustment of GPU Frequency and Voltage: When the GPU rendering frame time is greater than 16ms for three consecutive times:

[0361] To increase the GPU frequency from 500MHz to 700MHz via the HDF GPU driver's GpuSetFreq interface, the temperature threshold must be less than 85℃.

[0362] If the temperature exceeds 85°C after increasing the frequency, reduce the GPU voltage, such as from 1.2V to 1.1V, to balance performance and power consumption.

[0363] GPU rendering frame time decreased from 17ms to 14ms, and the frame rate increased from 35FPS to 43FPS;

[0364] S6.2.4 Dynamic Expansion of DMA-BUF Channel: When the DMA-BUF channel utilization rate is greater than 70% for three consecutive times:

[0365] Call the DmaBufExpandChannels interface of the HDF DMA-BUF driver to add 2 more DMA-BUF channels, increasing the total from 4 to 6;

[0366] Channel utilization decreased from 75% to 50%, and data transmission latency decreased from 0.3ms to 0.2ms.

[0367] Case Study: Android game driver PID:1234. When running a 3D game, GPU utilization is 85%, rendering frame time is 17ms, and memory page miss rate is 6%.

[0368] The scheduler boosted the GPU frequency to 700MHz, increased the page cache to 4MB, and bound the CPU to the big cores;

[0369] After optimization, the GPU utilization rate was 72%, the rendering frame time was 14ms, the memory page miss rate was 3%, and the game frame rate was increased from 35FPS to 43FPS.

[0370] S6.3, Fault Self-Healing and Performance Rollback: For Android driver performance anomalies, such as frame latency suddenly increasing to 30ms, IPC latency exceeding 10ms, and driver crashes, a fault self-healing mechanism is implemented, from rapid location to emergency repair and then to automatic rollback.

[0371] S6.3.1 Rapid Fault Location:

[0372] The call stack of the driver process is obtained through the kernel unwind interface to identify abnormal functions, such as eglSwapBuffers and hw_get_module.

[0373] Determine the cause of the fault by combining monitoring indicators:

[0374] If eglSwapBuffers consumption suddenly increases and GPU utilization is 100%, it indicates insufficient GPU resources.

[0375] If hw_get_module returns an error and the HDF driver is not registered, the driver loading is considered to have failed.

[0376] S6.3.2 Emergency Resource Expansion and Driver Restart:

[0377] Addressing insufficient GPU resources:

[0378] Temporarily request one additional GPU context, increasing the total from two to three, and allocate it to the current driver;

[0379] Low-priority drivers, such as camera preview, should release resources, while high-priority drivers should be prioritized.

[0380] GPU rendering frame time was reduced from 30ms to 18ms;

[0381] For driver crashes, such as receiving a SIGSEGV signal:

[0382] Call HdfAndroidHalUnregister to uninstall the crashed driver;

[0383] Call HdfAndroidHalRegister to reload the driver and restore the default configuration;

[0384] The driver restart takes less than 500ms, which is imperceptible to the user.

[0385] S6.3.3 Performance rollback mechanism: When tuning strategies are ineffective, such as when the GPU temperature exceeds 90℃ after increasing the GPU frequency or the page miss rate is still greater than 5% after memory expansion:

[0386] Automatically fall back to the default policy: GPU frequency 500MHz, page cache 2MB, CPU scheduling SCHED_FIFO;

[0387] The system notifies the user that "the current hardware load is too high, and the image quality has been reduced to ensure smoothness," such as lowering the game resolution from 1080P to 720P.

[0388] The rollback time is less than 100ms, avoiding system crashes.

[0389] Case Study: When Android video decoding driver PID:5678 was decoding 8K video, the frame rate suddenly increased to 40ms, and the temperature exceeded 90℃.

[0390] The scheduler reverts to the default GPU frequency of 500MHz and reduces the video resolution to 4K;

[0391] After the rollback, the frame rate dropped to 25ms, the temperature dropped to 80℃, and video playback returned to smoothness.

[0392] Experiments have verified that this embodiment has the following technical effects:

[0393] Significantly reduced performance overhead: Through kernel-level adaptation, native protocol parsing, and EGL direct connection, the average call latency of Android drivers is reduced by 60%, with GPU rendering frame time decreasing from 19ms to 13ms and IPC transmission latency decreasing from 2ms to 0.3ms, reaching more than 85% of the performance of OpenHarmony native drivers.

[0394] Significantly improved resource utilization: Real-time performance scheduling increased GPU resource utilization from 60% to 85%, memory page cache hit rate from 85% to 95%, and CPU core load balancing improved by 40%.

[0395] Improved adaptation efficiency and compatibility: HDF native loading and automatic version adaptation shorten the Android driver adaptation cycle from 3 months to 2 weeks, supporting all versions of Android 8 to Android 14, with compatibility covering more than 95% of graphics and multimedia drivers;

[0396] Enhanced stability: The fault self-healing mechanism reduces the Android driver crash recovery time from 5 seconds to 1 second, and the runtime exception rate from 10% to below 2%.

[0397] 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.< / id>

Claims

1. A method for compatible operation of HarmonyOS platform with heterogeneous closed-source drivers, characterized in that, Specifically, the following steps are included: When HarmonyOS starts up, the system service management framework builds a service mapping table between the external services required by heterogeneous drivers and the system's native services, establishes protocol parsing logic, builds a hardware resource pool, and allocates hardware resource quotas. Allocate a dedicated kernel scheduling group to the heterogeneous driver process, set CPU core affinity and bind it to the corresponding CPU core, and create an independent memory isolation zone; store the system library symbol information that the heterogeneous driver depends on to the kernel-level symbol cache, and establish a symbol index structure to record the storage location of the system library. When the heterogeneous driver is loaded, the HarmonyOS system maps its binary file to the virtual address space of the heterogeneous driver process, determines the storage location based on the symbol index structure, and returns it to the dynamic linker; it completes memory allocation alignment and adaptation in kernel mode, and creates hard links in the device directory so that the nodes used by it and the native device nodes of the HarmonyOS system point to the same hardware entity; When a heterogeneous driver registers, it sends a registration request to the HarmonyOS hardware driver framework. The protocol parsing logic completes the parsing, converts the heterogeneous driver's external service handle into a remote object reference, generates a HarmonyOS native request based on the parsing result, triggers the HarmonyOS service framework to allocate the target service for it, and updates the service mapping table. It also parses the heterogeneous driver's ELF file to extract features and obtains feature vectors. Based on the feature vectors, it loads the matching performance and security policies and injects the policy parameters into the corresponding system modules. When a heterogeneous driver initiates a service call, the kernel verifies the running permissions of the heterogeneous driver process and their matching access permissions with the target service. If the verification fails, the call request is rejected; otherwise, the call is allowed. When transferring data, the heterogeneous driver requests DMA-BUF shared memory and obtains a file descriptor within the hardware resource quota. The system service management framework maps this shared memory to the target service address space and uses the kernel synchronization and mutual exclusion mechanism to achieve zero-copy data transfer.

2. The HarmonyOS platform compatible operation method according to claim 1, characterized in that, When a heterogeneous driver is loaded and a missing system library it depends on is detected, the dynamic linker reads the heterogeneous driver's ELF file to extract the missing dependency symbols, searches for functionally equivalent compatible symbols in the system's compatible interface library, and binds the driver's missing symbols to the compatible symbols through symbol redirection, thus completing automatic dependency repair.

3. The HarmonyOS platform compatible operation method according to claim 1, characterized in that, When multiple heterogeneous drivers compete for the same type of hardware resources during heterogeneous driver registration, resource arbitration is performed according to driver priority. Drivers with priority greater than the threshold are allocated resources first, and the maximum duration of resource occupation is set.

4. The HarmonyOS platform compatible operation method according to claim 1, characterized in that, For hardware hot-plug scenarios, when registering heterogeneous drivers, the device hot-plug callback mechanism is extended. A processing thread is set up to listen for device access and removal events. When a device is accessed, the matching heterogeneous driver is queried based on the device information. The system service management framework dynamically adds mapping entries to update the service mapping table, completes the registration of the new service, and synchronously notifies the upper-layer application to reinitialize the device. When a device is removed, the system service management framework deregisters the corresponding service, uninstalls the heterogeneous driver, and releases related resources.

5. The HarmonyOS platform compatible operation method according to claim 1, characterized in that, When heterogeneous drivers run, for the set hardware resources, the system service management framework calls the trusted execution environment service to initialize a trusted session for the corresponding heterogeneous driver and build a trusted verification environment. When a heterogeneous driver invokes a setting operation, a trusted verification process is triggered to verify the legitimacy of the heterogeneous driver's trusted certificate. If the verification is successful, the heterogeneous driver is allowed to access the set hardware resources, and the relevant data is stored in a trusted memory area.

6. The HarmonyOS platform compatible operation method according to claim 1, characterized in that, The method for completing memory allocation alignment and adaptation in kernel mode is as follows: Create a memory cache containing cache blocks with the required alignment granularity for various heterogeneous drivers; Receive the requested memory size from user space and calculate the aligned size according to the alignment granularity of the heterogeneous driver; Allocate a cache block with the corresponding alignment granularity from the memory cache, add alignment information markers to the header of the cache block, and then return the cache block address to user space; When releasing memory, the user-mode address is restored to the actual cache block address, the header flag of the cache block is read to complete the validity check, and then the cache block is returned to the dedicated memory cache area to complete the release.

7. The HarmonyOS platform compatible operation method according to claim 5, characterized in that, The method of loading the matching performance and security strategies based on feature vectors and injecting the strategy parameters into the corresponding system modules is as follows: A driver version adaptation service is built to run as an independent system service. When heterogeneous drivers are registered and loaded, the driver version adaptation service parses the ELF format file of the heterogeneous driver through the driver file parsing interface, extracts the version feature information, which contains system version, interface level and build identifier in the driver's built-in segment, as well as the hardware feature information, which contains hardware type, hardware capability requirements and security level requirements, and encapsulates the version feature information and hardware feature information into a driver feature vector. Based on the driver feature vector, the matching performance adaptation policy and security operation policy are loaded from the system policy configuration directory. The performance parameters corresponding to the performance adaptation policy include the number of pre-allocated frame buffers, data format configuration, and the lower limit of hardware operating frequency. The security parameters corresponding to the security policy include security domain labels, trusted execution environment enabling requirements, and system permission requirements. The performance parameters are input into the hardware rendering and driver management module, and the security parameters are input into the security management module and trusted environment proxy module.

8. The HarmonyOS platform compatible operation method according to claim 1, characterized in that, For heterogeneous graphics drivers, upon receiving display parameters during operation, they first obtain the device handle of the graphics driver in the system hardware driver framework, read the system display parameters including resolution, refresh rate, pixel format, and display controller identifier, and return the device handle and system display parameters to the heterogeneous driver. For the graphics context creation interface, they parse the passed configuration attributes, extract the context version, priority, and debug flags, convert them into configuration parameters recognizable by the graphics driver in the system hardware driver framework, call the graphics driver interface to create a hardware context and obtain the handle, encapsulate it, and return it to the heterogeneous driver. A new context scheduling module is added to the graphics driver of the system hardware driver framework. Different priorities are assigned to heterogeneous drivers according to their application scenarios. During scheduling, contexts with a priority greater than the threshold preempt the unlocked resources of contexts with a lower priority. A time-slice round-robin mechanism is used to limit the maximum single occupancy time of a context. When switching contexts, the texture data of the next context is preloaded into the graphics cache through a cache preloading mechanism. When the heterogeneous driver creates a rendering surface, it allocates a buffer managed by the hardware driver framework and adds a compatibility identifier. When creating graphics, it binds the physical memory address of the buffer. When the heterogeneous driver submits a rendering frame, it generates a synchronization signal object and passes it to the heterogeneous driver. When rendering output, it directly submits the frame data rendered by the heterogeneous driver to the display controller to complete the screen output.

9. The HarmonyOS platform compatible operation method according to claim 1, characterized in that, The service mapping table is cached in the service cache area.

10. The HarmonyOS platform compatible operation method according to claim 1, characterized in that, When a fault occurs during the operation of a heterogeneous driver, the call stack information of the heterogeneous driver process is obtained, the abnormal function is identified, the fault type is determined based on the obtained monitoring data, the relevant resources are temporarily expanded when resources are insufficient, and the driver is automatically uninstalled and reloaded and the default configuration is restored when the driver crashes.

Images