A binder driver device connection method, apparatus, device and medium

Abstract

The application discloses a binder driving device connection method, device, equipment and medium, and relates to the technical field of computers.The method comprises the following steps: after a target container is started, the target device identification number of a target binder driving device allocated in advance for the target container is acquired; the device information of the target binder driving device is obtained according to the target device identification number; and the target device file corresponding to the target binder driving device is created based on the device information, so that an application program connects the target binder driving device through the target device file.The application program can directly connect the target binder driving device by using the target device file created in the target container, without modifying the libbinder source code, so that the process is more simple and fast.The application does not need to pay attention to the environment variable, so that the situation that an incorrect driving device is connected by using an incorrect device file due to the environment variable is avoided, and therefore the correctness of binder driving device connection is improved, the isolation effect between containers is realized, and the inter-process communication is normal.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a binder driver device connection method, apparatus, device, and medium. Background Technology

[0002] Binder is a framework in the Android system that implements inter-process communication. The Binder framework consists of a kernel-level driver, application-level interface libraries, and a service manager. A basic diagram illustrating the principles of Binder communication is shown below. Figure 1 As shown, the server registers its name with the service manager, and the client obtains the corresponding service through the service manager. The server, client, and service manager all use libbinder to open and connect to the binder driver. When opening the driver, the user needs to specify the path to the binder driver file, such as / dev / binder, which works correctly in a single-system environment. To support multiple Android container environments, the binder driver generates multiple device files, each representing a binder driver instance.

[0003] Different Android containers use different driver devices. A typical implementation is as follows: 1. Before starting the Android container, find an idle binder driver device and pass its name to the container via an environment variable; 2. Modify the libbinder source code so that when the application calls libbinder to open the binder driver, it first reads the driver device name environment variable and opens the driver device based on the obtained name. A diagram illustrating a correct binder driver device connection is shown below. Figure 2 As shown, container 1 is connected to the / dev / binder driver, and container 2 is connected to the / dev / binder1 driver.

[0004] However, environment variables are obtained by the application that calls libbinder, but the application may overwrite or clear environment variables. This can cause libbinder to open an incorrect binder driver, ultimately leading to communication errors. In a specific embodiment, a diagram illustrating an incorrect binder driver device connection is shown below. Figure 3 As shown, container 1 connects to the / dev / binder driver. The client process in container 2 clears the environment variable BINDID. When the client calls the libbinder library to open the binder driver, it mistakenly opens the / dev / binder driver that belongs to container 1, thus connecting to the server process in container 1. This results in the loss of the isolation effect between containers, further causing abnormal inter-process communication.

[0005] In summary, improving the correctness of binder driver device connections to achieve isolation between containers and further ensure normal inter-process communication is an urgent problem to be solved. Summary of the Invention

[0006] In view of this, the purpose of this invention is to provide a binder driver device connection method, apparatus, device, and medium, which can improve the correctness of binder driver device connection, thereby achieving isolation between containers and further enabling normal inter-process communication. The specific solution is as follows:

[0007] In a first aspect, this application discloses a binder driver device connection method, including:

[0008] After the target container starts, it obtains the target device identifier of the target binder driver device that has been pre-assigned to the target container;

[0009] Obtain the device information of the target binder driver device based on the target device identifier;

[0010] Based on the device information, a target device file corresponding to the target binder driver device is created, so that the application can connect to the target binder driver device through the target device file.

[0011] Optionally, the target device identifier is the identifier of the target binder driver device selected from idle binder driver devices before the target container starts.

[0012] Optionally, after the target container starts, it obtains the target device identifier of the target binder driver device pre-assigned to the target container, including:

[0013] After the target container starts, it reads the target identifier file that has been pre-mounted to the target container to obtain the target device identifier of the target binder driver device that has been pre-assigned to the target container; the target identifier file is a file used to store the target device identifier and mount it to the target container before the target container starts.

[0014] Optionally, obtaining the device information of the target binder driver device based on the target device identifier includes:

[0015] Based on the target device identifier, a preset device file corresponding to the target binder driver device is determined from the target container, and the device information of the target binder driver device is obtained based on the preset device file.

[0016] Optionally, determining the preset device file corresponding to the target binder driver device from the target container includes:

[0017] The preset device file corresponding to the target binder driver device is determined from the device files corresponding to different preset binder driver devices pre-stored in the target container.

[0018] Optionally, the step of creating a target device file corresponding to the target binder driver device based on the device information, so that the application can connect to the target binder driver device through the target device file, includes:

[0019] Based on the device information, a target device file corresponding to the target binder driver device is created and replaces the original device file in the target container, so that the application can connect to the target binder driver device through the target device file.

[0020] Optionally, the step of creating a target device file corresponding to the target binder driver device based on the device information and replacing the original device file in the target container, so that the application can connect to the target binder driver device through the target device file, includes:

[0021] Delete the original device file in the target container;

[0022] Based on the device information, a target device file corresponding to the target binder driver device is created, and the target device file is written into the target container so that the application can connect to the target binder driver device through the target device file.

[0023] Secondly, this application discloses a binder driver device connection device, comprising:

[0024] The identifier acquisition module is used to acquire the target device identifier of the target binder driver device that has been pre-assigned to the target container after the target container starts.

[0025] The device information acquisition module is used to obtain the device information of the target binder driver device based on the target device identifier.

[0026] The target device file creation module is used to create a target device file corresponding to the target binder driver device based on the device information, so that the application can connect to the target binder driver device through the target device file.

[0027] Thirdly, this application discloses an electronic device, including:

[0028] Memory, used to store computer programs;

[0029] A processor is configured to execute the computer program to implement the aforementioned disclosed binder driver device connection method.

[0030] Fourthly, this application discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned disclosed binder driver device connection method.

[0031] As can be seen, after the target container of this application starts, it obtains the target device identifier of the target binder driver device pre-assigned to the target container; obtains the device information of the target binder driver device based on the target device identifier; and creates a target device file corresponding to the target binder driver device based on the device information, so that the application can connect to the target binder driver device through the target device file. Therefore, this application directly creates the target device file corresponding to the binder driver device in the target container, and the application can directly use the target device file to connect to the target binder driver device without modifying the libbinder source code, making the process simpler and faster. Furthermore, this application does not need to pay attention to environment variables, that is, it does not need to determine the driver device through environment variables, thus avoiding the situation of connecting to the wrong driver device using the wrong device file due to the clearing of environment variables. This improves the correctness of binder driver device connection, achieving isolation between containers and further ensuring normal inter-process communication. Attached Figure Description

[0032] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0033] Figure 1 This is a schematic diagram illustrating the basic principle of binder communication disclosed in this application;

[0034] Figure 2 This is a schematic diagram illustrating the correct connection of a binder driver device as disclosed in this application;

[0035] Figure 3 This is a schematic diagram of an incorrect connection of a binder driver device disclosed in this application;

[0036] Figure 4This is a flowchart of a binder driver device connection method disclosed in this application;

[0037] Figure 5 This application discloses a specific flowchart of a binder driver device connection method;

[0038] Figure 6 This is a schematic diagram of a binder driver device connection disclosed in this application;

[0039] Figure 7 This is a schematic diagram of a binder driver device connection device disclosed in this application;

[0040] Figure 8 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation

[0041] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0042] Different Android containers use different driver devices. A typical implementation is as follows: 1. Before starting the Android container, find an idle binder driver device and pass its name to the container via an environment variable; 2. Modify the libbinder source code so that when the application calls libbinder to open the binder driver, it first reads the driver device name environment variable and opens the driver device based on the obtained name. A diagram illustrating a correct binder driver device connection is shown below. Figure 2 As shown, container 1 is connected to the / dev / binder driver, and container 2 is connected to the / dev / binder1 driver.

[0043] However, environment variables are obtained by the application that calls libbinder, but the application may overwrite or clear environment variables. This can cause libbinder to open an incorrect binder driver, ultimately leading to communication errors. In a specific embodiment, a diagram illustrating an incorrect binder driver device connection is shown below. Figure 3As shown, container 1 connects to the / dev / binder driver. The client process in container 2 clears the environment variable BINDID. When the client calls the libbinder library to open the binder driver, it mistakenly opens the / dev / binder driver that belongs to container 1, thus connecting to the server process in container 1. This results in the loss of the isolation effect between containers, further causing abnormal inter-process communication.

[0044] Therefore, this application proposes a binder driver device connection scheme, which can improve the correctness of binder driver device connection, so as to achieve the isolation effect between containers and further enable normal inter-process communication.

[0045] This application discloses a binder driver device connection method. See also Figure 4 As shown, the method includes:

[0046] Step S11: After the target container starts, obtain the target device identifier of the target binder driver device that has been pre-assigned to the target container.

[0047] In this embodiment of the application, the target device identifier is the identifier of the target binder driver device selected from the idle binder driver devices before the target container starts.

[0048] It should be noted that before the target container starts, different device identifiers need to be assigned to different binder driver devices. It is also necessary to match an idle target binder driver device for the target container so that after the target container starts, the init process can obtain the target device identifier of the target binder driver device pre-assigned to the target container. It should be noted that the operation of matching an idle target binder driver device for the target container can be done manually or automatically by the Android system.

[0049] In this embodiment of the application, after the target container starts, obtaining the target device identifier of the target binder driver device pre-assigned to the target container includes: after the target container starts, reading the target identifier file pre-mounted to the target container to obtain the target device identifier of the target binder driver device pre-assigned to the target container; the target identifier file is a file used to store the target device identifier and mount it to the target container before the target container starts.

[0050] It should be noted that before the target container starts, in order to facilitate obtaining the target device identifier of the target binder driver device pre-assigned to the target container, the target device identifier of the target binder driver device pre-assigned to the target container needs to be stored in the target identifier file, and then the target identifier file is mounted to the target container.

[0051] Understandably, in existing methods, the selection of the binder driver is completed based on environment variables when the application opens the driver. However, in this application, the selection of the binder driver is done before the container starts. Specifically, the selection of the container's binder driver can be completed when the container is first created. That is, the binder driver is allocated to the container when it is first created, the device identifier of the allocated binder driver is written to the identifier file, and the identifier file is mounted to the corresponding container.

[0052] It should be noted that the device identifier set for different binder driver devices can be in the form of numbers and letters.

[0053] Step S12: Obtain the device information of the target binder driver device based on the target device identifier.

[0054] In this embodiment, the device information includes the target major device number and the target minor device number of the target binder driver device. It should be noted that in the Android system kernel driver, each binder driver device is associated with a set of major and minor device numbers at the underlying level. Different binder driver devices have the same major device number but different minor device numbers.

[0055] It should be noted that the step of obtaining the device information of the target binder driver device based on the target device identifier is completed by the init process.

[0056] Step S13: Create a target device file corresponding to the target binder driver device based on the device information, so that the application can connect to the target binder driver device through the target device file.

[0057] In this embodiment of the application, the step of creating the target device file corresponding to the target binder driver device based on the device information is completed by the init process.

[0058] In this embodiment of the application, the application opens the target device file through libbinder to connect to the target binder driver device.

[0059] As can be seen, after the target container of this application starts, it obtains the target device identifier of the target binder driver device pre-assigned to the target container; obtains the device information of the target binder driver device based on the target device identifier; and creates a target device file corresponding to the target binder driver device based on the device information, so that the application can connect to the target binder driver device through the target device file. Therefore, this application directly creates the target device file corresponding to the binder driver device in the target container, and the application can directly use the target device file to connect to the target binder driver device without modifying the libbinder source code, making the process simpler and faster. Furthermore, this application does not need to pay attention to environment variables, that is, it does not need to determine the driver device through environment variables, thus avoiding the situation of connecting to the wrong driver device using the wrong device file due to the clearing of environment variables. This improves the correctness of binder driver device connection, achieving isolation between containers and further ensuring normal inter-process communication.

[0060] This application discloses a specific method for connecting a binder driver device. Compared to the previous embodiment, this embodiment further explains and optimizes the technical solution. See also... Figure 5 As shown, it specifically includes:

[0061] Step S21: After the target container starts, obtain the target device identifier of the target binder driver device that has been pre-assigned to the target container.

[0062] For a more detailed description of the process of step S21, please refer to the relevant content disclosed in the foregoing embodiments, which will not be repeated here.

[0063] Step S22: Based on the target device identifier, determine the preset device file corresponding to the target binder driver device from the target container, and obtain the device information of the target binder driver device based on the preset device file.

[0064] In this embodiment of the application, determining the preset device file corresponding to the target binder driver device from the target container includes: determining the preset device file corresponding to the target binder driver device from the device files corresponding to different preset binder driver devices pre-stored in the target container. It should be noted that the target container pre-stores device files corresponding to different preset binder driver devices, and these device files store the device information of the corresponding binder driver devices. However, the target container can only use one binder driver device; therefore, it is necessary to determine the device file corresponding to that driver device, that is, to determine the preset device file corresponding to the target binder driver device.

[0065] Step S23: Create a target device file corresponding to the target binder driver device based on the device information, and replace the original device file in the target container, so that the application can connect to the target binder driver device through the target device file.

[0066] In this embodiment, the application opens the target device file via libbinder to connect to the target binder driver device. It should be noted that the original device file is a device file located in the default location accessed by libbinder. In this application, the default location accessed by libbinder remains unchanged. Therefore, by using the target device file to replace the original device file in the default location, the application can open the target device file to connect to the target binder driver device when accessing the default location via libbinder.

[0067] In one specific embodiment, the step of creating a target device file corresponding to the target binder driver device based on the device information and replacing the original device file in the target container, so that the application can connect to the target binder driver device through the target device file, includes: deleting the original device file in the target container; creating a target device file corresponding to the target binder driver device based on the device information and writing the target device file into the target container, so that the application can connect to the target binder driver device through the target device file. It should be noted that this application can achieve the purpose of replacing the original device file in the target container by deleting the original device file in the default location and storing the target device file in the default location. It should also be noted that the filenames of the target device file and the original device file may or may not be the same.

[0068] In another specific embodiment, the original device file in the target container can be directly set to be unopenable; a target device file corresponding to the target binder driver device is created based on the device information, and the target device file is written into the target container, so that the application can connect to the target binder driver device through the target device file. Specifically, the original device file in the default folder at the default location is set to be unopenable, and the target device file is stored in the default folder to replace the original device file in the target container. It should be noted that the filenames of the target device file and the original device file can be different. It should also be noted that files in the default folder can be read, so the original device file needs to be set to be unopenable to ensure that the target device file is opened instead.

[0069] As can be seen, this application directly creates the target device file corresponding to the binder driver device in the target container. The application can directly use the target device file to connect to the target binder driver device without modifying the libbinder source code, making the process simpler and faster. In addition, this application does not need to pay attention to environment variables, that is, it does not need to determine the driver device through environment variables. Therefore, it avoids the situation of connecting to the wrong driver device using the wrong device file due to the clearing of environment variables. This can improve the correctness of binder driver device connection, so as to achieve the isolation effect between containers and further enable normal inter-process communication.

[0070] See Figure 6 The diagram shows a schematic of the binder driver device connection. In the diagram, the default location and filenames of libbinder access in containers 1 and 2 remain unchanged, but the device information within the files changes. Figure 6 One specific implementation process of this solution in the case of [the specific situation] is as follows:

[0071] Prerequisite steps: Select an idle target binder driver device (assuming there are 5 binder driver devices in total, select driver device 1), write the target identifier of the idle target binder driver device into the file bindid (target identifier file), and then mount the bindid file into the target container;

[0072] Step 1: Start the target container;

[0073] Step 2: Run the init process. The init process reads the bindid file and obtains the target identifier of the target binder driver device assigned to the target container, i.e., driver device 1.

[0074] Step 3: The init process analyzes / sys / class / misc / binder1 / dev (the default device file / dev / binder1 of the target binder driver device stored in the target container) based on the target identifier to obtain the major and minor numbers of the target binder driver device.

[0075] Step 4: The init process deletes the original device file / dev / binder in the default location;

[0076] Step 5: The init process calls mknod(" / dev / binder", S_IFCHR|0666, makedev(major, minor)) to create the target device file. That is, it calls the major and minor numbers in step 3 to create the target device file so that the application can open / dev / binder through libbinder, which is actually equivalent to opening / dev / binder1. The target device file has the same name as the original device file, which is still / dev / binder.

[0077] Accordingly, embodiments of this application also disclose a binder driver device connection device, see [link to relevant documentation]. Figure 7 As shown, the device includes:

[0078] The identifier acquisition module 11 is used to acquire the target device identifier of the target binder driver device that has been pre-assigned to the target container after the target container starts.

[0079] Device information acquisition module 12 is used to obtain device information of the target binder driver device according to the target device identifier;

[0080] The target device file creation module 13 is used to create a target device file corresponding to the target binder driver device based on the device information, so that the application can connect to the target binder driver device through the target device file.

[0081] For more detailed information on the working process of each of the above modules, please refer to the relevant content disclosed in the foregoing embodiments, which will not be repeated here.

[0082] As can be seen, after the target container of this application starts, it obtains the target device identifier of the target binder driver device pre-assigned to the target container; obtains the device information of the target binder driver device based on the target device identifier; and creates a target device file corresponding to the target binder driver device based on the device information, so that the application can connect to the target binder driver device through the target device file. Therefore, this application directly creates the target device file corresponding to the binder driver device in the target container, and the application can directly use the target device file to connect to the target binder driver device without modifying the libbinder source code, making the process simpler and faster. Furthermore, this application does not need to pay attention to environment variables, that is, it does not need to determine the driver device through environment variables, thus avoiding the situation of connecting to the wrong driver device using the wrong device file due to the clearing of environment variables. This improves the correctness of binder driver device connection, achieving isolation between containers and further ensuring normal inter-process communication.

[0083] Furthermore, embodiments of this application also provide an electronic device. Figure 8 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application.

[0084] Figure 8 This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of this application. Specifically, the electronic device 20 may include: at least one processor 21, at least one memory 22, a display screen 23, an input / output interface 24, a communication interface 25, a power supply 26, and a communication bus 27. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the binder driver device connection method disclosed in any of the foregoing embodiments. Alternatively, the electronic device 20 in this embodiment may specifically be a computer.

[0085] In this embodiment, the power supply 26 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 25 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 24 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0086] Furthermore, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk, or optical disk, etc. The resources stored thereon may include computer programs 221, and the storage method may be temporary storage or permanent storage. The computer programs 221 may include, in addition to computer programs capable of performing the binder driver device connection method executed by the electronic device 20 as disclosed in any of the foregoing embodiments, computer programs capable of performing other specific tasks.

[0087] Furthermore, embodiments of this application also disclose a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned disclosed binder driver device connection method.

[0088] For the specific steps of this method, please refer to the relevant content disclosed in the foregoing embodiments, which will not be repeated here.

[0089] The various embodiments in this application are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. For the same or similar parts between the various embodiments, refer to each other. As for the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple, and relevant parts can be referred to in the method section.

[0090] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0091] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0092] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0093] The foregoing has provided a detailed description of a binder driver device connection method, apparatus, device, and storage medium provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A binder driver device connection method, characterized in that, include: After the target container starts, it obtains the target device identifier of the target binder driver device that has been pre-assigned to the target container; Obtain the device information of the target binder driver device based on the target device identifier; Based on the device information, a target device file corresponding to the target binder driver device is created, so that the application can connect to the target binder driver device through the target device file; The step of creating a target device file corresponding to the target binder driver device based on the device information, so that the application can connect to the target binder driver device through the target device file, includes: Based on the device information, a target device file corresponding to the target binder driver device is created and replaces the original device file in the target container, so that the application can connect to the target binder driver device through the target device file.

2. The binder driver device connection method according to claim 1, characterized in that, The target device identifier is the identifier of the target binder driver device selected from the idle binder driver devices before the target container starts.

3. The binder driver device connection method according to claim 1, characterized in that, After the target container starts, it obtains the target device identifier of the target binder driver device pre-assigned to the target container, including: After the target container starts, it reads the target identifier file that has been pre-mounted to the target container to obtain the target device identifier of the target binder driver device that has been pre-assigned to the target container; the target identifier file is a file used to store the target device identifier and mount it to the target container before the target container starts.

4. The binder driver device connection method according to claim 1, characterized in that, The step of obtaining the device information of the target binder driver device based on the target device identifier includes: Based on the target device identifier, a preset device file corresponding to the target binder driver device is determined from the target container, and the device information of the target binder driver device is obtained based on the preset device file.

5. The binder driver device connection method according to claim 4, characterized in that, The step of determining the preset device file corresponding to the target binder driver device from the target container includes: The preset device file corresponding to the target binder driver device is determined from the device files corresponding to different preset binder driver devices pre-stored in the target container.

6. The binder driver device connection method according to claim 1, characterized in that, The step of creating a target device file corresponding to the target binder driver device based on the device information and replacing the original device file in the target container, so that the application can connect to the target binder driver device through the target device file, includes: Delete the original device file in the target container; Based on the device information, a target device file corresponding to the target binder driver device is created, and the target device file is written into the target container so that the application can connect to the target binder driver device through the target device file.

7. A binder driver device connection device, characterized in that, include: The identifier acquisition module is used to acquire the target device identifier of the target binder driver device that has been pre-assigned to the target container after the target container starts. The device information acquisition module is used to obtain the device information of the target binder driver device based on the target device identifier. The target device file creation module is used to create a target device file corresponding to the target binder driver device based on the device information, so that the application can connect to the target binder driver device through the target device file; Specifically, the target device file creation module is used to create a target device file corresponding to the target binder driver device based on the device information, and replace the original device file in the target container, so that the application can connect to the target binder driver device through the target device file.

8. An electronic device, characterized in that, It includes a processor and a memory; wherein, when the processor executes a computer program stored in the memory, it implements the binder driver device connection method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, Used to store a computer program; wherein, when the computer program is executed by a processor, it implements the binder driver device connection method as described in any one of claims 1 to 6.

Images