Equipment management method and electronic equipment

Abstract

The embodiment of the invention discloses an equipment management method and electronic equipment, and the method comprises the steps: setting an internal and external bridging directory of a container of a host machine as a loading point A before the operation of the container, and setting the transmission attribute of the loading point A as sharing; when the container runs, the loading point A is mapped into a loading point B in the container, the propagation attribute of the loading point B is set to be shared, and bidirectional propagation of mapping actions under the loading point A of the host machine and the loading point B in the container is supported; therefore, on the premise that the container does not run again, the inserted equipment can be mapped into the container through the internal and external bridging directory of the container of the host machine, so that the application in the container can access the equipment; meanwhile, after the equipment is pulled up, the equipment is cancelled and mapped into the container, so that the application in the container cannot access the equipment; and on the premise that the container does not run again and the equipment is kept being inserted, the equipment in the mapping container is independently canceled, and the use of the equipment by the host machine is not influenced.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to a device management method and an electronic device. Background Technology

[0002] Electronic devices run a host operating system, which in turn can run containers. Containers can utilize the host operating system's kernel and create an isolated runtime environment on top of it. Each container has its own file system, process space, network space, etc., and is isolated from other containers, but they share the host operating system's kernel.

[0003] Users using applications within containers (such as Linux containers) may need to read and write files on devices (such as USB drives, hard drives, and network devices like cloud storage). However, if a user hot-plugs the device while it's running (i.e., inserting or removing the device while it's running without shutting down or restarting the device), the container's isolation technology prevents the application from reading or writing data on the device. This prevents users from hot-plugging devices after the container is running, hindering their use of peripherals and degrading the user experience. Summary of the Invention

[0004] This application provides a device management method and an electronic device. Before the container runs, the host machine's internal and external bridging directories are set as mount point A, and the propagation attribute of mount point A is set to shared. During container runtime, mount point A is mapped to mount point B within the container, and the propagation attribute of mount point B is set to shared. This supports bidirectional propagation of the mapping action between mount point A on the host machine and mount point B within the container. Therefore, it allows inserted devices to be mapped into the container via the host machine's internal and external bridging directories without restarting the container, enabling applications within the container to access the devices. Conversely, after unplugging the device, the mapping is de-mapped into the container, preventing applications within the container from accessing the device. Furthermore, it supports de-mapping devices within the container independently without restarting the container and while the device remains inserted, without affecting the host machine's use of the device.

[0005] In a first aspect, this application provides a device management method applied to a first electronic device running a host operating system, the host operating system running a first container. The method includes: before the first container starts, the first electronic device creates a first bridging directory in the host operating system and sets the first bridging directory as a first mount point; when the first container starts, the first electronic device creates a second mount point in the first container based on the information of the first mount point; after the first container starts, upon receiving a notification of device insertion, the first electronic device obtains the path of the device in the host operating system and maps the path of the device to a first directory under the first mount point; wherein, mapping the path of the device to the first directory is a first mapping action; the first electronic device propagates the first mapping action to the second mount point in the first container through the first mount point in the host operating system; the first electronic device obtains a second directory under the second mount point in the first container based on the first mapping action.

[0006] The first electronic device can be, for example, Figure 7 The first container of the electronic device 100 shown can be as follows: Figure 1 , Figure 3 or Figure 5 The container shown (e.g., a Linux container) can have its first bridging directory as the bridging directory between the container and the host operating system (e.g., ...).

[0007] The first mount point can be mount point A (e.g., / data / rootfs / bridge / ), the second mount point can be mount point B (e.g., / bridge / ), the device path can be, for example, / storage / USB1 / , and the first directory can be directory A (e.g., / data / rootfs / bridge / ).

[0008] The second directory can be directory B (e.g., / data / rootfs / br idge / USB1 / ).

[0009] By implementing the method provided in the first aspect, it is possible to map inserted devices into the container through the host machine's internal and external container bridging directories without re-running the container, enabling applications within the container to access the devices. This achieves plug-and-play functionality, allowing container applications running on the host operating system to use devices on the host side, meeting users' needs for convenient use of peripherals and improving the user experience.

[0010] In conjunction with the first aspect, in some embodiments, the propagation attribute of the first loading point is set to shared; and the propagation attribute of the second loading point is set to shared.

[0011] In this way, electronic devices can support bidirectional propagation of downmapping actions between the host machine's load point A and the container's load point B.

[0012] In conjunction with the first aspect, in some embodiments, the first electronic device creates a second load point in the first container based on information from the first load point, specifically including: the first electronic device maps the first bridging directory to a second bridging directory in the first container through the host operating system, and creates the second bridging directory as a second load point in the first container.

[0013] The second bridging directory can be a bridging directory between the container and the outside of the container (e.g., / bridge / USB1 / ).

[0014] In conjunction with the first aspect, in some embodiments, the method further includes: after the first container starts, receiving a notification that the device has been unplugged; the first electronic device unmaps the device path to a first directory under the first mount point in the host operating system, and deletes the first directory under the first mount point.

[0015] In this way, after the device is unplugged, the electronic device can unmap the device into the container, making the application inside the container unable to access the device.

[0016] In conjunction with the first aspect, in some embodiments, the method further includes: while the device remains inserted, in response to a triggering operation, the first electronic device removes the second mount point from the first container, and the path of the device received from the first mount point in the host operating system is mapped to the first directory.

[0017] In this way, electronic devices can support the individual unmapping of devices within a container without restarting the container and keeping the device plugged in, without affecting the host machine's use of the device.

[0018] In conjunction with the first aspect, in some embodiments, the host operating system includes a container fusion service module and a device service module. Upon receiving a notification of device insertion, the first electronic device obtains the device path in the host operating system and maps the device path to a first directory under the first mount point. Specifically, if the first electronic device detects device insertion through the device service module, the device service module calls back to notify the container fusion service module; the first electronic device obtains the device path from the device service module through the container fusion service module in the host operating system and maps the device path to a first directory under the first mount point.

[0019] In this way, electronic devices can support rapid detection of hot-plug events, reducing system power consumption.

[0020] In conjunction with the first aspect, in some embodiments, the device service module includes a first interface for registering callbacks for device hot-plug events.

[0021] In conjunction with the first aspect, in some embodiments, obtaining a notification of device insertion specifically includes: the first electronic device receiving a trigger operation through a first application in the host operating system; the first electronic device obtaining the path of the device in the host operating system and mapping the path of the device to a first directory under the first mount point, specifically including: the first electronic device obtaining the path of the device through a first application in the host operating system and mapping the path of the device to a first directory under the first mount point.

[0022] The first application can be, for example, Figure 3 The container fusion application shown.

[0023] In this way, electronic devices can support hot-swapping of devices within the container while the container is running, allowing users to open files within the device without rerunning the container, thus improving the user experience.

[0024] In conjunction with the first aspect, in some embodiments, obtaining a device insertion notification specifically includes: a first electronic device receiving a trigger operation via a second application in a first container; the first electronic device sending a first notification to the host operating system in the first container, the first notification being used to instruct the device to be inserted.

[0025] The second application can be, for example: Figure 5 The device management application shown.

[0026] In this way, the electronic device 100 can enable users to manually control the hot-swapping of devices within the container during container operation, allowing users to open files within the device without rerunning the container, thus improving the user experience.

[0027] Secondly, this application provides an electronic device running a host operating system, which in turn runs a first container. Before the first container starts, the host operating system creates a first bridging directory and sets it as a first mount point. When the first container starts, it creates a second mount point based on information from the first mount point. After the first container starts, upon receiving a notification of device insertion, the host operating system obtains the device's path and maps it to a first directory under the first mount point. Mapping the device's path to the first directory is a first mapping action. The host operating system propagates this first mapping action to the second mount point within the first container via the first mount point. The first container obtains the second directory under the second mount point based on the first mapping action.

[0028] In conjunction with the second aspect, in some embodiments, the propagation attribute of the first loading point is set to shared; and the propagation attribute of the second loading point is set to shared.

[0029] In conjunction with the second aspect, in some embodiments, the first container is specifically used to create the second bridging directory as the second mount point; the host operating system is used to map the first bridging directory to the second bridging directory in the first container.

[0030] In conjunction with the second aspect, in some embodiments, after the first container starts, the host operating system is also used to receive a notification that the device has been unplugged; the host operating system is also used to unmap the device's path to the first directory under the first mount point, and delete the first directory under the first mount point.

[0031] In conjunction with the second aspect, in some embodiments, while the device remains inserted, in response to a triggering operation, the first container is also used to remove the mapping action whereby the path of the device received by the second mount point from the first mount point in the host operating system is mapped to the first directory.

[0032] In conjunction with the second aspect, in some embodiments, the host operating system includes a container fusion service module and a device service module. If a device is detected being inserted, the device service module is used to notify the container fusion service module via callback. The container fusion service module is used to obtain the path of the device from the device service module and map the path of the device to a first directory under a first load point.

[0033] In conjunction with the second aspect, in some embodiments, the device service module includes a first interface for registering callbacks for device hot-plug events.

[0034] In conjunction with the second aspect, in some embodiments, the host operating system is specifically used to receive the trigger operation through the first application; the host operating system is specifically used to obtain the path of the device through the first application and map the path of the device to the first directory under the first loading point.

[0035] In conjunction with the second aspect, in some embodiments, the host operating system is specifically used to receive a first notification sent by the first container, the first notification being used to instruct the device to be inserted; the first container is used to receive a trigger operation through a second application.

[0036] Thirdly, this application provides a computer-readable storage medium storing a computer program or computer instructions, which are executed by a processor to implement the method described in any of the first aspects above.

[0037] Fourthly, this application provides a computer program product that, when executed by a processor, implements the method described in any one of the first aspects above.

[0038] Fifthly, this application provides a chip including a processor and a memory, wherein the memory is used to store computer programs or computer instructions, and the processor is used to execute the computer programs or computer instructions stored in the memory, causing the chip to perform the method described in any of the first aspects above.

[0039] The solutions provided in the second to fifth aspects above are used to implement or cooperate with the methods provided in the first aspect above, and therefore can achieve the same or corresponding beneficial effects as the methods in the first aspect, which will not be elaborated here. Attached Figure Description

[0040] Figure 1 This is a flowchart illustrating a device management method provided in an embodiment of this application;

[0041] Figures 2A-2C These are a set of interface diagrams provided in the embodiments of this application;

[0042] Figure 3 This is a flowchart illustrating another device management method provided in an embodiment of this application;

[0043] Figures 4A-4F This is another set of interface diagrams provided in the embodiments of this application;

[0044] Figure 5 This is a flowchart illustrating another device management method provided in an embodiment of this application;

[0045] Figures 6A-6D This is another set of interface diagrams provided in the embodiments of this application;

[0046] Figure 7 This is a schematic diagram of the structure of an electronic device 100 provided in an embodiment of this application. Detailed Implementation

[0047] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be a limitation of this application.

[0048] Electronic devices run a host operating system, which in turn can run containers. Containers can utilize the host operating system's kernel and create an isolated runtime environment on top of it. Each container has its own file system, process space, network space, etc., and is isolated from other containers, but they share the host operating system's kernel.

[0049] Users using applications within containers (such as Linux containers) may need to read and write files on devices (such as USB drives, hard drives, and network devices like cloud storage). However, if the user hot-plugs the device (i.e., inserting or removing the device while it's running without shutting down or restarting the device), the container's isolation technology prevents the application from reading or writing data on the device. This prevents users from hot-plugging devices after the container is running, hindering their use of peripherals and degrading the user experience.

[0050] Currently, it is possible to read and write data to a device through a container by restarting the container after detecting a hot-plugging of the device. This greatly increases system power consumption and seriously affects the user experience.

[0051] To address the aforementioned issues, this application provides a device management method and electronic device. Before the container runs, the host machine's internal and external bridging directories are set as load point A, and the propagation attribute of load point A is set to shared. During container runtime, load point A is mapped to load point B within the container, and the propagation attribute of load point B is set to shared. This supports bidirectional propagation of the mapping action between load point A on the host machine and load point B within the container. Therefore, it allows inserted devices to be mapped into the container via the host machine's internal and external bridging directories without restarting the container, enabling applications within the container to access the devices. Conversely, after unplugging the device, the mapping is de-mapped into the container, preventing applications within the container from accessing it. Furthermore, it allows devices within the container to be de-mapped individually without restarting the container and while the device remains inserted, without affecting the host machine's use of the device. This enables plug-and-play functionality, allowing applications running on the host machine's operating system to use devices on the host side, meeting users' needs for convenient peripheral use and improving user experience.

[0052] First, a flowchart illustrating a device management method provided in an embodiment of this application is presented.

[0053] Figure 1 The specific flow of a device management method provided in an embodiment of this application is illustrated by way of example.

[0054] This method can be applied to an electronic device 100, which runs a host operating system that runs containers. The host operating system may include a container fusion service module and a device service module. The container fusion service module can receive notifications of device hot-plug events by registering callbacks for device hot-plug events with the device service module. It can also map the device to the host operating system when it is inserted (i.e., obtain the device's path in the host operating system and map that path to the bridge directory inside and outside the container), and unmap the device when it is removed (i.e., unmap the device's path to the bridge directory inside and outside the container). It can also create a mount point in the host operating system. The device service module can be aware of device hot-plugging. The container may run a device management application; the device management application can manage the ejection of devices within the container.

[0055] The host operating system and the operating system inside the container can be the same type of operating system (e.g., both are Linux operating systems), or they can be two different types of operating systems (e.g., the host operating system is a Windows operating system and the operating system inside the container is a Linux operating system). This application embodiment does not limit this.

[0056] The aforementioned devices are those that have a corresponding directory (path) in the host machine's operating system after being inserted into the host machine. These devices may include, but are not limited to, storage devices, such as USB flash drives, hard drives, and other mobile devices, as well as network devices such as cloud storage.

[0057] like Figure 1 As shown, the method may include:

[0058] S101. Create load point A and set the propagation attribute of load point A to shared.

[0059] Specifically, before the container runs, the container fusion service module in the host operating system can connect the first bridging directory (e.g.

[0060] ` / data / rootfs / bridge / ` is set as mount point A, and the propagation attribute of mount point A is set to shared. Here, the first bridging directory is a bridging directory between the container and the host operating system. This first bridging directory is a file directory created by the electronic device 100 in the host operating system's file system that can bridge or map with directories inside the container, thereby achieving the purpose of sharing files or data between the host operating system and the container.

[0061] Mount point A can be used to map the inserted device. That is, mount point A allows electronic device 100 to connect the top-level directory in the device file (i.e., the device's path in the host operating system, such as / storage / USB1 / ) to a subdirectory (i.e., directory A, such as / data / rootfs / bridge / USB1 / ) under the first bridging directory, so that electronic device 100 can access the device file through the subdirectory. The association between the top-level directory in the device file and the subdirectory under the first bridging directory can be recorded in the host operating system. Furthermore, the specified file system on the specified device can be mounted to mount point A using the mount command, which is common in operating systems such as Linux and Android. For example, this can be done by entering...

[0062] The command "mount / storage / USB1 / / data / rootfs / br idge / " specifies the path of the inserted device in the host operating system (e.g., ...).

[0063] The device file ( / storage / USB1 / ) is loaded into mount point A (i.e., the first bridging directory, such as / data / rootfs / bridge / ), resulting in a subdirectory (i.e., directory A, such as / data / rootfs / bridge / USB1 / ) under mount point A. This allows the electronic device 100 to access device files through directory A. The association between the device's path in the host operating system and directory A under mount point A can be recorded in the host operating system.

[0064] The propagation attribute of a mount point specifies how mapping actions are propagated. This means that the association between directories recorded in the host operating system (e.g., the path of a device in the host operating system and directory A under mount point A) is propagated from the host operating system to the container. Specifically, the propagation attribute of a mount point can include types such as shared, private, and slave. Setting the propagation attribute of mount point A to shared means that mapping actions under mount point A in the host operating system can be propagated bidirectionally with mount points within the container, ensuring that directories under mount point A in the host operating system and directories under mount points within the container are updated synchronously. For example, after a device is plugged in, the device's path in the host operating system (e.g., / storage / USB1 / ) is mapped to mount point A (e.g., / data / rootfs / brute / ). This mapping can be propagated to the mount point within the container, allowing applications within the container to access files and data on the device through the device directory (directory B, e.g., / brute / USB1 / ) under the container's mount point. Further, after the device is unplugged, the device directory (directory A, e.g., / data / rootfs / brute / USB1 / ) under mount point A in the host operating system is unmapped, and directory A (e.g., / data / rootfs / brute / USB1 / ) is unmapped.

[0065] The mapping action ` / data / rootfs / br idge / USB1 / ` is deleted. This mapping action can be propagated to the container's mount point, and the device directory under the container's mount point (i.e., directory B, e.g., ` / br idge / USB1 / `) is simultaneously deleted. Furthermore, mount point A in the host operating system can receive mapping actions propagated from the container's mount point. For example, if the device directory under the container's mount point (i.e., directory B, e.g., ` / br idge / USB1 / `) is unmapped, and directory B (e.g., ` / br idge / USB1 / `) is deleted, mount point A in the host operating system can receive this mapping action, and the device directory under mount point A in the host operating system (i.e., directory A, e.g., ` / data / rootfs / br idge / USB1 / `) is simultaneously deleted. The fact that the propagation attribute of mount point A is set to private means that mapping actions under mount point A in the host operating system cannot be propagated to the container's mount point, and mount point A in the host operating system cannot receive mapping actions propagated from the container's mount point. The fact that the propagation attribute of load point A is set to slave mode means that mapping actions under load point A in the host operating system cannot be propagated to load points within the container, but load point A in the host operating system can receive mapping actions propagated from load points within the container.

[0066] S102. Create load point B based on load point A, and set the propagation attribute of load point B to shared.

[0067] Specifically, during container runtime, the container engine (not shown in the diagram) in the host operating system can create an isolated space for the container. This isolated space can be used to isolate the container from the mount point in the host operating system. The host operating system can map the first bridging directory (i.e., mount point A, e.g., / data / rootfs / bridge / ) to the isolated space within the container by calling the container engine interface (not shown in the diagram), resulting in a second bridging directory (e.g., / bridge / ), and then set this second bridging directory (e.g., / bridge / ) as mount point B. The propagation attribute of mount point B is set to shared; a specific command could be, for example, "unshare-m --propagation shared". The second bridging directory has the same lifecycle as the container. In this way, the propagation attribute of mount point B within the container and the propagation attribute of mount point A in the host operating system are both shared, allowing mount point B within the container and mount point A in the host operating system to propagate mapping actions to each other. In this context, setting the propagation attribute of mount point B to "shared" means that mapping actions under mount point B within the container can be propagated bidirectionally with mount point A in the host operating system. This ensures that directories under mount point B within the container and under mount point A in the host operating system can be updated synchronously. For example, if the device directory (i.e., directory B, e.g., / br idge / USB1 / ) under mount point B within the container is unmapped and directory B (e.g., / br idge / USB1 / ) is deleted, this mapping action can be propagated to mount point A in the host operating system. The device directory (i.e., directory A, e.g., / br idge / USB1 / ) under mount point A in the host operating system will then be updated synchronously.

[0068] The path ` / data / rootfs / bridge / USB1 / ` is synchronously deleted. Furthermore, mount point B within the container can receive mapping actions propagated from mount point A in the host operating system. For example, after a device is plugged in, the device's path in the host operating system (e.g., ` / storage / USB1 / `) is mapped to mount point A (e.g., ` / data / rootfs / bridge / `). Mount point B within the container can receive this mapping action, allowing applications within the container to access files and data on the device through the device directory (i.e., directory B, e.g., ` / bridge / USB1 / `) under mount point B. Similarly, after the device is unplugged, the device directory (i.e., directory A, e.g., ` / data / rootfs / bridge / `) under mount point A in the host operating system...

[0069] The mapping for ` / data / rootfs / bridge / USB1 / ` is unmapped, directory A (e.g., ` / data / rootfs / bridge / USB1 / `) is deleted, and mount point B within the container can receive this mapping action. The device directory under mount point B (i.e., directory B, e.g., ` / bridge / USB1 / `) is simultaneously deleted. Setting the propagation attribute of mount point B to private means that mapping actions under mount point B cannot be propagated to mount point A in the host operating system, and mount point B cannot receive mapping actions propagated from mount point A in the host operating system. Setting the propagation attribute of mount point B to slave mode means that mapping actions under mount point B cannot be propagated to mount point A in the host operating system, but mount point B can receive mapping actions propagated from mount point A in the host operating system.

[0070] S103, Callback for registered device hot-plug events.

[0071] S104, Callback notification of device hot-plug event.

[0072] Specifically, the device service module in the host operating system may include an interface for registering callbacks for device hot-plug events. After the container starts running, the container fusion service module in the host operating system can call this interface to register the callback for the device hot-plug event with the device service module. When the device service module in the host operating system becomes aware of a device hot-plugging event, it can notify the container fusion service module in the host operating system of the hot-plug event via a callback. It is easy to understand that the registration of the device hot-plug event callback by the container fusion service module in the host operating system to the device service module in the host operating system is executed automatically, without user triggering. In this way, the electronic device 100 can support the host operating system to quickly detect device hot-plug events, reducing system power consumption.

[0073] S105. Obtain the device path.

[0074] Specifically, after the container fusion service module in the host operating system receives a notification of device insertion, it can obtain the device's path in the host operating system (e.g., / storage / USB1 / ) through the device service module in the host operating system. The device path is stored within the host operating system. It's easy to understand that the container fusion service module in the host operating system obtains the device path automatically, without requiring user intervention.

[0075] S106. Map the device path to directory A under load point A.

[0076] Specifically, the container fusion service module in the host operating system can map the device path (e.g., / storage / USB1 / ) to directory A under mount point A (e.g., / data / rootfs / br idge / USB1 / ). In other words, the container fusion service module in the host operating system can connect the device path (e.g., / storage / USB1 / ) to directory A under mount point A (e.g., / data / rootfs / br idge / USB1 / ).

[0077] The device can be mounted at directory A (e.g., / data / rootfs / brider / USB1 / ), allowing the host operating system to access the device file. Furthermore, the `mount` command, common in operating systems such as Linux and Android, can be used to mount a specified file system from the specified device to mount point A. For example, the command "mount / storage / USB1 / / data / rootfs / brider / " can be entered in the host operating system to mount the path of the inserted device in the host operating system (e.g., / storage / USB1 / ) to mount point A (e.g., / data / rootfs / brider / ).

[0078] Under ` / data / rootfs / bridge / `, a directory A (e.g., ` / data / rootfs / bridge / USB1 / `) is obtained under mount point A, allowing the host operating system to access device files through directory A. Since the propagation attributes of mount point A in the host operating system and mount point B within the container are shared, the mapping action of mapping device paths under mount point A to directory A in the host operating system can be propagated to mount point B in the container, thereby generating directory B (e.g., ` / bridge / USB1 / `) under mount point B.

[0079] In this way, without restarting the container, applications inside the container can access directory A by accessing directory B, and thus access files and data on the device.

[0080] S107. Unmap the device path and delete directory A.

[0081] Specifically, after the container fusion service module in the host operating system receives a notification that the device has been unplugged, the container fusion service module can unmap the device's path (e.g., / storage / USB1 / ) to directory A under mount point A (e.g., ...).

[0082] The code snippet describes a process called ` / data / rootfs / mount_gate / USB1 / `, which involves unmapping a device path from mount point A to directory A within the container. Since the propagation attributes of mount point A and mount point B are shared, the unmapping of the device path from mount point A to directory A in the host operating system can be propagated to mount point B in the container, thus deleting directory B (e.g., ` / mount_gate / USB1 / `) under mount point B.

[0083] In this way, without re-running the container, applications inside the container cannot access files and data on the device by accessing directory B.

[0084] S108. In response to the trigger operation, delete the mapping action where the device path is mapped to directory A.

[0085] Specifically, while the device remains inserted, in response to a triggered operation by a device management application running within the container, the electronic device 100 can remove the mapping of the device path (e.g., / storage / USB1 / ) received from mount point B (e.g., / bridge / ) in the host operating system from mount point A to directory A (e.g., / data / rootfs / bridge / USB1 / ), thereby deleting directory B (e.g., / bridge / USB1 / ) under mount point B. In this way, without restarting the container and while the device remains inserted, the electronic device 100 can independently unmap the device within the container (i.e., eject the device) without affecting the host operating system's use of the device.

[0086] For example, such as Figure 2A As shown, the electronic device 100 may display a user interface 410, which may include options for popping up devices (e.g., option 411), which can be used to trigger the unmapping of devices within a separate container (i.e., popping up devices).

[0087] Electronic device 100 can receive a user's click operation on an option in the pop-up device (e.g., clicking option 411), and in response to this input operation, electronic device 100 can display, as shown in the image. Figure 2B The user interface shown is 420.

[0088] For example, such as Figure 2BAs shown, the user interface 420 may include a prompt box (such as prompt box 421), which may include text prompting the user to confirm the pop-up device (e.g., "You have selected a pop-up device; please confirm the operation"). In some embodiments, the type of prompt information included in prompt box 421 may also be an image, video, sound, etc., and this application embodiment does not limit this. In addition, the prompt box may also include one or more options (such as option 422), which can be used to trigger the electronic device 100 to confirm the separate unmapping of the device (i.e., the pop-up device) within the container.

[0089] Electronic device 100 can receive user input (e.g., a click) on option 422, and in response to the input, electronic device 100 can display, as shown below. Figure 2C The user interface shown is 430.

[0090] For example, such as Figure 2C As shown, the user interface 430 may include a prompt box (e.g., prompt box 431), which may include text prompting the user that the device ejection operation was successful (e.g., "You have successfully ejected the device"). In some embodiments, the type of prompt information included in the prompt box 431 may also be an image, video, sound, etc., and this application embodiment does not limit this.

[0091] In this way, the electronic device 100 can enable hot-swapping of the device during container operation, allowing users to open files within the device without rerunning the container, thus improving the user experience.

[0092] Figure 3 The specific flow of another device management method provided in the embodiments of this application is illustrated by way of example.

[0093] This method can be applied to an electronic device 100, which runs a host operating system, and the host operating system runs containers. The host operating system may include a container fusion application and a device service module. The container fusion application can receive a user's trigger operation to map a device; in response to this trigger operation, the container fusion application can obtain the device's path in the host operating system and map the device's path to the first bridge directory of the host operating system. It can also receive a user's trigger operation to unmap a device; in response to this trigger operation, the container fusion application can unmap the device (i.e., unmap the device's path to the first bridge directory). It can also create a mount point in the host operating system. The device service module can pass the device's path in the host operating system to the container fusion application. The container may run a device management application; the device management application can manage the ejection of devices within the container.

[0094] The host operating system and the operating system inside the container can be the same type of operating system (e.g., both are Linux operating systems), or they can be two different types of operating systems (e.g., the host operating system is a Windows operating system and the operating system inside the container is a Linux operating system). This application embodiment does not limit this.

[0095] The aforementioned devices are those that, after being inserted into the host machine, have a corresponding directory (path) in the host machine's operating system. These can include, but are not limited to, storage devices such as USB flash drives, hard drives, and other mobile devices, as well as network devices such as cloud storage. Figure 3 As shown, the method may include:

[0096] S201. Create load point A and set the propagation attribute of load point A to shared.

[0097] S202. Create load point B based on load point A, and set the propagation attribute of load point B to shared.

[0098] Among them, the above steps S201-S202 are the same as those mentioned above. Figure 1 Steps S101-S102 are similar to those shown above, and the specific execution process of steps S201-S202 can be referred to the above. Figure 1 The relevant textual descriptions in steps S101-S102 shown will not be repeated here.

[0099] S203. Upon receiving the trigger operation, obtain the device path.

[0100] Specifically, the container-embedded application in the host operating system can receive a trigger operation from the user-mapped device. In response to the trigger operation, the container-embedded application in the host operating system can obtain the path of the device in the host operating system from the device service module in the host operating system, where the path of the device is stored in the host operating system.

[0101] For example, such as Figure 4A As shown, the electronic device 100 can display a user interface 510, which may include a mapped device control (such as control 511) in a closed state. The mapped device control can be used to trigger the electronic device 100 to obtain the path of the device and map the path of the device to the first bridged directory.

[0102] Electronic device 100 can receive user input operations (e.g., clicks) on mapped device controls. In response to such input operations, electronic device 100 can obtain the path of the device and map the path of the device to the first bridging directory.

[0103] After mapping the device's path to the first bridging directory, the electronic device 100 can display as follows: Figure 4B The user interface 520 shown may include a mapped device control (such as control 521) that is in an open state.

[0104] For example, such as Figure 4C As shown, after mapping the device's path to the first bridging directory, the electronic device 100 can display a user interface 530 in the first host application of the host operating system. This user interface 530 can display directory A (e.g.,

[0105] / data / rootfs / bridge / USB1 / ).

[0106] For example, such as Figure 4D As shown, after mapping the device's path to the first bridging directory, the electronic device 100 can display a user interface 540 in the first container application within the container, which can display directory B (e.g., / bridge / USB1 / ).

[0107] S204. Map the device path to directory A under load point A.

[0108] Among them, step S204 is the same as the aforementioned Figure 1 The steps shown in step S106 are similar, and the specific execution process of step S204 can be referred to the above. Figure 1 The relevant textual descriptions in step S106 shown will not be repeated here.

[0109] S205. Unmap the device path and delete directory A.

[0110] Specifically, the containerized application in the host operating system can receive a user's trigger operation to unmap a device. In response to this trigger operation, the containerized application can unmap the device path (e.g., / storage / USB1 / ) to directory A under mount point A (e.g., / data / rootfs / br idge / USB1 / ) in the host operating system and delete directory A. Since the propagation attributes of mount point A in the host operating system and mount point B in the container are shared, the action of unmapping the device path under mount point A to directory A in the host operating system can be propagated to mount point B in the container, thereby deleting directory B under mount point B (e.g., / data / rootfs / br idge / USB1 / ).

[0111] / br idge / USB1 / ).

[0112] In this way, without re-running the container, applications inside the container cannot access files and data on the device by accessing directory B.

[0113] For example, such as Figure 4B As shown, the electronic device 100 can display a user interface 520, which may include an open mapping device control (such as control 521) that can be used to trigger the electronic device 100 to unmap the device (unmap the device path to the first bridging directory).

[0114] Electronic device 100 can receive user input operations (such as clicking) on ​​the mapped device control, and in response to the input operation, electronic device 100 can unmap the device (unmap the device path to the first bridging directory).

[0115] After unmapping the device, the electronic device 100 can display as follows: Figure 4A The user interface 510 shown may include a mapped device control (such as control 511) in a closed state.

[0116] For example, such as Figure 4E As shown, after unmapping the device, the electronic device 100 can display the user interface 550 in the first host application of the host operating system. Since the directory A (e.g., / data / rootfs / br idge / USB1 / ) has been deleted, the user interface 550 does not display the directory A (e.g., / data / rootfs / br idge / USB1 / ).

[0117] For example, such as Figure 4F As shown, after unmapping the device, the electronic device 100 can display the user interface 560 in the first container application within the container. Since directory B (e.g., / br idge / USB1 / ) has been deleted, the user interface 560 does not display directory B (e.g., / br idge / USB1 / ).

[0118] / br idge / USB1 / ).

[0119] S206. In response to the trigger operation, delete the mapping action where the device path is mapped to directory A.

[0120] Step S206 is the same as described above. Figure 1 The steps shown in step S108 are similar, and the specific execution process of step S206 can be referred to the above. Figure 1 The relevant textual descriptions in step S108 shown will not be repeated here.

[0121] In this way, the electronic device 100 can enable users to manually control the hot-swapping of devices within the container during container operation, allowing users to open files within the device without rerunning the container, thus improving the user experience.

[0122] Figure 5 The specific flow of another device management method provided in the embodiments of this application is illustrated by way of example.

[0123] This method can be applied to an electronic device 100, which runs a host operating system that runs containers. The host operating system may include a container fusion service module and a device service module. The container fusion service module can receive notifications from a device management application within the container instructing device insertion, obtain the device's path in the host operating system based on the notification, and map the device's path to a first bridge directory in the host operating system. It can also receive notifications from the device management application in the container instructing device removal, and unmap the device based on the notification (i.e., unmap the device's path to the first bridge directory). It can also create a mount point in the host operating system. The device service module can pass the device's path in the host operating system to the container fusion service module. The container may run a device management application. The device management application can receive user trigger operations, and in response to these operations, send a notification of a device hot-plug event to the container fusion service module. It can also manage the ejection of devices within the container.

[0124] The host operating system and the operating system inside the container can be the same type of operating system (e.g., both are Linux operating systems), or they can be two different types of operating systems (e.g., the host operating system is a Windows operating system and the operating system inside the container is a Linux operating system). This application embodiment does not limit this.

[0125] The aforementioned devices are those that have a corresponding directory (path) in the host machine's operating system after being inserted into the host machine. These devices may include, but are not limited to, storage devices, such as USB flash drives, hard drives, and other mobile devices, as well as network devices such as cloud storage.

[0126] like Figure 5 As shown, the method may include:

[0127] S301. Create load point A and set the propagation attribute of load point A to shared.

[0128] S302. Create load point B based on load point A, and set the propagation attribute of load point B to shared.

[0129] Among them, the above steps S301-S302 are the same as those mentioned above. Figure 1Steps S101-S102 are similar to those shown above, and the specific execution process of steps S301-S302 can be referred to the foregoing. Figure 1 The relevant textual descriptions in steps S101-S102 shown will not be repeated here.

[0130] S303. Upon receiving the trigger operation, send a notification of the device hot-plug event.

[0131] S304. Obtain the device path.

[0132] Specifically, the device management application running inside the container can receive a trigger operation from the user-mapped device. In response to the trigger operation, the device management application running inside the container can send a device insertion notification to the Container Fusion Service module in the host operating system.

[0133] Specifically, after the container fusion service module in the host operating system receives the notification of device insertion, the container fusion service module in the host operating system can obtain the path of the device in the host operating system, where the path of the device is stored in the host operating system.

[0134] For example, such as Figure 6A As shown, the electronic device 100 can display a user interface 610, which may include a mapped device control (such as control 611) in a closed state. The mapped device control can be used to trigger the electronic device 100 to obtain the path of the device and map the path of the device to the first bridged directory.

[0135] Electronic device 100 can receive user input operations (e.g., clicks) on mapped device controls. In response to such input operations, electronic device 100 can obtain the path of the device and map the path of the device to the first bridging directory.

[0136] After mapping the device's path to the first bridging directory, the electronic device 100 can display as follows: Figure 6B The user interface 620 shown may include options for pop-up devices (e.g., option 622) and mapped device controls (e.g., control 621) that are in an open state.

[0137] For example, such as Figure 4C As shown, after mapping the device's path to the first bridging directory, the electronic device 100 can display a user interface 530 in the first host application of the host operating system. This user interface 530 can display directory A (e.g.,

[0138] / data / rootfs / bridge / USB1 / ).

[0139] For example, such as Figure 4D As shown, after mapping the device's path to the first bridging directory, the electronic device 100 can display a user interface 540 in the first container application within the container, which can display directory B (e.g., / bridge / USB1 / ).

[0140] S305. Map the device path to directory A under load point A.

[0141] Among them, step S305 is the same as the aforementioned Figure 1 The steps shown in step S106 are similar, and the specific execution process of step S305 can be referred to the above. Figure 1 The relevant textual descriptions in step S106 shown will not be repeated here.

[0142] S306. Unmap the device path and delete directory A.

[0143] Specifically, the device management application running inside the container can receive a user's trigger operation to unmap a device. In response to this trigger operation, the device management application running inside the container can send a notification to the Container Fusion Service module in the host operating system to unmap the device.

[0144] Specifically, after the container fusion service module in the host operating system receives a notification that the device has been unplugged, it can unmap the device path (e.g., / storage / USB1 / ) to directory A under mount point A (e.g., / data / rootfs / br idge / USB1 / ) and delete directory A. Since the propagation attributes of mount point A and mount point B in the container are shared, the unmapping of the device path under mount point A in the host operating system can be propagated to mount point B in the container, thereby deleting directory B under mount point B (e.g., / data / rootfs / br idge / USB1 / ).

[0145] / br idge / USB1 / ).

[0146] In this way, without re-running the container, applications inside the container cannot access files and data on the device by accessing directory B.

[0147] For example, such as Figure 6B As shown, the electronic device 100 can display a user interface 620, which can include an open mapping device control (such as control 621) that can be used to trigger the electronic device 100 to unmap the device (unmap the device path to the first bridging directory).

[0148] Electronic device 100 can receive user input operations (such as clicking) on ​​the mapped device control, and in response to the input operation, electronic device 100 can unmap the device (unmap the device path to the first bridging directory).

[0149] After unmapping the device, the electronic device 100 can display as follows: Figure 6A The user interface 610 shown may include a mapped device control (such as control 611) in a closed state.

[0150] For example, such as Figure 4E As shown, after unmapping the device, the electronic device 100 can display the user interface 550 in the first host application of the host operating system. Since the directory A (e.g., / data / rootfs / br idge / USB1 / ) has been deleted, the user interface 550 does not display the directory A (e.g., / data / rootfs / br idge / USB1 / ).

[0151] For example, such as Figure 4F As shown, after unmapping the device, the electronic device 100 can display the user interface 560 in the first container application within the container. Since directory B (e.g., / br idge / USB1 / ) has been deleted, the user interface 560 does not display directory B (e.g., / br idge / USB1 / ).

[0152] / br idge / USB1 / ).

[0153] S307. In response to a trigger operation, delete the mapping action where the device path is mapped to directory A.

[0154] Specifically, while the device remains inserted, in response to a triggered operation by a device management application running within the container, the electronic device 100 can remove the mapping of the device path (e.g., / storage / USB1 / ) received from mount point B (e.g., / bridge / ) in the host operating system from mount point A to directory A (e.g., / data / rootfs / bridge / USB1 / ), thereby deleting directory B (e.g., / bridge / USB1 / ) under mount point B. In this way, without restarting the container and while the device remains inserted, the electronic device 100 can independently unmap the device within the container (i.e., eject the device) without affecting the host operating system's use of the device.

[0155] For example, such as Figure 6A As shown, the electronic device 100 may also include an option to eject the device (e.g., option 612), which can be used to trigger a separate unmapping of the device within the container (i.e., ejecting the device).

[0156] Electronic device 100 can receive a user's click operation on an option in the pop-up device (e.g., clicking option 612), and in response to this input operation, electronic device 100 can display, as shown in the image. Figure 6C The user interface 630 shown.

[0157] For example, such as Figure 6C As shown, the user interface 630 may include a prompt box (such as prompt box 631), which may include text prompting the user to confirm the pop-up device (e.g., "You have selected a pop-up device; please confirm the operation"). In some embodiments, the type of prompt information included in the prompt box 631 may also be an image, video, sound, etc., and this application embodiment does not limit this. In addition, the prompt box may also include one or more options (such as option 632), which can be used to trigger the electronic device 100 to confirm the separate unmapping of the device (i.e., the pop-up device) within the container.

[0158] Electronic device 100 can receive user input (e.g., a click) on option 632, and in response to the input, electronic device 100 can display, as shown below. Figure 6D The user interface shown is 640.

[0159] For example, such as Figure 6D As shown, the user interface 640 may include a prompt box (e.g., prompt box 641), which may include text prompting the user that the device ejection operation was successful (e.g., "You have successfully ejected the device"). In some embodiments, the type of prompting information included in the prompt box 641 may also be an image, video, sound, etc., and this application embodiment does not limit this.

[0160] In this way, the electronic device 100 can enable users to manually control the hot-swapping of devices within the container during container operation, allowing users to open files within the device without rerunning the container, thus improving the user experience.

[0161] The following describes an exemplary electronic device 100 provided in an embodiment of this application.

[0162] Figure 7 The structure of the electronic device 100 provided in an embodiment of this application is illustrated by way of example.

[0163] The following description uses electronic device 100 as an example to illustrate the embodiment. It should be understood that electronic device 100 may have more than Figure 7 The more or fewer components shown can be combined into two or more components, or they can have different component configurations. Figure 7The various components shown can be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and / or application-specific integrated circuits.

[0164] like Figure 7 As shown, the electronic device 100 may include: a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, etc.

[0165] Processor 110 may include one or more processing units, such as: application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, memory, video codec, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0166] The controller can be the nerve center and command center of the electronic device 100. The controller can generate operation control signals according to the instruction opcode and timing signals to complete the control of fetching and executing instructions.

[0167] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0168] USB interface 130 is an interface compliant with the USB standard specification, specifically a Mini USB interface, Micro USB interface, USB Type-C interface, etc. USB interface 130 can be used to connect a charger to charge electronic device 100, and can also be used for data transfer between electronic device 100 and peripheral devices. In this embodiment, electronic device 100 can connect to mobile devices (e.g., USB flash drives, hard drives) via the USB interface. This interface can also be used to connect other electronic devices, such as AR devices.

[0169] The charging management module 140 is used to receive charging input from the charger.

[0170] The power management module 141 is used to connect the battery 142, the charging management module 140, and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140 to power the processor 110, internal memory 121, external memory, etc.

[0171] The external storage interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 through the external storage interface 120 to perform data storage functions. For example, music, video, and other files can be saved on the external memory card.

[0172] Internal memory 121 can be used to store computer executable program code, which includes instructions. Processor 110 executes various functional applications and data processing of electronic device 100 by running the instructions stored in internal memory 121. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function (such as facial recognition, fingerprint recognition, mobile payment, etc.). The data storage area may store data created during the use of electronic device 100 (such as facial information template data, fingerprint information templates, etc.). Furthermore, internal memory 121 may include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.

[0173] In this embodiment of the application, the electronic device 100 can also access the server of the cloud storage service provider by connecting to a network device (e.g., a cloud drive) via a network (e.g., Wi-Fi, Ethernet), thereby accessing and managing files and data stored in the network device.

[0174] In this embodiment of the application, the device type of electronic device 100 can be any of the following: mobile phone, tablet computer, handheld computer, desktop computer, laptop computer, ultra-mobile personal computer (UMPC), netbook, personal digital assistant (PDA), etc. This embodiment of the application does not limit the specific type of electronic device 100.

[0175] In this embodiment, infringement evidence can be obtained by checking whether the bridging directory (i.e., the aforementioned first bridging directory, such as / data / rootfs / bridge / ) inside and outside the container is set as a mount point and whether the propagation attribute of the mount point is set to shared, from outside the container (host machine). For example, the command #cat / proc / 1 / mountinfo|grep can be entered in the host operating system.

[0176] " / data / rootfs / bridge / ". If a result is returned and the result contains the shared attribute, it indicates that the bridging directory inside or outside the container (e.g., / data / rootfs / bridge / ) is set as the mount point and the propagation attribute of that mount point is set to shared.

[0177] In this embodiment, it can be determined by checking outside the container (host machine) whether the device (mobile device or network device) directory is mapped to other directories under the bridge directory inside and outside the container (i.e., the aforementioned first bridge directory, such as / data / rootfs / bridge / ).

[0178] The code snippet ` / data / rootfs / br idge / USB1 / ` is used to collect evidence of infringement. For example, in the host operating system, enter the command `#mount|grep USB`. If the result shows "tmpfson / data / rootfs / br idge / USB1 / ", it indicates that the device (e.g., USB1) directory is mapped to the bridging directory inside and outside the container (i.e., the aforementioned first bridging directory, such as ` / data / rootfs / br idge / `).

[0179] This application also provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it can implement the steps performed by the electronic device in the above method embodiments, or the steps performed by the human-computer interaction module and the computing module.

[0180] This application also provides a computer program product that, when run on a terminal device, enables the terminal device to perform the steps executed by the electronic device in the above method embodiments.

[0181] This application also provides a chip system, which includes a processor coupled to a memory. The processor executes a computer program stored in the memory to implement the steps performed by the electronic device in any of the method embodiments of this application. The chip system can be a single chip or a chip module composed of multiple chips.

[0182] The term "user interface (UI)," or simply "interface," used in the specification and accompanying drawings of this application, refers to the medium through which an application or operating system interacts and exchanges information with the user. It facilitates the conversion between the internal form of information and a form acceptable to the user. The user interface of an application is written in source code using specific computer languages ​​such as Java or Extensible Markup Language (XML). This source code is parsed and rendered on the terminal device, ultimately presenting user-recognizable content, such as images, text, and buttons. Controls, also known as widgets, are the basic elements of the user interface. Typical controls include toolbars, menu bars, text boxes, buttons, scroll bars, images, and text. The attributes and content of controls in the interface are defined using tags or nodes, such as XML tags. <textview> 、 <imgview> 、 <videoview>Nodes define the controls contained in the interface. A node corresponds to a control or property in the interface, and after parsing and rendering, the node is presented as the content visible to the user. In addition, many applications, such as hybrid applications, often contain web pages within their interfaces. A web page, also known as a webpage, can be understood as a special control embedded within the application interface. Web pages are source code written in a specific computer language, such as Hypertext Markup Language.

[0183] HTML (Hypertext Markup Language), Cascading Style Sheets (CSS), JavaScript (JS), etc., are all forms of webpage source code. These can be loaded and displayed as user-readable content by a browser or a webpage display component with similar functionality. The specific content contained in a webpage is also defined through tags or nodes in the webpage source code; for example, HTML uses tags or nodes to define the content. 、 、 <video> 、 <canvas>To define the elements and attributes of a webpage.

[0184] The most common form of user interface is the graphical user interface (GUI), which refers to a user interface related to computer operation displayed graphically. It can be an icon, window, control, or other interface element displayed on the screen of an electronic device. Controls can include visual interface elements such as icons, buttons, menus, tabs, text boxes, dialog boxes, status bars, navigation bars, and widgets.

[0185] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0186] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0187] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as meaning "if..." or "after..." or "in response to determining..." or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is detected" can be interpreted as meaning "if determining..." or "in response to determining..." or "when (the stated condition or event) is detected" or "in response to detecting (the stated condition or event)".

[0188] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0189] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.< / canvas> < / video> < / videoview> < / imgview> < / textview>

Claims

1. A device management method, applied to a first electronic device, characterized in that, The first electronic device runs a host operating system, and the host operating system runs a first container. The method includes: Before the first container starts, the first electronic device creates a first bridged directory in the host operating system and sets the first bridged directory as the first mount point; When the first container starts, the first electronic device creates a second loading point within the first container based on the information from the first loading point; After the first container starts, it receives a notification of device insertion. The first electronic device obtains the path of the device in the host operating system and maps the path of the device to the first directory under the first loading point; wherein, mapping the path of the device to the first directory is the first mapping action. The first electronic device propagates the first mapping action to the second loading point in the first container through the first loading point in the host operating system; The first electronic device obtains the second directory under the second loading point in the first container based on the first mapping action.

2. The method according to claim 1, characterized in that, The propagation attribute of the first load point is set to shared; and the propagation attribute of the second load point is set to shared.

3. The method according to claim 1 or 2, characterized in that, The first electronic device creates a second loading point in the first container based on the information from the first loading point, specifically including: The first electronic device maps the first bridged directory to a second bridged directory in the first container through the host operating system, and creates the second bridged directory as the second mount point in the first container.

4. The method according to any one of claims 1-3, characterized in that, The method further includes: After the first container is started, a notification is received that the device has been unplugged; The first electronic device unmaps the device path to the first directory under the first loading point in the host operating system and deletes the first directory under the first loading point.

5. The method according to any one of claims 1-3, characterized in that, The method further includes: While the device remains inserted, in response to a trigger operation, the first electronic device removes the second mount point from the first container. The path of the device received from the first mount point in the host operating system is mapped to the first directory.

6. The method according to any one of claims 1-3, characterized in that, The host operating system includes a container fusion service module and a device service module. Upon receiving a notification of device insertion, the first electronic device obtains the device's path within the host operating system and maps the device's path to a first directory under the first mounting point. Specifically, this includes: If the first electronic device detects the insertion of the device through the device service module, the device service module will call back to notify the container fusion service module; The first electronic device obtains the path of the device from the device service module through the container fusion service module in the host operating system, and maps the path of the device to the first directory under the first loading point.

7. The method according to claim 6, characterized in that, The device service module includes a first interface, which is used to register callbacks for device hot-plug events.

8. The method according to any one of claims 1-5, characterized in that, The notification of receiving device insertion specifically includes: The first electronic device receives a trigger operation through a first application in the host operating system; The first electronic device obtains the device's path in the host operating system and maps the device's path to a first directory under the first loading point, specifically including: The first electronic device obtains the path of the device through the first application in the host operating system, and maps the path of the device to the first directory under the first loading point.

9. The method according to any one of claims 1-5, characterized in that, The notification of receiving device insertion specifically includes: The first electronic device receives a trigger operation via a second application within the first container; The first electronic device sends a first notification to the host operating system from within the first container, the first notification being used to instruct the device to be inserted.

10. An electronic device, characterized in that, The electronic device runs a host operating system, and the host operating system runs a first container; Before the first container starts, the host operating system creates a first bridged directory and sets the first bridged directory as the first mount point; When the first container starts, the first container is used to create a second load point based on the information of the first load point; After the first container starts, it receives a notification that a device has been inserted. The host operating system then obtains the path of the device and maps the path of the device to a first directory under the first loading point. The mapping of the path of the device to the first directory is the first mapping action. The host operating system is used to propagate the first mapping action to the second loading point in the first container through the first loading point; The first container is used to obtain the second directory under the second load point based on the first mapping action.

11. The electronic device according to claim 10, characterized in that, The propagation attribute of the first load point is set to shared; and the propagation attribute of the second load point is set to shared.

12. The electronic device according to claim 10 or 11, characterized in that, The first container is specifically used to create the second bridging directory as the second mount point; The host operating system is used to map the first bridged directory to the second bridged directory in the first container.

13. The electronic device according to any one of claims 10-12, characterized in that, After the first container starts, the host operating system is also used to receive a notification that the device has been unplugged; The host operating system is also used to unmap the path of the device to the first directory under the first loading point, and delete the first directory under the first loading point.

14. The electronic device according to any one of claims 10-12, characterized in that, While the device remains inserted, in response to a triggering operation, the first container is also configured to remove the mapping action from the second mount point where the path of the device received from the first mount point in the host operating system is mapped to the first directory.

15. The electronic device according to any one of claims 10-12, characterized in that, The host operating system includes a container fusion service module and a device service module. If the device insertion is detected, the device service module is used to notify the container fusion service module via callback; The container fusion service module is used to obtain the path of the device from the device service module and map the path of the device to the first directory under the first loading point.

16. The electronic device according to claim 15, characterized in that, The device service module includes a first interface, which is used to register callbacks for device hot-plug events.

17. The electronic device according to any one of claims 10-14, characterized in that, The host operating system is specifically used to receive trigger operations through the first application; The host operating system is specifically used to obtain the path of the device through the first application and map the path of the device to the first directory under the first loading point.

18. The electronic device according to any one of claims 10-14, characterized in that, The host operating system is specifically used to receive a first notification sent by the first container, and the first notification is used to instruct the device to be inserted. The first container is used to receive a trigger operation through the second application.

19. A computer storage medium, characterized in that, The computer storage medium stores a computer program, which, when executed by a processor, causes the electronic device to perform the method as described in any one of claims 1-9.

20. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it causes the electronic device to perform the method as described in any one of claims 1-9.

Images