Process communication method, device and equipment based on Android / Linux fusion system

Abstract

The invention discloses a process communication method, device and equipment based on an Android / Linux fusion system, relates to the technical field of artificial intelligence, and is used for solving the technical problems of low communication efficiency, poor stability and the like existing in an existing cross-system communication mode. The method comprises the following steps of: sending a calling request to a Binder driver by adopting a Binder adaptation layer of a Linux system; according to a label of a target Binder service in the Android system, adopting a Binder driver to send the calling request to the target Binder service; the target Binder service is adopted to send the calling request to a target process in the Android system for service logic execution, and a calling result is obtained; according to the method, the target Binder service is adopted, and the calling result is fed back to the communication bridge in the Binder adaptation layer through the Binder driver, so that compared with an existing cross-system communication mode, the Binder adaptation layer and the Binder driver are introduced into the Linux system, bidirectional communication between the Android system and the Linux system is achieved, and the problems that communication between the systems is low in efficiency, poor in stability and the like are solved.

Description

Technical Field

[0001] The present application relates to the field of artificial intelligence technology, and provides a process communication method, device, and equipment based on an Android / Linux fusion system. Background Art

[0002] Currently, with the development of embedded devices and intelligent terminals, the scenario where the Android system and the Linux system coexist and work together has been widely applied. For example, in a vehicle-mounted system, the main control unit usually runs the Linux system to execute underlying tasks, while the human-computer interaction part uses the Android system to provide a rich interface and multimedia support; in Internet of Things devices, some edge computing devices need to collect and analyze data through the Linux system, and at the same time use the Android system to process user interaction and application ecology; in a smart home gateway, the gateway device may run the Android system to provide easy-to-use application support and the Linux system to achieve efficient data processing and protocol adaptation. Obviously, in these scenarios, efficient communication between the Android system and the Linux system has become a key requirement. However, in the current communication scenarios of these Android / Linux fusion systems, although there are already various implementation methods, there are still the following defects in terms of performance, complexity, and scalability: (1) The cross-system communication method between Android / Linux fusion systems is inefficient; (2) The existing cross-system communication methods have complex structures in design and implementation; (3) The existing cross-system communication methods do not support transparent Remote Procedure Call (RPC); (4) There are compatibility issues between the Android system and the Linux system; (5) The existing cross-system communication methods have poor scalability and adaptability; (6) The existing cross-system communication methods have insufficient security and stability; (7) The development cost is high. Summary of the Invention

[0003] The present application provides a process communication method, device, and equipment based on an Android / Linux fusion system, which are used to solve the technical problems such as low communication efficiency and poor stability existing in the existing cross-system communication methods.

[0004] On the one hand, a process communication method based on an Android / Linux fusion system is provided, and the method includes: The Binder adaptation layer using the Linux system sends the call request to the Binder driver; wherein, the call request contains the label of the target Binder service in the Android system; the Binder driver is set in the Linux kernel; According to the label, the Binder driver sends the call request to the target Binder service; The target Binder service is used to send the call request to the target process in the Android system for business logic execution to obtain a call result; The target Binder service is used to feedback the call result to the communication bridge in the Binder adaptation layer through the Binder driver.

[0005] Optionally, before the Binder adaptation layer using the Linux system sends the call request to the Binder driver, the method further includes: In the Linux system, the call request is seriallyized to obtain a seriallyized call request.

[0006] Optionally, before the Binder adaptation layer using the Linux system sends the call request to the Binder driver, the method further includes: The original Binder driver is transplanted into the Linux kernel; wherein, the Linux system and the Android system share the same Linux kernel; The original Binder driver is modified to obtain a modified Binder driver; wherein, the modified Binder driver supports being loaded as a standard character device in the Linux system and supports process registration and service mapping in the Linux system.

[0007] Optionally, before the Binder adaptation layer using the Linux system sends the call request to the Binder driver, the method further includes: In the Android system and the Linux system, a user space communication interface and a standard RPC call interface are respectively designed; A common data format and communication protocol are defined; wherein, the data exchange rules of the communication protocol include a message structure and a transmission method.

[0008] Optionally, before the Binder adaptation layer using the Linux system sends the call request to the Binder driver, the method further includes: Set up a Binder adaptation layer in the Linux system; wherein, a communication bridge and a permission verifier are set in the Binder adaptation layer; a permission verification mechanism and an access control mechanism are set in the permission verifier.

[0009] Optionally, before using the Binder adaptation layer of the Linux system to send a call request to the Binder driver, the method further includes: Obtain the user ID or process ID of the caller; wherein, the caller is the Linux system or the Android system; Determine whether there is a process in the predefined permission list that matches the user ID or process ID; If it is determined that there is a process in the predefined permission list that matches the user ID or process ID, it is determined that the caller has cross-system call permission.

[0010] Optionally, before using the Binder adaptation layer of the Linux system to send a call request to the Binder driver, the method further includes: When performing Binder service registration, determine whether the registrant meets the preset conditions through a preset Binder service registration mechanism; wherein, the registrant is the Linux system or the Android system; If it is determined that the registrant meets the preset conditions, perform Binder service registration on the registrant.

[0011] Optionally, before using the Binder adaptation layer of the Linux system to send a call request to the Binder driver, the method further includes: Determine whether the caller has a local authorization file through a preset local system authorization verification mechanism; wherein, the caller is the Linux system or the Android system; If it is determined that the caller has a local authorization file, it is determined that the caller has local system call permission.

[0012] On the one hand, provide a process communication device based on an Android / Linux integrated system, the device includes: A request sending unit, configured to use the Binder adaptation layer of the Linux system to send a call request to the Binder driver; wherein, the call request contains a label of a target Binder service in the Android system; the Binder driver is set in the Linux kernel; The request sending unit is further configured to send the call request to the target Binder service by using the Binder driver according to the label; A result acquisition unit, configured to send the call request to a target process in the Android system through the target Binder service for executing business logic, and acquire a call result; A result feedback unit, configured to feedback the call result to a communication bridge in the Binder adaptation layer through the Binder driver by using the target Binder service.

[0013] On the one hand, an electronic device is provided, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, any of the above methods is implemented.

[0014] On the one hand, a storage medium is provided, on which computer program instructions are stored. When the computer program instructions are executed by a processor, any of the above methods is implemented.

[0015] Compared with the prior art, the beneficial effects of the present application are as follows: In the present application, when performing cross-system process communication based on the Android / Linux integrated system, first, the Binder adaptation layer of the Linux system can be used to send a call request to the Binder driver; wherein, the call request contains a tag of a target Binder service in the Android system; the Binder driver is set in the Linux kernel; then, according to the tag, the Binder driver can be used to send the call request to the target Binder service; next, the target Binder service can be used to send the call request to a target process in the Android system for executing business logic to acquire a call result; finally, the target Binder service can be used to feedback the call result to a communication bridge in the Binder adaptation layer through the Binder driver.

[0016] Therefore, in the present application, since the Linux system is based on its own Binder adaptation layer and Binder driver to send a call request generated by itself to the Android system for process communication, and when performing call result feedback, it is also based on the Binder adaptation layer and Binder driver of the Linux system itself. Therefore, compared with existing cross-system communication methods such as Socket communication and shared memory communication, the present application establishes an efficient and stable two-way communication architecture between the Android system and the Linux system by making full use of the efficient communication mechanism of Binder, which can not only improve the efficiency of system collaborative work, but also provide a more flexible and stable communication solution for embedded devices and multi-system integration applications. And this also has important technical value and application prospects for multi-system collaborative intelligent terminals and industrial scenarios. Brief Description of the Drawings

[0017] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the following will briefly introduce the drawings required for use in the description of the embodiments or related technologies. Obviously, the drawings in the following description are only the embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on the provided drawings.

[0018] Figure 1 An electronic device provided by an embodiment of the present application; Figure 2 A schematic diagram of a process communication method based on an Android / Linux integrated system provided by an embodiment of the present application; Figure 3 A schematic diagram of an architecture based on an Android / Linux integrated system provided by an embodiment of the present application; Figure 4 Another schematic diagram of a process communication method based on an Android / Linux integrated system provided by an embodiment of the present application; Figure 5 A schematic diagram of a process communication device based on an Android / Linux integrated system provided by an embodiment of the present application.

[0019] Reference signs in the figure: 10 - Process communication device based on Android / Linux integrated system, 101 - Processor, 102 - Memory, 103 - I / O interface, 104 - Database, 50 - Process communication device based on Android / Linux integrated system, 501 - Request sending unit, 502 - Result obtaining unit, 503 - Result feedback unit, 504 - Data serialization unit, 505 - Integrated system design unit, 506 - Permission and access unit. Detailed Embodiments

[0020] To make the objectives, technical solutions, and advantages of the present application clearer and more understandable, the following will clearly and completely describe the technical solutions in the embodiments of the present application with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, rather than all of them. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts fall within the scope of protection of the present application. Without conflict, the embodiments in the present application and the features in the embodiments can be combined arbitrarily with each other. And although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order from here.

[0021] Currently, with the development of embedded devices and smart terminals, Android and Linux systems are gradually widely used in various scenarios. For example, the Android system dominates in smartphones, smart homes, and in-vehicle systems with its rich application ecosystem and user-friendly interface; while the Linux system is widely used in servers, industrial control, Internet of Things devices, etc. due to its openness, high efficiency, and stability. In addition, in actual applications, there are also a large number of scenarios where the Android system and the Linux system coexist and work together. For example, in an in-vehicle system, the main control unit usually runs the Linux system to execute underlying tasks, while the human-machine interaction part uses the Android system to provide a rich interface and multimedia support; in Internet of Things devices, some edge computing devices need to collect and analyze data through the Linux system, and at the same time use the Android system to handle user interaction and application ecosystem; in a smart home gateway, the gateway device may run the Android system to provide easy-to-use application support and the Linux system to achieve efficient data processing and protocol adaptation. Obviously, in these scenarios, efficient communication between the Android system and the Linux system becomes a key requirement.

[0022] However, in the current communication scenarios of these Android / Linux integrated systems, although there are already various implementation methods, there are still the following defects in terms of performance, complexity, and scalability: (1) Since existing communication methods such as Socket communication and file system transfer usually require additional serialization and deserialization processing, the cross-system communication method between the Android system and the Linux system is inefficient; (2) Due to problems such as high development difficulty and inconsistent interfaces, the existing cross-system communication methods are complex in design and implementation; (3) Since developers need to explicitly manage the sending and receiving of data, the existing cross-system communication methods do not support transparent remote procedure call (RPC); (4) Due to the lack of a direct mapping relationship between the AIDL interface definition of the Android system and the process communication mechanisms (such as message queues, semaphores, etc.) in the Linux system, there are compatibility issues between the Android system and the Linux system; (5) Facing the increasing application scenarios and communication requirements, as well as diverse hardware platforms (such as ARM, x86, etc.), the existing cross-system communication methods have poor scalability and adaptability; (6) Due to the lack of access control and permission verification, and the need for developers to manually manage the synchronization mechanism for shared memory, the existing cross-system communication methods have insufficient security and stability; (7) Due to the aforementioned communication efficiency and compatibility issues, developers need to invest more time and human resources in designing, developing, and debugging the communication mechanism, so the development cost is high.

[0023] Based on this, the embodiments of the present application provide a process communication method based on an Android / Linux fusion system. In this method, first, the Binder adaptation layer of the Linux system can be used to send a call request to the Binder driver; among them, the call request contains the label of the target Binder service in the Android system; the Binder driver is set in the Linux kernel; then, according to this label, the Binder driver can be used to send the call request to the target Binder service; next, the target Binder service can be used to send the call request to the target process in the Android system for business logic execution to obtain a call result; finally, the target Binder service can be used to feedback the call result to the communication bridge in the Binder adaptation layer through the Binder driver. Therefore, in the present application, since the Linux system is based on its own Binder adaptation layer and Binder driver to send the call requests generated by itself to the Android system for process communication, and when feedbacking the call result, it is also based on the Binder adaptation layer and Binder driver of the Linux system itself. Therefore, compared with the existing Socket communication and shared memory communication, the present application fully utilizes the efficient communication mechanism of Binder to establish an efficient and stable two-way communication architecture between the Android system and the Linux system, which can not only improve the efficiency of system collaborative work, but also provide a more flexible and stable communication solution for embedded devices and multi-system fusion applications. And this also has important technical value and application prospects for multi-system collaborative intelligent terminals and industrial scenarios.

[0024] After introducing the design concept of the embodiments of the present application, the following briefly introduces the application scenarios applicable to the technical solutions of the embodiments of the present application. It should be noted that the following introduced application scenarios are only used to illustrate the embodiments of the present application rather than limiting. In the specific implementation process, the technical solutions provided by the embodiments of the present application can be flexibly applied according to actual needs.

[0025] As Figure 1 shown, a kind of electronic device provided by the embodiments of the present application, and this electronic device can specifically be a process communication device 10 based on an Android / Linux fusion system.

[0026] Among them, the process communication device 10 based on the Android / Linux integrated system can perform cross-system process communication based on the Android / Linux integrated system. For example, it can be a personal computer (PC), a server, a laptop, etc. The process communication device 10 based on the Android / Linux integrated system may include one or more processors 101, a memory 102, an I / O interface 103, and a database 104. Specifically, the processor 101 can be a central processing unit (CPU), or a digital processing unit, etc. The memory 102 can be a volatile memory, such as a random-access memory (RAM); the memory 102 can also be a non-volatile memory, such as a read-only memory, a flash memory, a hard disk drive (HDD), or a solid-state drive (SSD); or the memory 102 is any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory 102 can be a combination of the above memories. In the memory 102, some program instructions of the process communication method based on the Android / Linux integrated system provided in the embodiments of the present application can be stored. When these program instructions are executed by the processor 101, they can be used to implement the steps of the process communication method based on the Android / Linux integrated system provided in the embodiments of the present application, so as to solve the technical problems such as low communication efficiency and poor stability existing in the existing cross-system communication methods. The database 104 can be used to store data such as Binder driver code and local authorization files involved in the solutions provided in the embodiments of the present application.

[0027] In the embodiments of the present application, the process communication device 10 based on the Android / Linux integrated system can obtain a process communication instruction through the I / O interface 103. Then, the processor 101 of the process communication device 10 based on the Android / Linux integrated system will solve the technical problems such as low communication efficiency and poor stability existing in the existing cross-system communication methods according to the code instructions of the process communication method based on the Android / Linux integrated system provided in the embodiments of the present application stored in the memory 102. In addition, data such as Binder driver code and local authorization files can also be stored in the database 104.

[0028] Such as Figure 2As shown, it is a schematic architecture diagram of a system provided by an embodiment of the present application based on an Android / Linux integrated system. Among them, the integrated system includes a Kernel Space and a User Space.

[0029] Specifically, the Kernel Space is a standard Linux kernel. The Linux system and the Android system share this Linux kernel, and a modified Binder driver and a kernel address space are set in this Linux kernel so that the Linux system has the ability to support Binder communication.

[0030] Based on this, in the actual communication process, the Linux system can cache relevant communication data in the kernel address space through the set Binder driver. Similarly, based on the memory mapping (mmap) mechanism, the Android system can also cache relevant communication data in this kernel address space through its own Binder service.

[0031] The User Space includes the respective process communication layers, physical memory, and a unified interface layer of the Linux system and the Android system. Among them, a Binder adaptation layer is also set in the process communication layer of the Linux system, and a communication bridge and a permission validator are also set in this Binder adaptation layer.

[0032] Based on this, in the actual communication process, the Linux user space can not only support process registration of Binder services, but also implement a Binder user space library to provide functions of an Android Interface Definition Language (AIDL) interface similar to that of the Android system, so that Linux applications can conveniently call Binder services.

[0033] The unified interface layer is used to encapsulate the communication details between the Linux system and the Android system to shield system differences.

[0034] In addition, the communication bridge in the Binder adaptation layer can be used to coordinate the communication between the processes at both ends of the Linux system and the Android system to ensure the consistency of data formats and call protocols. Moreover, this communication bridge also provides a transparent Remote Procedure Call (RPC) function so that the processes of the Linux system and the Android system can call the services of each other as if they were calling local methods.

[0035] Certainly, the method provided by the embodiments of the present application is not limited to Figure 1 the application scenarios shown, and can also be used in other possible application scenarios, which are not limited by the embodiments of the present application. The functions that can be achieved by each device in Figure 1 the application scenarios shown will be described together in the subsequent method embodiments, and will not be elaborated here too much. Next, the method of the embodiments of the present application will be introduced with reference to the accompanying drawings.

[0036] As Figure 3 shown, it is a schematic diagram of a process communication method based on an Android / Linux fusion system provided by the embodiments of the present application. This method can be executed through the Figure 2 Android / Linux fusion system architecture in. Specifically, when the Linux system calls the process of the Android system, the process of this method is introduced as follows.

[0037] Step 301: In the Linux system, serialize the call request data to obtain the serialized call request.

[0038] To improve communication efficiency, in the embodiments of the present application, AIDL or a custom protocol (used to define interfaces and data structures) can be used to serialize the call parameters of the call request in the Linux system, that is, serialize the call request into a unified binary format to facilitate cross-system transmission.

[0039] To perform more efficient communication, in the embodiments of the present application, Google ProtocolBuffers can also be used to serialize the call parameters of the call request in the Linux system.

[0040] To be applicable to scenarios of compatibility and readability, in the embodiments of the application, formats such as JSON and XML can also be used as the serialization protocol for data transmission, that is, formats such as JSON and XML can be used to serialize the call parameters of the call request in the Linux system.

[0041] In addition, for scenarios with high performance requirements, a compression algorithm (such as LZ4 and Snappy compression algorithms) can be used during the serialization process to reduce the amount of data.

[0042] For small-scale data transmission, direct transmission of binary data without serialization is allowed.

[0043] Step 302: Use the Binder adaptation layer of the Linux system to send the serialized call request to the Binder driver.

[0044] In the embodiments of the present application, the call request contains the label of the target Binder service in the Android system; the Binder driver is set in the Linux kernel.

[0045] Specifically, when the Binder adaptation layer receives the serialized call request, it will first parse the serialized call request in the communication bridge to determine the label of the target Binder service in the Android system that will perform cross-system process communication. Based on this, the Binder adaptation layer will send the serialized call request and the label of the target Binder service to the Binder driver together. As Figure 2 shown, this call-related data can be stored in the Binder buffer in the kernel address space to prepare for subsequent process calls.

[0046] Step 303: According to the label, use the Binder driver to send the serialized call request to the target Binder service.

[0047] In the embodiments of the present application, as Figure 2 shown, based on the mmap mechanism, according to the label, use the Binder driver to send the serialized call request to the target Binder service.

[0048] Step 304: Use the target Binder service to send the serialized call request to the target process in the Android system for business logic execution to obtain a call result.

[0049] In the embodiments of the present application, after obtaining the call result, based on the mmap mechanism, the call result can be mapped to the Binder map space in physical memory so that the user can directly access the relevant data.

[0050] Step 305: Use the target Binder service to feedback the call result to the communication bridge in the Binder adaptation layer through the Binder driver.

[0051] In the embodiments of the present application, after the communication bridge receives the call result, it can deserialize the call result into available data.

[0052] In a possible implementation, before using the Binder adaptation layer of the Linux system to send the call request to the Binder driver, "Binder driver transplantation" can also be performed.

[0053] Specifically, the original Binder driver of the Android system can be transplanted into the Linux kernel. Among them, the Linux system and the Android system share the same Linux kernel, and kernel adaptation is performed for the Advanced RISC Machines (ARM) of the target hardware platform.

[0054] Then, the original Binder driver can be modified to obtain a modified Binder driver. Among them, the modified Binder driver supports being loaded as a standard character device in the Linux system and supports process registration and service mapping in the Linux system.

[0055] That is, the driver interface of the original Binder driver can be modified so that the modified Binder driver can be loaded as a standard character device in the Linux system.

[0056] Moreover, in order to expand the functions, the Binder driver can be modified to support process registration and service mapping in the Linux system; and the memory allocation and queue management logic in the Binder driver can be optimized to support high-frequency communication requirements.

[0057] In a possible implementation manner, before the Binder adaptation layer of the Linux system sends a call request to the Binder driver, "user space interface development" can also be performed.

[0058] Specifically, user space communication interfaces can be designed in the Android system and the Linux system respectively to encapsulate the details of Binder calls; and a standard RPC call interface can be provided so that developers can implement cross-system communication through simple function calls.

[0059] Then, a common data format and communication protocol can be defined to ensure that the Android system and the Linux system can correctly parse the data sent by each other. Among them, the data exchange rules of the communication protocol include the message structure and the transmission method. In the embodiments of the present application, in order to ensure the orderliness and reliability of data transmission, the message structure is specifically as follows: Message header (Header): Used to store additional detailed information; Message type (type): Used to identify the purpose of the message (such as request, response); Message length (length): Used to record the number of bytes of the message body; Sequence number (seq): Used to match requests and responses; Timestamp (timestamp): Used to record the sending time; Message body (Body): Used to transmit serialized data.

[0060] In a possible implementation, before the Binder adaptation layer of the Linux system sends a call request to the Binder driver, a "two-way communication bridge" can also be designed.

[0061] Specifically, a Binder adaptation layer can be set up in the Linux system; among them, a communication bridge and a permission verifier are set in the Binder adaptation layer; a permission verification mechanism and an access control mechanism are set in the permission verifier. That is, a bridge service can be introduced between the Android system and the Linux system to coordinate the communication between the Linux system and the Android system. Among them, the bridge service is registered as a system service through the Binder driver in the Android system and exposes an interface through the Binder adaptation layer on the Linux side.

[0062] In addition, the bridge service can also implement data routing and call management, that is, after the bridge service receives a call request from the Android system or the Linux system, it can convert the call request into a format that the target system can understand. Of course, to ensure the integrity of two-way communication, the bridge service can also implement a mechanism for returning call results.

[0063] In a possible implementation, before the Binder adaptation layer of the Linux system sends a call request to the Binder driver, "cross-system permission management" can also be performed.

[0064] Specifically, first, the user ID (UID) or process ID (PID) of the caller can be obtained; among them, the caller is the Linux system or the Android system; then, it can be determined whether there is a process in the predefined permission list that matches the user ID or process ID; next, if it is determined that there is a process in the predefined permission list that matches the user ID or process ID, it is determined that the caller has cross-system call permission; otherwise, it is determined that the caller does not have cross-system call permission. For example, maintaining a whitelist of authorized processes, then only processes in the whitelist that match the UID or PID can pass the permission verification. That is, this application introduces a permission verification mechanism for the communication process to ensure that only authorized processes can initiate cross-system calls.

[0065] In a possible implementation, before the Binder adaptation layer of the Linux system sends a call request to the Binder driver, "access control" can also be performed.

[0066] Specifically, when performing Binder service registration, first, through a preset Binder service registration mechanism, it can be determined whether the registrant meets the preset conditions; where the registrant is a Linux system or an Android system; then, if it is determined that the registrant meets the preset conditions, Binder service registration can be performed on the registrant; otherwise, it means that the registrant cannot perform Binder service registration. That is, through the service registration mechanism, it can be ensured that only authorized systems and processes can register and access specific Binder services, preventing unauthorized processes from accessing sensitive data. Based on this, during service registration, the system will check the identity of the registrant, and only eligible systems can successfully register the service.

[0067] In a possible implementation manner, before the Binder adaptation layer of the Linux system sends a call request to the Binder driver, "local system permission management" can also be performed.

[0068] Specifically, through a preset local system authorization verification mechanism, it can be determined whether the caller has a local authorization file; where the caller is a Linux system or an Android system; then, if it is determined that the caller has a local authorization file, it can be determined that the caller has local system call permission; otherwise, it can be determined that the caller does not have local system call permission, so the call needs to be rejected. That is, this application adds a local authorization verification mechanism to verify whether the local system has the permission to initiate a call before cross-system calls occur.

[0069] In a possible implementation manner, the above "cross-system permission management", "access control", and "local system permission management" are all integrated into the Binder adaptation layer for easy checking during the communication process. Based on this, by centrally managing security policies and permission rules, this application can not only improve the security and stability of the system, but also simplify the development process and improve communication efficiency.

[0070] In a possible implementation manner, in addition to enabling the Linux system to have Binder functionality by transplanting the "Binder driver", a custom driver with similar Binder functionality can also be implemented based on the existing Linux Inter-Process Communication (IPC), for example, a custom driver with similar Binder functionality can be implemented based on inter-process communication such as message queues, shared memory, or semaphores.

[0071] Moreover, for kernel features of different hardware platforms (e.g., ARM64, x86_64, etc.), different memory management strategies can be selected. For example, for the kernel features of the hardware platform ARM64, the memory allocation mechanism of the Binder driver can be optimized. For example, the data buffer size can be dynamically adjusted (16KB - 64KB, default 32KB) to meet the requirements of different application scenarios.

[0072] In a possible implementation, in addition to designing a communication bridge to coordinate process communication between the Android system and the Linux system, a kernel module can also be directly designed in the kernel space to directly interact with the Binder driver to reduce the context switching overhead in the user space.

[0073] In a possible implementation, this application supports a caching strategy, that is, for frequently called interfaces, a result caching mechanism can be added to the communication bridge to reduce repeated calculations and communication delays.

[0074] In a possible implementation, this application also supports dynamic load balancing, that is, in a multi-core system, the communication bridge is allowed to dynamically allocate resources according to the load to improve the concurrent performance.

[0075] In a possible implementation, this application also supports a Transport Layer Security (TLS) encryption channel to ensure the confidentiality and integrity of data during the communication process.

[0076] In another possible implementation, when the Android system invokes a process of the Linux system, as Figure 4 shown, it is another schematic diagram of the process communication method provided by the embodiment of this application based on the Android / Linux integrated system. This method can be executed through the Figure 2 Android / Linux integrated system architecture. Specifically, the process of this method is introduced as follows.

[0077] Step 401: In the Android system, serialize the call request to obtain the serialized call request.

[0078] Step 402: Use the Binder service of the Android system to send the serialized call request to the Binder driver.

[0079] Step 403: According to the label indicating the target Binder service in the Linux system in the serialized call request, use the Binder driver to send the serialized call request to the target Binder service through the communication bridge in the adaptation layer.

[0080] Step 404: Use the target Binder service to send the serialized call request to the target process in the Linux system for business logic execution, and obtain the call result.

[0081] Step 505: Use the target Binder service to feedback the call result to the Binder service of the Android system through the communication bridge in the adaptation layer and the Binder driver in sequence.

[0082] In summary, the present application has the following advantages: (1) Between the Android system and the Linux system, since data transmission is carried out using the Binder driver, multiple data copies in traditional IPC (such as Socket communication) are avoided. Therefore, the present application can share data through memory mapping, reduce the number of data switches between the user space and the kernel space, which greatly reduces communication latency and improves communication efficiency.

[0083] In addition, the present application also supports efficient Protocol Buffers or direct transmission of binary data through data serialization.

[0084] (2) Since the present application not only combines the UID / PID verification mechanism and local system permission verification to perform identity verification on both communication parties, but also uses a TLS encryption channel to ensure the confidentiality and integrity of data during communication. Therefore, the present application prevents unauthorized access, that is, only processes that have passed permission authentication can access the interface, which greatly reduces the risk of being maliciously attacked and enhances security.

[0085] (3) Since the present application not only realizes the unification of the communication protocol between Android Binder and the Linux system through the communication bridge, shielding the underlying driver differences, but also provides API interfaces for developers to call to implement high-level abstract communication logic. Therefore, developers do not need to deeply understand the underlying communication mechanism and only need to call the unified interface to complete data transmission, which greatly simplifies the complexity of cross-platform communication and reduces the development cost.

[0086] (4) Since the present application can dynamically allocate memory buffers, the present application can support load balancing during communication, avoid resource contention or deadlocks in high-concurrency scenarios, and improve the stability of the system. Moreover, since a result caching mechanism is added to the communication bridge, the present application can also reduce repeated calculations and communication conflicts.

[0087] Based on the same inventive concept, an embodiment of the present application provides a process communication device 50 based on an Android / Linux integrated system, asFigure 5 As shown in the figure, the process communication device 50 based on the Android / Linux integrated system includes: A request sending unit 501, configured to send a call request to the Binder driver by using the Binder adaptation layer of the Linux system; wherein, the call request contains a label of a target Binder service in the Android system; the Binder driver is set in the Linux kernel; The request sending unit 501 is further configured to send the call request to the target Binder service by using the Binder driver according to the label; A result obtaining unit 502, configured to send the call request to a target process in the Android system for business logic execution by using the target Binder service, and obtain a call result; A result feedback unit 503, configured to feedback the call result to a communication bridge in the Binder adaptation layer through the Binder driver by using the target Binder service.

[0088] Optionally, the process communication device 50 based on the Android / Linux integrated system further includes a data serialization unit 504, configured to: In the Linux system, perform data serialization on the call request to obtain a serialized call request.

[0089] Optionally, the process communication device 50 based on the Android / Linux integrated system further includes an integrated system design unit 505, configured to: Port the original Binder driver to the Linux kernel; wherein, the Linux system and the Android system share the same Linux kernel; Modify the original Binder driver to obtain a modified Binder driver; wherein, the modified Binder driver supports being loaded as a standard character device in the Linux system, and supports process registration and service mapping in the Linux system.

[0090] Optionally, the integrated system design unit 505 is further configured to: Respectively design a user space communication interface and a standard RPC call interface in the Android system and the Linux system; Define a common data format and a communication protocol; wherein, the data exchange rules of the communication protocol include a message structure and a transmission method.

[0091] Optionally, the integrated system design unit 505 is further configured to: Set up a Binder adaptation layer in the Linux system; wherein, a communication bridge and a permission verifier are set in the Binder adaptation layer; a permission verification mechanism and an access control mechanism are set in the permission verifier.

[0092] Optionally, the process communication device 50 based on the Android / Linux integrated system further includes a permission and access unit 506, which is used for: Obtain the user ID or process ID of the caller; wherein, the caller is the Linux system or the Android system; Determine whether there is a process in the predefined permission list that matches the user ID or process ID; If it is determined that there is a process in the predefined permission list that matches the user ID or process ID, then determine that the caller has cross-system call permission.

[0093] Optionally, the permission and access unit 506 is further used for: When performing Binder service registration, determine whether the registrant meets the preset conditions through a preset Binder service registration mechanism; wherein, the registrant is the Linux system or the Android system; If it is determined that the registrant meets the preset conditions, then perform Binder service registration on the registrant.

[0094] Optionally, the permission and access unit 506 is further used for: Determine whether the caller has a local authorization file through a preset local system authorization verification mechanism; wherein, the caller is the Linux system or the Android system; If it is determined that the caller has a local authorization file, then determine that the caller has local system call permission.

[0095] The process communication device 50 based on the Android / Linux integrated system can be used to execute Figures 3 - 4 the method executed in the embodiments shown, therefore, for the functions that can be realized by each functional module of the process communication device 50 based on the Android / Linux integrated system, reference can be made to Figures 3 - 4 the description of the embodiments shown, which will not be elaborated here.

[0096] In some possible implementation manners, each aspect of the method provided in this application can also be implemented in the form of a program part, which includes program code. When the program part runs on a computer device, the program code is used to cause the computer device to execute the steps in the method according to various exemplary implementation manners of this application described above in this specification. For example, the computer device can execute the method executed in the embodiments shown in Figures 3 - 4 the embodiments shown.

[0097] Those of ordinary skill in the art can understand that all or part of the steps to implement the above method embodiments can be completed by hardware related to program instructions. The foregoing program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps including those of the above method embodiments. The foregoing storage medium includes: various media that can store program codes, such as removable storage devices, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical discs. Alternatively, if the above integrated units of the present invention are implemented in the form of software functional modules and sold or used as independent components, they can also be stored in a computer-readable storage medium. Based on such understanding, the technical solutions of the embodiments of the present invention, in essence or the part that contributes to the prior art, can be embodied in the form of software components. The computer software components are stored in a storage medium and include several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the methods described in the various embodiments of the present invention. The foregoing storage medium includes: various media that can store program codes, such as removable storage devices, ROM, RAM, magnetic disks, or optical discs.

[0098] Although the preferred embodiments of the present application have been described, those skilled in the art can make additional changes and modifications to these embodiments once they learn the basic creative concept. Therefore, the appended claims are intended to be construed as including the preferred embodiments and all changes and modifications that fall within the scope of the present application.

[0099] Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalent technologies, the present application is also intended to include these changes and modifications.

Claims

1. A process communication method based on an Android / Linux integrated system, characterized in that, The method includes: Using the Binder adaptation layer of the Linux system to send a call request to the Binder driver; wherein, the call request contains the label of the target Binder service in the Android system; the Binder driver is set in the Linux kernel; According to the label, using the Binder driver to send the call request to the target Binder service; Using the target Binder service to send the call request to the target process in the Android system for business logic execution to obtain a call result; Using the target Binder service to feedback the call result to the communication bridge in the Binder adaptation layer through the Binder driver.

2. The method according to claim 1, characterized in that, Before using the Binder adaptation layer of the Linux system to send a call request to the Binder driver, the method further includes: In the Linux system, serializing the data of the call request to obtain a serialized call request.

3. The method according to claim 1, characterized in that Before using the Binder adaptation layer of the Linux system to send a call request to the Binder driver, the method further includes: Porting the original Binder driver to the Linux kernel; wherein, the Linux system and the Android system share the same Linux kernel; Modifying the original Binder driver to obtain a modified Binder driver; wherein, the modified Binder driver supports being loaded as a standard character device in the Linux system and supports process registration and service mapping in the Linux system.

4. The method according to claim 1, characterized in that, Before using the Binder adaptation layer of the Linux system to send a call request to the Binder driver, the method further includes: In the Android system and the Linux system, designing a user space communication interface and a standard RPC call interface respectively; Defining a common data format and communication protocol; wherein, the data exchange rules of the communication protocol include a message structure and a transmission method.

5. The method according to claim 1, wherein Before using the Binder adaptation layer of the Linux system to send a call request to the Binder driver, the method further includes: Setting up a Binder adaptation layer in the Linux system; wherein, a communication bridge and a permission verifier are set in the Binder adaptation layer; a permission verification mechanism and an access control mechanism are set in the permission verifier.

6. The method according to claim 1, characterized in that Before using the Binder adaptation layer of the Linux system to send a call request to the Binder driver, the method further includes: Obtaining the user ID or process ID of the calling party; wherein, the calling party is the Linux system or the Android system; Determining whether there is a process in the predefined permission list that matches the user ID or process ID; If it is determined that there is a process in the predefined permission list that matches the user ID or process ID, it is determined that the calling party has cross-system call permission.

7. The method according to claim 1, wherein Before the Binder adaptation layer using the Linux system sends the call request to the Binder driver, the method further includes: When performing Binder service registration, determine whether the registrant meets the preset conditions through a preset Binder service registration mechanism; wherein, the registrant is the Linux system or the Android system; If it is determined that the registrant meets the preset conditions, perform Binder service registration on the registrant.

8. The method according to claim 1, wherein Before the Binder adaptation layer using the Linux system sends the call request to the Binder driver, the method further includes: Determine whether the caller has a local authorization file through a preset local system authorization verification mechanism; wherein, the caller is the Linux system or the Android system; If it is determined that the caller has a local authorization file, determine that the caller has local system call permissions.

9. A process communication device based on an Android / Linux integrated system, characterized in that, The device includes: A request sending unit, configured to use the Binder adaptation layer of the Linux system to send a call request to the Binder driver; wherein, the call request contains the label of the target Binder service in the Android system; the Binder driver is set in the Linux kernel; The request sending unit is further configured to send the call request to the target Binder service using the Binder driver according to the label; A result obtaining unit, configured to use the target Binder service to send the call request to the target process in the Android system for business logic execution to obtain a call result; A result feedback unit, configured to use the target Binder service to feedback the call result to the communication bridge in the Binder adaptation layer through the Binder driver.

10. An electronic device, characterized in that, The device includes: A memory, configured to store program instructions; A processor, configured to call the program instructions stored in the memory and execute the method according to any one of claims 1-8 according to the obtained program instructions.

Images