WO2019072182A1

WO2019072182A1 - Hardware abstraction layer multiplexing method and apparatus, operating system and device

Info

Publication number: WO2019072182A1
Application number: PCT/CN2018/109550
Authority: WO
Inventors: 方文骁
Original assignee: 阿里巴巴集团控股有限公司
Priority date: 2017-10-13
Filing date: 2018-10-10
Publication date: 2019-04-18
Also published as: CN109669782A; TW201937364A

Abstract

Provided are a hardware abstraction layer multiplexing method and apparatus, an operating system and a device. The method comprises: in response to a hardware operation instruction, a first process of a first operating system invoking a first application program interface (API) in a virtual hardware abstraction layer (HAL) at a first operating system side, and sending an invoking request of the first API to a second operating system by means of cross-process communication, so that a second process in the second operating system invokes a second API in an HAL at a second operating system side so as to execute the hardware operation instruction, wherein the configuration of the first API in the virtual HAL corresponds to the configuration of the second API in the HAL at the second operating system side. By providing the virtual HAL at a first operating system side, the invoking of an API in the virtual HAL by the first operating system side can be transferred to a second operating system side by means of cross-process communication so as to realize the multiplexing of an HAL at the second operating system side by means of a first operating system, and the present invention is convenient to realize, and can be applied to any different operating systems.

Description

Hardware abstraction layer multiplexing method, device, operating system and device

The present application claims priority to Chinese Patent Application No. 201710953523.1, entitled "Hardware Abstraction Layer Reuse Method, Apparatus, Operating System, and Device", which is filed on October 13, 2017, the entire contents of which are incorporated herein by reference. In the application.

Technical field

The present invention relates to the field of operating system technologies, and in particular, to a hardware abstraction layer multiplexing method, apparatus, operating system, and device.

Background technique

When developing terminal devices, mobile terminal and other terminal equipment manufacturers often develop a hardware abstraction layer (HAL) for only one operating system. If the terminal device still needs to support another operating system, the most efficient method is to reuse or reuse the HAL. Often, the basic C libraries on which two different operating systems are based are different, which makes adaptation of the HAL multiplexed.

At present, the most commonly used adaptation scheme is to directly load the HAL using the Libhybris mechanism. The Bionic-based Android operating system and the Glibc-based operating system can be reused in the same HAL. Among them, Bionic is the basic C library of the Android operating system, and Glibc is The base C library for the GNU operating system. In order to use the Libhybris mechanism, it is first necessary to match all the functions and data structures used by the HAL on the two basic C libraries, that is, to establish the mapping relationship between functions and data structures in the two basic C libraries, and may also need to be in two Additional functions are added or modified in the base C library.

Based on the Libhybris mechanism, only the above two operating systems can be reused for HAL, and the limitation is large. Moreover, complex adaptation processing is required for the two basic C libraries, which is difficult to implement.

Summary of the invention

In view of this, the embodiments of the present invention provide a hardware abstraction layer multiplexing method, device, operating system, and device, which are used to reduce the difficulty of multiplexing the same hardware abstraction layer by different operating systems.

In a first aspect, an embodiment of the present invention provides a hardware abstraction layer multiplexing method, which is applied to a first process of a first operating system, and includes:

Retrieving a first application interface in a virtual hardware abstraction layer corresponding to the first operating system in response to a hardware operation instruction;

Sending, by the inter-process communication, the call request of the application program interface to the second operating system, so that the second process in the second operating system invokes the hardware abstraction layer corresponding to the second operating system according to the call request The second application program interface executes the hardware operation instruction;

The configuration of the first application program interface in the virtual hardware abstraction layer has a corresponding relationship with the configuration of the second application program interface in the hardware abstraction layer.

In a second aspect, the embodiment of the present invention provides a hardware abstraction layer multiplexing device, which is applied to a first process of a first operating system, and includes:

Calling a module, in response to the hardware operation instruction, calling a first application interface in the virtual hardware abstraction layer corresponding to the first operating system;

a sending module, configured to send, by using a cross-process communication, a call request of the first application program interface to a second operating system, so that a second process in the second operating system invokes the second The second application program interface in the hardware abstraction layer corresponding to the operating system executes the hardware operation instruction;

In a third aspect, an embodiment of the present invention provides an operating system, including: an application framework layer and a virtual hardware abstraction layer;

The application framework layer includes a process for implementing the hardware abstraction layer multiplexing method as described in the first aspect;

The configuration of the application program interface in the virtual hardware abstraction layer has a corresponding relationship with the configuration of the application program interface in the hardware abstraction layer corresponding to another operating system. Implementation of the application program interface in the virtual hardware abstraction layer indicates that a call request to an application interface in the virtual hardware abstraction layer is transmitted to another operating system through inter-process communication. The operating system corresponds to the first operating system in the first aspect.

In a fourth aspect, an embodiment of the present invention provides an electronic device, where the electronic device can be implemented as a user terminal device, including a processor and a memory, where the memory is used to store and support the user terminal device to perform the hardware abstraction layer recovery in the first aspect. In a program of a method, the processor is configured to execute a program stored in the memory. The electronic device can also include a communication interface for communicating with other devices or communication networks.

In addition, an embodiment of the present invention provides a computer storage medium for storing computer software instructions for the electronic device, which includes a program for performing the hardware abstraction layer multiplexing method in the above first aspect.

In a fifth aspect, an embodiment of the present invention provides a hardware abstraction layer multiplexing method, which is applied to a first process of a first operating system, and includes:

Receiving a call request sent by the second process in the second operating system by the cross-process communication, where the call request is the second process in the virtual hardware abstraction layer corresponding to the second operating system in response to the hardware operation instruction Triggered by an application interface;

And calling a second application program interface in the hardware abstraction layer corresponding to the second operating system to execute the hardware operation instruction according to the calling request;

In a sixth aspect, the embodiment of the present invention provides a hardware abstraction layer multiplexing device, which is applied to a first process of a first operating system, and includes:

a receiving module, configured to receive a call request sent by the second process in the second operating system by using the cross-process communication, where the call request is that the second process invokes the virtual hardware corresponding to the second operating system in response to the hardware operation instruction Triggered by the first application interface in the abstraction layer;

a calling module, configured to invoke a second application program interface in a hardware abstraction layer corresponding to the second operating system according to the calling request, to execute the hardware operation instruction;

In a seventh aspect, an embodiment of the present invention provides an operating system, including: an application framework layer and a cross-process communication interface, where the application framework layer includes a process, and the process is used to implement the hardware abstraction layer as described in the fifth aspect. Reuse method. The operating system corresponds to the first operating system in the fifth aspect.

In an eighth aspect, an embodiment of the present invention provides an electronic device, where the electronic device can be implemented as a user terminal device, such as a smart phone, and the like, and includes a processor and a memory, where the memory is used to store and support the electronic device to perform the foregoing fifth aspect. A program of a hardware abstraction layer multiplexing method, the processor being configured to execute a program stored in the memory. The electronic device can also include a communication interface for communicating with other devices or communication networks.

In addition, an embodiment of the present invention provides a computer storage medium for storing computer software instructions for the electronic device, which includes a program for performing the hardware abstraction layer multiplexing method in the fifth aspect.

The hardware abstraction layer multiplexing method, device, operating system and device provided by the embodiments of the present invention include a first operating system and a second operating system based on different basic C libraries in a terminal device, and the initially developed HAL is directed to the first The second operating system is called the real HAL. In order to enable the first operating system to multiplex the real HAL, a virtual HAL is set on the first operating system side, and an application program interface (API) configured in the virtual HAL is configured with an API encapsulated in the real HAL. The configuration has a corresponding relationship, such as the same, but the implementation of the API encapsulated in the virtual HAL is different from the implementation of the API encapsulated in the real HAL. The API implementation encapsulated in the virtual HAL indicates that the first operating system side is called by cross-process communication. The API is transmitted to the second operating system side, and the API implementation encapsulated in the real HAL is related operational information that is required to actually perform the API call.

Based on this, when the first operating system side triggers a hardware operation instruction for a certain hardware such as a camera in response to the user's operation, the first process call on the first operating system side is triggered to call the corresponding corresponding virtual HAL corresponding to the hardware. The first API, such as the camera, opens the interface, so that the first process can send a call request to invoke the first API to the second operating system side, and the second operating system second, by cross-process communication based on the implementation of the first API. After receiving the call request, the process calls the corresponding second API in the real HAL, thereby completing the execution of the hardware operation instruction according to the implementation of the second API. In this solution, the virtual HAL needs to be set on the first operating system side, so that the API configuration in the virtual HAL has a corresponding relationship with the real HAL API configuration, and the API implementation in the virtual HAL is set to be a virtual HAL through cross-process communication. The call of an API is passed to the second operating system corresponding to the real HAL, so that the first operating system can reuse the real HAL of the second operating system side, which is convenient to implement and can be applied to any different operating system. .

DRAWINGS

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, a brief description of the drawings used in the embodiments or the prior art description will be briefly described below. Obviously, the drawings in the following description It is a certain embodiment of the present invention, and other drawings can be obtained from those skilled in the art without any creative work.

FIG. 1 is a schematic diagram of a hardware abstraction layer multiplexing scenario according to an embodiment of the present invention;

2 is a flowchart of a hardware abstraction layer multiplexing method according to an embodiment of the present invention;

FIG. 3 is a flowchart of another hardware abstraction layer multiplexing method according to an embodiment of the present invention;

FIG. 4 is a flowchart of still another hardware abstraction layer multiplexing method according to an embodiment of the present invention;

FIG. 5 is an interaction diagram of a hardware abstraction layer multiplexing method according to an embodiment of the present invention;

6 is a schematic structural diagram of a hardware abstraction layer multiplexing device corresponding to the embodiment shown in FIG. 2;

7 is a schematic diagram showing the composition of an operating system corresponding to the embodiment shown in FIG. 2;

8 is a schematic structural diagram of an electronic device corresponding to the hardware abstraction layer multiplexing device shown in FIG. 6;

9 is a schematic structural diagram of a hardware abstraction layer multiplexing device corresponding to the embodiment shown in FIG. 3 or FIG. 4;

10 is a schematic diagram showing the composition of an operating system corresponding to the embodiment shown in FIG. 3 or FIG. 4;

FIG. 11 is a schematic structural diagram of an electronic device corresponding to the hardware abstraction layer multiplexing device shown in FIG. 9.

Detailed ways

The technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the drawings in the embodiments of the present invention. It is a partial embodiment of the invention, and not all of the embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative efforts are within the scope of the present invention.

The terms used in the embodiments of the present invention are for the purpose of describing particular embodiments only and are not intended to limit the invention. The singular forms "a", "the", "the" and "the" Generally, at least two types are included, but the case of including at least one is not excluded.

It should be understood that the term "and/or" as used herein is merely an association describing the associated object, indicating that there may be three relationships, for example, A and/or B, which may indicate that A exists separately, while A and B, there are three cases of B alone. In addition, the character "/" in this article generally indicates that the contextual object is an "or" relationship.

It should be understood that although the terms first, second, third, etc. may be used to describe XXX in embodiments of the invention, these XXX should not be limited to these terms. These terms are only used to distinguish XXX. For example, the first XXX may also be referred to as a second XXX without departing from the scope of the embodiments of the present invention. Similarly, the second XXX may also be referred to as a first XXX.

Depending on the context, the words "if" and "if" as used herein may be interpreted to mean "when" or "when" or "in response to determining" or "in response to detecting." Similarly, depending on the context, the phrase "if determined" or "if detected (conditions or events stated)" can be interpreted as "when determined" or "in response to determination" or "when detected (stated condition or event) "Time" or "in response to a test (condition or event stated)".

It should also be noted that the terms "including", "comprising" or "comprising" or any other variations thereof are intended to encompass a non-exclusive inclusion, such that the item or system comprising a plurality of elements includes not only those elements but also Other elements, or elements that are inherent to such goods or systems. An element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the item or system including the element, without further limitation.

In addition, the sequence of steps in the following method embodiments is merely an example and is not strictly limited.

FIG. 1 is a schematic diagram of a hardware abstraction layer multiplexing scenario according to an embodiment of the present invention. As shown in FIG. 1 , a terminal device includes two operating systems OS_A and OS_B based on different basic C libraries, where OS_A is included. It is based on the basic C library, Libc_A, and OS_B is based on the basic C library, A developed by Libc_B. Corresponding to the scenario, the hardware abstraction layer multiplexing method provided by the embodiment of the present invention is used to implement multiplexing of the two operating systems shown in FIG. 1 , OS_A and OS_B, to the HAL located on the OS_A side.

Assume that the initially developed HAL is for OS_A, and is different from the virtual HAL, assuming it is called a real HAL. In order to enable OS_B to multiplex the real HAL, a virtual HAL is set on the OS_B side. Specifically, the configuration of the API encapsulated in the virtual HAL (which may also be referred to as a definition) has a corresponding relationship with the configuration of the API encapsulated in the real HAL. Preferably, the configuration and reality of the encapsulated API in the virtual HAL may be set. The configuration of the API encapsulated in the HAL is the same, but the implementation of the API encapsulated in the virtual HAL is different from the implementation of the API encapsulated in the real HAL. The API implementation encapsulated in the virtual HAL indicates that the API called by the OS_B side is transmitted through cross-process communication. To the OS_A side, the API implementation encapsulated in the real HAL is the relevant operational information required to actually complete the API call.

The mapping between the configuration of the API encapsulated in the virtual HAL and the configuration of the API encapsulated in the real HAL may be expressed as a one-to-one correspondence, or may be represented as a many-to-one correspondence. For example, if an API is configured as function(A, B, C) in the real HAL, the API configuration corresponding to the API in the virtual HAL can be: function(A), function(B), function(C ), that is, a three-to-one correspondence is formed.

Wherein, since the content implemented by the API in the virtual HAL involves cross-process communication, it is necessary to establish an inter-process communication (IPC) connection between the above two operating systems as shown in FIG. 1 : IPC Bridge, as illustrated in the figure. IPC_A, IPC_B is the interface at both ends of the communication. Optionally, the cross-process communication may be pre-established for subsequent direct use, or may be established in real time as needed.

It can be understood that the establishment of the above-mentioned cross-process communication is to establish an interface IPC_A on the OS_A side and an interface IPC_B on the OS_B side, wherein the IPC_A is based on Libc_A and the IPC_B is based on Libc_B.

Optionally, the cross-process communication connection may be implemented based on an IPC mechanism provided in an operating system kernel Kernel, such as Socket, OpenBinder, but is not limited to the two implementation manners.

In addition, the real HAL and the virtual HAL in the embodiment of the present invention may be considered as an abstraction layer for a certain hardware in the terminal device, such as a hardware abstraction layer of the camera: camera HAL; or a hardware abstraction layer of the sensor: sensor HAL, etc. Wait.

Based on the setting conditions of the above two operating systems, for example, when a camera application on the OS_B side needs to call the camera HAL to operate the camera in response to the user's operation, the camera application can start a process, and the process can think Is process B, the process B, for example, calls an API in the virtual camera HAL, assuming that the configuration and implementation of the API is as follows:

Bool open(int cameraId){

Return ipc_send(API_OPEN,cameraId);

}

This API is used to trigger the opening operation of the camera. Among them, bool open (int cameraId) is the configuration of the API, and the content in {} is the implementation of the API. The cameraId is a call parameter indicating which camera needs to be operated, such as Id=0 for the front camera and Id=1 for the rear camera. API_OPEN indicates that the Open API is called, and return returns the result of ipc_send as the result of the open API.

It can be seen that the implementation of this API indicates a call to pass the API to the OS_A side via cross-process communication (IPC). Therefore, the process B can create a cross-process communication with a certain preset process on the OS_A side called process A in real time, and send a call request for the API to the process A through the established cross-process communication. The call request may carry API call related parameters, such as which API identifier information to be called API_OPEN, and which camera needs to be turned on - cameraId, so that process A can call the real camera according to the call request. The corresponding API in the HAL is used to complete the operations required by the camera application for the camera application. Assume that the corresponding API is configured and implemented in the real camera HAL as follows:

Where open(int cameraId) is the configuration of the API, and the content in {} is the implementation of the API. It can be seen that the implementation of the API in the real camera HAL is different in the implementation of the virtual camera HAL, and the implementation in the real camera HAL is specifically the operation information of the corresponding hardware and the like.

In the above example, the virtual HAL is the same as the configuration of the API in the real HAL, and both are bool open (int cameraId).

It should be noted that the above process A is a process corresponding to the real camera HAL, and the process A can be regarded as a real camera HAL service process, which is pre-created, and the process B can be regarded as a client process, and the process A can It is started with the start of OS_A, and then it is monitored whether there is a client process from OA_B that needs to call the API in the real camera HAL.

The virtual HAL is set in the OS_B, and the configuration of the API in the virtual HAL has a corresponding relationship with the configuration of the real API. For example, the API configuration in the virtual HAL can be formed by directly copying from the real HAL. The implementation of the API in the virtual HAL only needs to provide the sending function of the IPC and provide related calling parameters, so that the virtual HAL does not need complicated function realization logic with respect to the real HAL, that is, it does not need to actually perform the operation control of the hardware, and realize simple.

The hardware abstraction layer multiplexing method provided by the embodiment of the present invention is introduced in the following embodiments in combination with the following embodiments.

2 is a flowchart of a hardware abstraction layer multiplexing method according to an embodiment of the present invention. The hardware abstraction layer multiplexing method provided in this embodiment is implemented in the first operating system shown in FIG. The first process in the operating system executes. With reference to FIG. 1, it is assumed that the first operating system is OS_B, the second operating system is OS_A, the first process is process B, and the second process is process A. As shown in FIG. 2, the method includes the following steps:

201. In response to the hardware operation instruction, the first process of the first operating system invokes the first application interface in the virtual hardware abstraction layer corresponding to the first operating system.

Optionally, in an actual application, the process B may be a process initiated by an application or application framework layer on the OS_B side, such as a process initiated by the camera application in the above example. Optionally, the process B may also be a dedicated process corresponding to the virtual HAL, and is used to invoke the API in the virtual HAL. At this time, the process B may be accessed by the application.

For example, the camera application responds to the user-triggered photographing operation instruction, accesses the process B corresponding to the virtual camera HAL corresponding to the camera, and transmits relevant parameters to the first process, such as the camera identifier camera0, and the working mode—photographing. Thus, process B invokes the camera API in the virtual camera HAL based on this parameter.

202. The first process sends a call request of the application program interface to the second operating system by using the cross-process communication, so that the second process in the second operating system invokes the second in the hardware abstraction layer corresponding to the second operating system according to the call request. The second application interface executes hardware operation instructions.

The configuration of the first application program interface in the virtual HAL has a corresponding relationship with the configuration of the second application program interface in the HAL corresponding to the second operating system, that is, the real HAL.

In this embodiment, it is assumed that the above correspondence relationship is embodied as the same configuration, so that the first API is the same as the second API.

As mentioned above, when process B calls an API, based on the implementation of the API, the call request of the API will be sent to OS_A through cross-process communication, so that process A in OS_A calls process B according to the call request. The API in the real HAL to execute hardware operation instructions. The content included in the implementation of the API indicates that the calling parameter of the API is transmitted to the process A through cross-process communication, and the calling parameter includes, for example, an identifier of the API and a hardware identifier corresponding to the API. Process B can extract the call parameters from it, and the package is sent to process A in the call request.

In the actual application, the process A calls the API that the process B needs to call in the real HAL to execute the above hardware operation instructions, which may involve the callback of the hardware operation result, that is, feedback to the process B, and may not involve the callback of the hardware operation result. For example, the above API may only implement a few cameras for querying the user terminal device, for example, there will be no callback of the hardware operation result; for example, the above API may be to trigger the camera to perform recording, and at this time, there will be hardware. The callback of the operation result, the video captured by the camera is called back to the first process.

Therefore, in the case of a hardware operation result callback, Process B also needs to receive the hardware operation result fed back by Process A.

Optionally, the hardware operation result may include: hardware data generated by hardware that executes hardware operation instructions, that is, hardware corresponding to the real HAL, such as the video recorded above; or the hardware operation result is hardware data in the shared memory. The storage address in the middle; or, the result of the hardware operation is an operation failure prompt message.

Optionally, in order to avoid the need to transmit excessive data between the process B and the process A, the required transmission time is too long, so that the excessive occupation time of the real HAL and the virtual HAL affects other needs to call the real HAL and the virtual HAL. The process call, process A can determine according to the size of the data volume of the hardware data is directly feedback to the process B the hardware data. For example, when the data volume of the hardware data is less than the preset threshold, the data is directly fed back to the process B. Otherwise, the hardware data is stored in the shared memory, so that only the storage address of the hardware data in the shared memory is fed back to the process B. So that process B gets the hardware data from the shared memory. The shared memory is a preset storage space that can be shared by two operating systems.

It should be noted that the above operation failure prompt information can be regarded as a special hardware operation result. The operation failure prompt information refers to the process A, after receiving the call request sent by the process B, calling the real HAL based on the call request. Before the corresponding API, if it is identified that the API to be called has an exclusive operation attribute, and then it is determined that the hardware corresponding to the real HAL is in a busy state, it is sent to the process B. When the hardware is in a busy state, it indicates that another process is calling the real HAL to operate the hardware, and then the process A cannot call the API in the real HAL, thereby feeding back the operation failure prompt information to the first process. The description about the above exclusive operation attribute will be described in detail in the subsequent embodiments.

In summary, the hardware abstraction layer multiplexing method provided by the embodiment of the present invention only needs to set a virtual HAL with the following features on the first operating system side, that is, a real hardware abstraction layer corresponding to the second operating system by the first operating system can be implemented. Reuse: The configuration of the API set in the virtual HAL has a corresponding relationship with the API configuration in the real HAL, and the API implementation in the virtual HAL is set to communicate the call of an API in the virtual HAL to the corresponding through the inter-process communication. In the second operating system of the real HAL. This solution is easy to implement and can be applied to any different operating system.

FIG. 3 is a flowchart of another hardware abstraction layer multiplexing method according to an embodiment of the present invention. The hardware abstraction layer multiplexing method provided by this embodiment is performed by a first process in a first operating system. It is assumed that the first operating system in this embodiment is OS_A shown in FIG. 1, the second operating system is OS_B shown in FIG. 1, the first process is process A shown in FIG. 1, and the second process is as shown in FIG. Process B, and thus, as shown in FIG. 3, the method may include the following steps: 301: The first process receives a call request sent by the second process in the second operating system by using the cross-process communication, where the call request is a response of the second process The hardware operation instruction is triggered by calling the first application interface in the virtual hardware abstraction layer corresponding to the second operating system.

302. The first process invokes a second application program interface in the hardware abstraction layer corresponding to the first operating system according to the call request to execute the hardware operation instruction.

The configuration of the first application program interface in the virtual HAL has a corresponding relationship with the configuration of the second application program interface in the hardware abstraction layer corresponding to the first operating system OS_A, that is, the real HAL.

In this embodiment, it is assumed that the above correspondence relationship is that the configuration of the first application program interface in the virtual HAL is the same as the configuration of the second application program interface in the real HAL, and the following description is based on the assumption.

The call request may carry information such as an identifier of an API to be invoked by the process B and an identifier of the hardware to be operated, so that the process A can invoke the corresponding API in the real HAL accordingly.

The process A may be a process set in advance on the OS_A side, and exists when the OS_A is started. The process A is responsible for the call of the real HAL corresponding to the OS_A by the process in the OS_B, so that the OS_B can multiplex the real HAL on the OS_A side.

For the specific process of the process A, the related steps in the foregoing embodiments may be referred to, and details are not described herein.

FIG. 4 is a flowchart of still another hardware abstraction layer multiplexing method according to an embodiment of the present invention. The hardware abstraction layer multiplexing method provided by this embodiment may be used by the first operating system. The first process to execute. It is assumed that the first operating system in this embodiment is OS_A shown in FIG. 1, the second operating system is OS_B shown in FIG. 1, the first process is process A shown in FIG. 1, and the second process is as shown in FIG. Process B, and thus, as shown in FIG. 4, the method may include the following steps:

401. The first process receives a call request sent by the second process in the second operating system by using the cross-process communication, where the call request is the first process in the virtual process abstraction layer corresponding to the second operating system in response to the hardware operation instruction. Triggered by the application interface.

402. The first process determines, according to the calling request, that the second application interface in the hardware abstraction layer corresponding to the first operating system needs to be invoked, and if the second application program interface has the exclusive operation attribute, the hardware corresponding to the hardware abstraction layer is viewed. status.

403. If the state of the hardware indicates that the hardware is in an idle state, the first process invokes the second application program interface in the hardware abstraction layer corresponding to the first operating system according to the call request to execute the hardware operation instruction.

404. The first process sets the state of the hardware to a busy state.

405. If the data quantity of the hardware data generated by the hardware execution hardware operation instruction is less than a preset threshold, the first process sends the hardware data to the second process; if the data quantity of the hardware data is greater than or equal to the preset threshold, the first The process stores the hardware data in the shared memory and sends the hardware data to the second process in the shared memory.

The call request sent by the process B carries the identifier of the first API invoked by the process B in the virtual HAL. Therefore, the process A can determine the correspondence between the API configuration in the real HAL and the API configuration in the virtual HAL. The second API in the real HAL that corresponds to the first API that Process B needs to call.

In an optional embodiment, after receiving the above call request, the process A may immediately invoke the corresponding second API in the real HAL. However, in some practical application scenarios, when the process A needs to invoke the second API in the real HAL to perform some operation on the hardware corresponding to the real HAL, there may be other processes in the OS_A that have previously called the real An API in the HAL is operating on the hardware. And if the hardware can only be operated by one process at the same time, that is, if the hardware belongs to exclusive hardware, then process A should not be allowed to call the API in the real HAL. For example, if a process is controlling a camera to take a photo, another process cannot use the camera at the same time.

Therefore, in order to avoid simultaneous calls of different processes to the same real HAL, that is, to avoid simultaneous operations of different processes on the same hardware, process A also provides a mutual exclusion mechanism, which is simply when the real HAL is currently being When the process is invoked, the process A will set the state of the hardware corresponding to the real HAL to a busy state, and vice versa, to avoid simultaneous calls of the real HAL by multiple processes. The busy state means that the hardware is occupied by a certain process. Therefore, the busy state also refers to an occupied state. Accordingly, the idle state may also refer to an unoccupied state.

Therefore, in order to implement the above mutual exclusion function, the process A may first identify whether the second API has an exclusive operation attribute before calling the second API in the real HAL based on the process B-based call request, and if the second API is identified as having an exclusive operation, Attribute, view the state of the hardware corresponding to the real HAL. If the state of the hardware indicates that the hardware is in an idle state, the process A can call the second API in the real HAL to execute the hardware operation instruction according to the call request of the process B; If the state of the hardware indicates that the hardware is busy, the process A sends an operation failure prompt message to the process A, indicating that the hardware is being operated by another process. Conversely, if it is recognized that the second API does not have an exclusive operation attribute, it means that even if another process is calling the real HAL to operate the hardware, the execution of the second API invoked by the process A does not affect the other. The process progresses normally. At this time, the process A can also call the second API in the real HAL to execute the hardware operation instruction.

In this embodiment, the exclusive operation attribute of the second API may also be referred to as an exclusive operation attribute, and the meaning thereof may be understood as: if a different process is allowed to simultaneously invoke the second API to perform some operation on the hardware, the second API There is no exclusive operation attribute. Conversely, if different processes are not allowed to simultaneously call the second API to perform some operation on the hardware, the second API has an exclusive operation attribute. For example, if the second API can implement the opening operation of the camera, the camera is not allowed to turn on the camera again because a certain process has actually turned on the camera. The second API has exclusive operational attributes. For example, if the second API is used to implement the query function of the number of cameras included in the terminal device, the second API does not have an exclusive operation attribute because it can actually allow multiple processes to simultaneously query the number of cameras. .

Optionally, whether the second API has an exclusive operation attribute may be identified according to a configuration of the second API in the real HAL. For example, a certain field may be set in the configuration of the second API, and different values of the field are used to indicate whether the second API has an exclusive operation attribute, for example, 00 means that there is no exclusive operation attribute, and 01 means that there is an exclusive operation attribute. .

In an optional embodiment, after receiving the call request sent by the process B, the process A may perform the query of the hardware state if it recognizes that the API corresponding to the call request in the real HAL has an exclusive operation attribute. However, in another alternative embodiment, process A may also view the state of the hardware to reduce the query operation only when it recognizes that it needs to invoke a particular API with exclusive operational attributes. Therefore, after receiving the call request sent by the process B, the process A has the exclusive operation attribute of the second API corresponding to the call request in the real HAL, and the second API is used to implement the hardware opening operation. At this time, the status of the hardware is checked. Taking the camera application as an example, in general, during the process of taking a picture through the camera, the process B may need to sequentially call the APIs of turning on the camera, turning on the preview, taking a picture, and turning off the camera. When process B calls the API for enabling the camera in the virtual HAL, process A receives the call request corresponding to the API of the open camera sent by process B, and then process A recognizes that the API has an exclusive operation attribute and is used to implement the camera. When the operation is turned on, the state of the camera is queried. Assuming that the camera is in an idle state at this time, the process A calls the API of the corresponding camera in the real HAL to perform an opening operation on the camera, and sets the state of the camera to a busy state. Alternatively, process A can also record that the process that puts the camera in a busy state is process B. Then, optionally, the process A feeds back the success indication to the process B, so that the process B continues to invoke the API for opening the preview in the virtual HAL. At this time, after receiving the call request corresponding to the API for opening the preview, the process A may not perform the query of the camera state even if it recognizes that the API of the open preview in the real HAL has an exclusive operation attribute, because the process B has not yet End the operation of the camera. Until process A receives the call request of process B to close the camera's API, it recognizes that the API of the closed camera has an exclusive operation attribute, and is used to implement the closing operation of the camera. At this time, process A sets the state of the camera to idle. State, at this point, process B ends the operation of the camera.

Therefore, if process A recognizes that the second API has an exclusive operation attribute, and the second API is used to implement a shutdown operation on the hardware, the state of the hardware is set to an idle state. In addition, in actual applications, in addition to the case where the process A needs to call the real HAL, there may be a process initiated by an application on the OS_A side, assuming that the third process needs to invoke the real HAL. . At this time, before calling the real HAL, the third process needs to query the process A for the state of the hardware corresponding to the real HAL to call the real HAL when the hardware is in an idle state. Therefore, the process A can also receive a query request for querying the state of the hardware corresponding to the real HAL sent by the third process in the OS_A through the inter-process communication, and send the state of the hardware to the third process, so that the third process according to the The state determines if the real HAL can be called.

As described in the foregoing embodiment, in order to avoid excessively long occupation time of the real HAL, the process A may determine the data size of the hardware data generated by the hardware when executing the hardware operation instruction according to the second API, and directly determine the hardware data. Feedback to process B, or feedback the storage address of the hardware data in the shared memory to process B.

In summary, the process A is provided on the OS_A side with the real HAL to listen for the call request from the OS_B to the real HAL, so as to assist the completion of the OS_B multiplexing of the real HAL; in addition, the process A also provides a mutual exclusion mechanism to avoid more The process calls the simultaneous HAL corresponding to the exclusive hardware.

FIG. 5 is an interaction diagram of a hardware abstraction layer multiplexing method according to an embodiment of the present invention. In the embodiment, the first operating system is OS_B, the second operating system is OS_A, and the first process is process B. The second process is process A. Also assume that the API configuration in the virtual HAL is the same as the API configuration in the real HAL. As shown in FIG. 5, the following steps may be included:

501. In response to the hardware operation instruction, the first process of the first operating system invokes an application program interface in a virtual hardware abstraction layer corresponding to the first operating system.

502. The first process sends an invocation request of the application program interface to the second process in the second operating system by cross-process communication.

503. The second process identifies that the application interface has an exclusive operation attribute, and checks the state of the hardware corresponding to the real hardware abstraction layer.

504. If the hardware is in an idle state, the second process invokes the application program interface in the real hardware abstraction layer corresponding to the second operating system according to the call request to execute the hardware operation instruction.

505. The second process sets the state of the hardware to a busy state.

506. The second process receives a query request that is sent by the third process in the second operating system by using the cross-process communication to query the status of the hardware corresponding to the real HAL.

507. The second process sends a query response indicating that the hardware is busy to the third process.

508. The third process gives up calling the real HAL.

509. The second process sends hardware data generated by the hardware to execute the hardware operation instruction to the first process.

A hardware abstraction layer multiplexing device of one or more embodiments of the present invention will be described in detail below. Those skilled in the art will appreciate that these hardware abstraction layer multiplexing devices can be constructed using commercially available hardware components configured by the steps taught by the present scheme.

FIG. 6 is a schematic structural diagram of a hardware abstraction layer multiplexing apparatus corresponding to the embodiment shown in FIG. 2. As shown in FIG. 6, the apparatus includes: a calling module 11, a sending module 12, and a receiving module 13.

The calling module 11 is configured to invoke a first application interface in the virtual hardware abstraction layer corresponding to the first operating system in response to the hardware operation instruction.

The sending module 12 is configured to send the call request of the application program interface to the second operating system by cross-process communication, so that the second process in the second operating system invokes the second operation according to the call request The second application program interface in the hardware abstraction layer corresponding to the system executes the hardware operation instruction.

Optionally, the configuration of the first application program interface in the virtual hardware abstraction layer is the same as the configuration of the second application program interface in the hardware abstraction layer.

Optionally, the device further includes: a receiving module 13.

The receiving module 13 is configured to receive a hardware operation result fed back by the second process.

The hardware operation result includes:

Hardware data generated by hardware that executes the hardware operation instructions; or a storage address of the hardware data in a shared memory; or an operation failure prompt information; wherein the hardware data and the storage address are The second process determines whether to send according to the data size of the hardware data; the operation failure prompt information is sent by the second process when determining that the hardware is busy.

The apparatus shown in FIG. 6 can perform the method of FIG. 2. For the parts not described in detail in this embodiment, reference may be made to the related description of the embodiment shown in FIG. 2. For the implementation process and technical effects of the technical solution, refer to the description in the embodiment shown in FIG. 2, and details are not described herein again.

FIG. 7 is a schematic diagram of a composition of an operating system corresponding to the embodiment shown in FIG. 2. As shown in FIG. 7, the operating system may be OS_B shown in FIG. 1, and the operating system includes: an application framework layer and a virtual Hardware abstraction layer.

The application framework layer includes a process for implementing the hardware abstraction layer multiplexing method described in the embodiment shown in FIG. 2. This process can be process B in the embodiment shown in FIG. 2.

Referring to the introduction in the foregoing embodiment, the configuration of the application program interface in the virtual hardware abstraction layer has a corresponding relationship with the configuration of the application program interface in the hardware abstraction layer corresponding to another operating system. Implementation of the application program interface in the virtual hardware abstraction layer indicates that a call request to an application interface in the virtual hardware abstraction layer is transmitted to another operating system through inter-process communication.

Since the implementation of the application interface in the virtual hardware abstraction layer involves cross-process communication, in an alternative embodiment, the cross-process communication can be implemented based on a cross-process communication mechanism such as a Socket provided in the kernel of the operating system, and thus, optional The operating system may also include a kernel as shown in FIG.

In a possible design, the structure of the hardware abstraction layer multiplexing device shown in FIG. 6 can be implemented as an electronic device, which is a user terminal device, such as a smart phone, a tablet computer, a PC, etc., as shown in FIG. The user terminal device may include a processor 21 and a memory 22. The memory 22 is configured to store a program for supporting a user terminal device to execute the hardware abstraction layer multiplexing method provided in each of the above-described embodiments, and the processor 21 is configured to execute the storage in the memory 22. program.

The program includes one or more computer instructions, wherein the one or more computer instructions are executed by the processor 21 to implement the following steps:

Optionally, the processor 21 is further configured to perform all or part of the steps of the foregoing method shown in FIG. 2.

The structure of the user terminal device may further include a communication interface 23 for the user terminal device to communicate with other devices or a communication network.

In addition, an embodiment of the present invention provides a computer storage medium for storing computer software instructions used by a user terminal device, which includes a program for performing the hardware abstraction layer multiplexing method in the foregoing method embodiment shown in FIG. .

FIG. 9 is a schematic structural diagram of a hardware abstraction layer multiplexing apparatus corresponding to the embodiment shown in FIG. 3 or FIG. 4. As shown in FIG. 9, the apparatus includes: a receiving module 31 and a calling module 32.

The receiving module 31 is configured to receive a call request sent by the second process in the second operating system by using the cross-process communication, where the call request is that the second process invokes the virtual corresponding to the second operating system in response to the hardware operation instruction Triggered by the first application interface in the hardware abstraction layer.

The calling module 32 is configured to invoke a second application program interface in the hardware abstraction layer corresponding to the second operating system according to the calling request to execute the hardware operation instruction.

Optionally, the device further includes: a query module 33, and a setting module 34.

The querying module 33 is configured to check the state of the hardware corresponding to the hardware abstraction layer if it is recognized that the second application program interface has an exclusive operation attribute.

Correspondingly, the calling module 32 is specifically configured to: if the query module 33 detects that the state indicates that the hardware is in an idle state, invoke the second application program interface according to the call request to execute the hardware operation instruction.

The setting module 34 is configured to set the state of the hardware to a busy state under the trigger of the calling module 32.

Optionally, the querying module 33 is specifically configured to: if it is recognized that the second application program interface has an exclusive operation attribute, and the second application program interface is used to implement an opening operation on the hardware, State the hardware.

Optionally, the calling module 32 is specifically configured to: if the second application program interface is identified as having a non-exclusive operation attribute, invoke the second application program interface according to the call request to perform the hardware operation instruction.

Optionally, the device further includes: a sending module 35.

The sending module 35 is configured to feed back a hardware operation result corresponding to the hardware operation instruction to the first process.

Optionally, the sending module 35 is specifically configured to:

And if the data amount of the hardware data generated by the hardware executing the hardware operation instruction is less than a preset threshold, sending the hardware data to the first process as the hardware operation result;

And if the data amount of the hardware data is greater than or equal to the preset threshold, storing the hardware data in a shared memory, and sending the storage address of the hardware data in the shared memory to the first process.

Optionally, the sending module 35 is further configured to:

If the status indicates that the hardware is in a busy state, the operation failure prompt information is sent to the first process.

Optionally, the receiving module 31 is further configured to: receive a query request sent by the third process in the second operating system by using a cross-process communication, where the query request is used to query a status of the hardware.

The sending module 35 is further configured to: send a status of the hardware to the third process, so that the third process determines whether the hardware abstraction layer can be invoked according to the status.

The apparatus shown in FIG. 9 can perform the method of the embodiment shown in FIG. 3 or FIG. 4. For the parts not described in detail in this embodiment, reference may be made to the related description of the embodiment shown in FIG. 3 or FIG. For the implementation process and technical effects of the technical solution, refer to the description in the embodiment shown in FIG. 3 or FIG. 4, and details are not described herein again.

10 is a schematic diagram of a composition of an operating system corresponding to the embodiment shown in FIG. 3 or FIG. 4. As shown in FIG. 10, the operating system may be OS_A as shown in FIG. 1, and the operating system includes: an application framework. Layer and cross-process communication interfaces.

The application framework layer includes a process for implementing the hardware abstraction layer multiplexing method as described in the embodiment shown in FIG. 3 or FIG. 4. This process can be process A in the embodiment shown in FIG. 2.

Referring to the introduction in the foregoing embodiment, optionally, the hardware abstraction layer may also be included in the operating system. The configuration of the application program interface in the hardware abstraction layer has a corresponding relationship with the configuration of the application program interface in the virtual hardware abstraction layer corresponding to the operating system shown in FIG.

The cross-process communication interface is used by the process to receive a call request sent by another operating system through the cross-process communication interface.

In an optional embodiment, the cross-process communication interface may be implemented based on a cross-process communication mechanism, such as a Socket, provided in a kernel of an operating system. Therefore, optionally, the operating system may further include a kernel as shown in FIG. .

In a possible design, the structure of the hardware abstraction layer multiplexing device shown in FIG. 9 can be implemented as an electronic device, and the electronic device is a user terminal device. As shown in FIG. 11, the user terminal device can include: a processor 41. And memory 42. The memory 42 is configured to store a program that supports the user terminal device to execute the hardware abstraction layer multiplexing method provided in each of the above-described embodiments, and the processor 41 is configured to execute the storage in the memory 42. program.

The program includes one or more computer instructions, wherein the one or more computer instructions are executed by the processor 41 to enable the following steps:

Optionally, the processor 41 is further configured to perform all or part of the steps of the foregoing method shown in FIG. 3 or FIG. 4.

The structure of the user terminal device may further include a communication interface 43 for the user terminal device to communicate with other devices or a communication network.

In addition, an embodiment of the present invention provides a computer storage medium for storing computer software instructions used by a user terminal device, which includes a hardware abstraction layer multiplexing method for performing the foregoing method embodiment shown in FIG. 3 or FIG. The procedures involved.

The device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separate, and the components displayed as units may or may not be physical units, ie may be located A place, or it can be distributed to multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the embodiment. Those of ordinary skill in the art can understand and implement without deliberate labor.

Through the description of the above embodiments, those skilled in the art can clearly understand that the embodiments can be implemented by adding a necessary general hardware platform, and can also be implemented by a combination of hardware and software. Based on the understanding, the above-mentioned technical solutions may be embodied in the form of a computer product in essence or in the form of a computer product, and the present invention may employ computer-usable storage in one or more computer-usable program codes. A form of computer program product embodied on a medium (including but not limited to disk storage, CD-ROM, optical storage, etc.).

The present invention has been described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (system), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flowchart illustrations and/or FIG. These computer program instructions can be provided to a processor of a general purpose computer, a special purpose computer, an embedded processor, or other programmable hardware abstraction layer multiplexing device to produce a machine that multiplexes the processing of the device through a computer or other programmable hardware abstraction layer. The instructions executed by the apparatus generate means for implementing the functions specified in one or more blocks of the flowchart or in a block or blocks of the flowchart.

The computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable hardware abstraction layer multiplexing device to operate in a particular manner, such that instructions stored in the computer readable memory produce an article of manufacture including the instruction device. The instruction means implements the functions specified in one or more blocks of the flow or in a flow or block diagram of the flowchart.

These computer program instructions can also be loaded onto a computer or other programmable hardware abstraction layer multiplexing device such that a series of operational steps are performed on a computer or other programmable device to produce computer-implemented processing for use in a computer or other programmable device The instructions executed above provide steps for implementing the functions specified in one or more blocks of the flowchart or in a block or blocks of the flowchart.

In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include non-persistent memory, random access memory (RAM), and/or non-volatile memory in a computer readable medium, such as read only memory (ROM) or flash memory. Memory is an example of a computer readable medium.

Computer readable media includes both permanent and non-persistent, removable and non-removable media. Information storage can be implemented by any method or technology. The information can be computer readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory. (ROM), electrically erasable programmable read only memory (EEPROM), flash memory or other memory technology, compact disk read only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, Magnetic tape cartridges, magnetic tape storage or other magnetic storage devices or any other non-transportable media can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary storage of computer readable media, such as modulated data signals and carrier waves.

It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and are not limited thereto; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that The technical solutions described in the foregoing embodiments are modified, or the equivalents of the technical features are replaced. The modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

A hardware abstraction layer multiplexing method, which is applied to a first process of a first operating system, including:

Retrieving a first application interface in a virtual hardware abstraction layer corresponding to the first operating system in response to a hardware operation instruction;

Sending, by the inter-process communication, the call request of the application program interface to the second operating system, so that the second process in the second operating system invokes the hardware abstraction layer corresponding to the second operating system according to the call request The second application program interface executes the hardware operation instruction;

The configuration of the first application program interface in the virtual hardware abstraction layer has a corresponding relationship with the configuration of the second application program interface in the hardware abstraction layer.
The method of claim 1, wherein the configuration of the first application interface in the virtual hardware abstraction layer is the same as the configuration of the second application program interface in the hardware abstraction layer.
The method of claim 1 further comprising:

Receiving a hardware operation result fed back by the second process.
The method of claim 3, wherein the hardware operation result comprises:

Hardware data generated by hardware that executes the hardware operation instructions; or a storage address of the hardware data in a shared memory; or an operation failure prompt information; wherein the hardware data and the storage address are The second process determines whether to send according to the data size of the hardware data; the operation failure prompt information is sent by the second process when determining that the hardware is busy.
A hardware abstraction layer multiplexing device, which is applied to a first process of a first operating system, and includes:

Calling a module, in response to the hardware operation instruction, calling a first application interface in the virtual hardware abstraction layer corresponding to the first operating system;

a sending module, configured to send, by using a cross-process communication, a call request of the first application program interface to a second operating system, so that a second process in the second operating system invokes the second The second application program interface in the hardware abstraction layer corresponding to the operating system executes the hardware operation instruction;

The configuration of the first application program interface in the virtual hardware abstraction layer has a corresponding relationship with the configuration of the second application program interface in the hardware abstraction layer.
An operating system, comprising: an application framework layer and a virtual hardware abstraction layer;

The application framework layer initiates a process for implementing the hardware abstraction layer multiplexing method according to any one of claims 1 to 3 in response to a hardware operation instruction;

The configuration of the application program interface in the virtual hardware abstraction layer has a corresponding relationship with the configuration of the application program interface in the hardware abstraction layer corresponding to another operating system.
An electronic device, comprising: a memory and a processor; wherein

The memory is for storing one or more computer instructions, wherein the one or more computer instructions are executed by the processor to implement the hardware abstraction layer multiplexing method according to any one of claims 1 to 3. .
A hardware abstraction layer multiplexing method, which is applied to a first process of a first operating system, including:

Receiving a call request sent by the second process in the second operating system by the cross-process communication, where the call request is the second process in the virtual hardware abstraction layer corresponding to the second operating system in response to the hardware operation instruction Triggered by an application interface;

And calling a second application program interface in the hardware abstraction layer corresponding to the first operating system to execute the hardware operation instruction according to the calling request;

The configuration of the first application program interface in the virtual hardware abstraction layer has a corresponding relationship with the configuration of the second application program interface in the hardware abstraction layer.
The method according to claim 8, wherein the second application interface in the hardware abstraction layer corresponding to the second operating system is invoked according to the call request to execute the hardware operation instruction, include:

If it is recognized that the second application program interface has an exclusive operation attribute, view a state of the hardware corresponding to the hardware abstraction layer;

If the state indicates that the hardware is in an idle state, the second application program interface is invoked according to the call request to execute the hardware operation instruction;

The state of the hardware is set to a busy state.
The method of claim 9 wherein the method further comprises:

If the status indicates that the hardware is in a busy state, the operation failure prompt information is sent to the first process.
The method according to claim 9, wherein if the second application interface is identified as having an exclusive operation attribute, the status of the hardware corresponding to the hardware abstraction layer is viewed, including:

If it is recognized that the second application interface has an exclusive operation attribute, and the second application interface is used to implement an opening operation on the hardware, view the state of the hardware.
The method of claim 11 wherein the method further comprises:

If it is recognized that the second application interface has an exclusive operation attribute, and the second application interface is used to implement a shutdown operation on the hardware, the state of the hardware is set to an idle state.
The method of claim 8 further comprising:

If it is recognized that the second application interface does not have an exclusive operation attribute, the second application interface is invoked according to the call request to execute the hardware operation instruction.
The method according to claim 9 or 13, wherein the method further comprises:

And feeding back the hardware operation result corresponding to the hardware operation instruction to the first process.
The method according to claim 14, wherein the feeding back the hardware operation result corresponding to the hardware operation instruction to the first process comprises:

And if the data amount of the hardware data generated by the hardware executing the hardware operation instruction is less than a preset threshold, sending the hardware data to the first process as the hardware operation result;

And if the data amount of the hardware data is greater than or equal to the preset threshold, storing the hardware data in a shared memory, and sending the storage address of the hardware data in the shared memory to the first process.
The method of claim 9 wherein the method further comprises:

Receiving a query request sent by the third process in the second operating system by using a cross-process communication, where the query request is used to query a state of the hardware;

Transmitting the state of the hardware to the third process to cause the third process to determine whether the hardware abstraction layer can be invoked according to the state.
A hardware abstraction layer multiplexing device, which is applied to a first process of a first operating system, and includes:

a receiving module, configured to receive a call request sent by the second process in the second operating system by using the cross-process communication, where the call request is that the second process invokes the virtual hardware corresponding to the second operating system in response to the hardware operation instruction Triggered by the first application interface in the abstraction layer;

a calling module, configured to invoke a second application program interface in a hardware abstraction layer corresponding to the second operating system according to the calling request, to execute the hardware operation instruction;

The configuration of the first application program interface in the virtual hardware abstraction layer has a corresponding relationship with the configuration of the second application program interface in the hardware abstraction layer.
An operating system, comprising:

An application framework layer and a cross-process communication interface, the application framework layer including a process for implementing the hardware abstraction layer multiplexing method according to any one of claims 8 to 16.
An electronic device, comprising: a memory and a processor; wherein

The memory is for storing one or more computer instructions, wherein the one or more computer instructions are executed by the processor to implement the hardware abstraction layer multiplexing method according to any one of claims 8 to 16. .