Methods for switching between multiple external devices and related equipment

Abstract

This application provides a method and related equipment for switching between multiple external devices. The method includes: determining a first path corresponding to the multiple inserted external devices, and reading the target device names corresponding to each of the external devices under the first path; generating multiple visual buttons corresponding to each of the external devices based on the read target device names; and activating the corresponding external device in response to a selection operation of the visual button. It can be seen that this method comprehensively considers the reading of external devices and the generation of visual buttons to achieve effective switching between multiple external devices, thereby realizing the identification and control of external devices according to target device names through the first path.

Description

Technical Field

[0001] The embodiments of this application relate to the field of device management technology, and in particular to a method for switching between multiple external devices and related equipment. Background Technology

[0002] In the relevant external device management methods, there are often program defects in the program calls when switching external devices connected to the Android system. These defects usually result in only the default external device being opened, making it difficult for users to customize the switching of external devices.

[0003] In some cases, external device applications that allow for custom switching may not be effectively compatible with other external device applications. Summary of the Invention

[0004] In view of this, the purpose of this application is to realize the custom switching of multiple external devices, and to propose a method and related equipment for switching multiple external devices.

[0005] For the purposes described above, this application provides several methods for switching external devices, including:

[0006] Determine the first path corresponding to the multiple inserted external devices, and read the target device name corresponding to each of the external devices under the first path;

[0007] Based on the read target device names, generate multiple visual buttons corresponding to each external device;

[0008] In response to the selection operation of the visual button, the corresponding external device is activated.

[0009] Further, before reading the target device name corresponding to each of the external devices under the first path, the process includes:

[0010] Generate a first device name under the first path, and perform standardization processing on the first device name;

[0011] The first device name that has undergone the standardization process is used as the target device name.

[0012] Further, generating the first device name under the first path includes:

[0013] Determine the second path corresponding to the plurality of inserted external devices;

[0014] All external devices are enumerated to the second path, and a second device name corresponding to each external device is generated under the second path;

[0015] The first device name is generated under the first path based on the second device name.

[0016] Further, reading the target device name corresponding to each of the external devices under the first path includes:

[0017] Read the folders corresponding to each of the external devices under the first path;

[0018] The name file of the external device is obtained from each of the corresponding folders, and the target device name of the corresponding external device is determined according to the name file.

[0019] Furthermore, the step of generating multiple visual buttons corresponding to each of the external devices based on the read target device names includes:

[0020] The number of external devices inserted is determined based on the number of folders read.

[0021] A corresponding number of visual buttons are generated based on the number of external devices, and the display name of the visual buttons is the same as the name of the target device.

[0022] Furthermore, the step of activating the corresponding external device in response to the selection operation of the visual button includes:

[0023] In response to the selection operation of the visualization button, the startup file path of the external device corresponding to the display name displayed by the visualization button is obtained;

[0024] Run the startup file located at the specified startup file path to start the corresponding external device.

[0025] Further, the step of running the startup file under the startup file path to start the corresponding external device includes:

[0026] Upon successful execution of the startup file located at the specified startup file path, the corresponding external device is started.

[0027] In response to the failure to run the startup file at the specified startup file path, start other external devices besides the external device.

[0028] Based on the same inventive concept, this application also provides a switching device for multiple external devices, including:

[0029] The device name acquisition module is configured to: determine a first path corresponding to the multiple inserted external devices, and read the target device name corresponding to each of the external devices under the first path;

[0030] The visual button generation module is configured to generate multiple visual buttons corresponding to each of the external devices based on the read target device names;

[0031] The device switching module is configured to: activate the corresponding external device in response to the selection operation of the visual button.

[0032] In some implementations, a device name generation module is also included, configured to:

[0033] Generate a first device name under the first path, and perform standardization processing on the first device name;

[0034] The first device name that has undergone the standardization process is used as the target device name.

[0035] In some implementations, the device name generation module is further configured to:

[0036] Determine the second path corresponding to the plurality of inserted external devices;

[0037] All external devices are enumerated to the second path, and a second device name corresponding to each external device is generated under the second path;

[0038] The first device name is generated under the first path based on the second device name.

[0039] In some implementations, the device name acquisition module is further configured to:

[0040] Read the folders corresponding to each of the external devices under the first path;

[0041] The name file of the external device is obtained from each of the corresponding folders, and the target device name of the corresponding external device is determined according to the name file.

[0042] In some implementations, the visual button generation module is further configured to:

[0043] The number of external devices inserted is determined based on the number of folders read.

[0044] A corresponding number of visual buttons are generated based on the number of external devices, and the display name of the visual buttons is the same as the name of the target device.

[0045] In some implementations, the device switching module is further configured to:

[0046] In response to the selection operation of the visualization button, the startup file path of the external device corresponding to the display name displayed by the visualization button is obtained;

[0047] Run the startup file located at the specified startup file path to start the corresponding external device.

[0048] In some implementations, the device switching module is further configured to:

[0049] Upon successful execution of the startup file located at the specified startup file path, the corresponding external device is started.

[0050] In response to the failure to run the startup file at the specified startup file path, start other external devices besides the external device.

[0051] Based on the same inventive concept, this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the switching method for multiple external devices as described in any of the above.

[0052] Based on the same inventive concept, this application also provides a non-transitory computer-readable storage medium, wherein the non-transitory computer-readable storage medium stores computer instructions for causing the computer to execute the switching method of the plurality of external devices as described above.

[0053] As can be seen from the above, the switching method and related equipment for multiple external devices provided in this application, based on the designed first path and target device name, comprehensively considers the reading of external devices and the generation of visual buttons when effectively switching between multiple external devices. This enables the identification of external devices according to the target device name through the first path, and the control of the corresponding external devices through the generated visual buttons, eliminating the defect of difficulty in switching between multiple external devices and completing the effective switching between multiple devices. Attached Figure Description

[0054] To more clearly illustrate the technical solutions in this application or related technologies, the drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0055] Figure 1 This is a flowchart illustrating a method for switching between multiple external devices according to an embodiment of this application;

[0056] Figure 2A flowchart for generating the target device name in this application embodiment;

[0057] Figure 3 A flowchart for generating the first device name in this application embodiment;

[0058] Figure 4 This is a flowchart illustrating the process of reading the target device name in an embodiment of this application.

[0059] Figure 5 This is a schematic diagram of a switching device module for multiple external devices according to an embodiment of this application;

[0060] Figure 6 This is a schematic diagram of the electronic device structure according to an embodiment of this application. Detailed Implementation

[0061] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with specific embodiments and the accompanying drawings.

[0062] It should be noted that, unless otherwise defined, the technical or scientific terms used in the embodiments of this application should have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms "first," "second," and similar terms used in the embodiments of this application do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed following the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect.

[0063] As described in the background section, the existing methods for switching between multiple external devices are still insufficient to meet the needs of device management in practice.

[0064] In the process of implementing this application, the applicant discovered that the main problem with the relevant methods for switching between multiple external devices is that the applications for related external devices that come with the Android system can often only open their default external devices, making it difficult to achieve effective switching when multiple devices are connected to the Android system at the same time.

[0065] When multiple external devices are connected to the Android system simultaneously, the system often experiences program defects in recognition and reading. Furthermore, forcibly switching between multiple external devices greatly increases the probability of device malfunction. For example, when switching between multiple USB cameras connected to the Android system, there is a possibility that one of the USB cameras may fail to display an image on the corresponding screen of the Android device.

[0066] Furthermore, the applicant also discovered that for other independent third-party applications that control external devices, their control logic for external devices is often self-contained and uses different program interfaces from the external device applications built into the Android system. These two types of applications are difficult to be effectively compatible with each other. Therefore, it is impossible to use the above two types of external device applications to effectively switch between multiple external devices at the same time.

[0067] Therefore, a method is needed that allows for custom switching between multiple external devices under any circumstances.

[0068] It is understandable that this method can be executed by any device, equipment, platform, or cluster of devices with computing and processing capabilities.

[0069] The technical methods of this application will be described in detail below through specific embodiments.

[0070] refer to Figure 1 A method for switching between multiple external devices according to one embodiment of this application includes the following steps:

[0071] Step S101: Determine the first path corresponding to the multiple inserted external devices, and read the target device name corresponding to each of the external devices under the first path.

[0072] In this step, multiple external devices can be audio-visual devices or storage devices, such as speakers, cameras, or flash drives. The target device name is a unique name generated under the first path after each external device is inserted. Each target device name corresponds to one external device, and the total number of target device names is equal to the total number of external devices. After an external device is inserted, the external device driver in the system can be activated. This driver is pre-installed in the system and identifies the inserted external devices.

[0073] In this specific example, a USB camera is used as an external device connected to an Android device's Android system. In other specific examples, the Android device and Android system can be replaced with other devices and operating systems; no specific restrictions are imposed here. Once the external USB camera is connected to the Android device, a connection is considered established between the external device and the Android system built into the Android device. Based on the insertion of the USB camera, the camera driver in the Android system can be launched, allowing the driver to recognize the inserted USB camera.

[0074] The camera driver can be an application that comes with the Android system, such as camera2, or a third-party standalone application, such as USB_camera. In this embodiment, no specific restrictions are placed on the type of camera application.

[0075] The camera driver identifies the plugged-in USB camera, which may include:

[0076] When an external USB camera is plugged into an Android device, the corresponding camera driver will obtain the first path corresponding to each USB camera to identify and read relevant information about the external USB camera. In this embodiment, the first path is the path accessed through the kernel driver. The kernel driver is one of the basic drivers of the system, and most device drivers run in kernel mode. Furthermore, based on the first path determined above, the target device name corresponding to each USB camera can be read under each first path.

[0077] In this embodiment, taking the insertion of three USB cameras as an example, the camera application can read the paths / sys / class / video0linux / , / sys / class / video1linux / , and / sys / class / video2linux / corresponding to each USB camera. Among them, the paths / sys / class / video0linux / , / sys / class / video1linux / , and / sys / class / video2linux / are used as the first paths in this embodiment.

[0078] Furthermore, the target device names corresponding to the three USB cameras read from the three first paths mentioned above are video0, video1, and video2.

[0079] As can be seen, this step enables the kernel driver to access the first path and read the target device name of the external USB camera.

[0080] Step S102: Based on the read target device names, generate multiple visual buttons corresponding to each external device.

[0081] In this step, based on the target device name read above, a corresponding number of visual buttons are generated in the Android device's visual interface.

[0082] When the target device names read are video0, video1, and video2, three visual buttons corresponding to video0, video1, and video2 are generated in the visualization interface.

[0083] Step S103: In response to the selection operation of the visual button, start the corresponding external device.

[0084] In this step, based on the visual buttons generated above, the corresponding external USB camera can be activated by operating each visual button.

[0085] Specifically, by operating the visual button named video0, the USB camera corresponding to video0 can be activated;

[0086] By operating the visual button named video1, the USB camera corresponding to video1 can be activated;

[0087] By activating the visual button labeled "video2", the USB camera corresponding to "video2" can be launched.

[0088] Based on the above steps S101 to S103, the external device is identified through the designed first path, and the external device is controlled through the generated visual button, which eliminates the defect of difficulty in switching between multiple external devices and completes the effective switching between multiple external devices.

[0089] In some embodiments, such as Figure 2 As shown, before reading the target device names corresponding to each of the external devices under the first path, the following steps are included:

[0090] Step S201: Generate a first device name under the first path and perform standardization processing on the first device name.

[0091] Specifically, when multiple external devices are inserted, each device has a different name due to different manufacturers and batches. The device name generated under the first path is the original factory-set device name, which is the first device name. Because the first device name varies for each external device, it needs to be standardized here to facilitate subsequent access and retrieval.

[0092] In specific examples of some embodiments, standardization can be achieved by assigning uniform numbers to external devices such as USB cameras, such as 0, 1, 2, 3, etc.; or by giving USB cameras custom names, such as corridor camera, conference room camera, and lobby camera, etc.

[0093] In specific examples of some embodiments, the standardized processing result can be set in the following form using the Java language:

[0094] Persist.sys.videoX

[0095] When three USB cameras are inserted, the first device names generated under the first path are videoX, videoY, and videoZ, respectively. The results of the normalization process can be represented as Persist.sys.video0, Persist.sys.video1, and Persist.sys.video2, respectively.

[0096] Specifically, in this embodiment, the Android system cannot predict the inserted external device, and therefore cannot determine the specific content of the device name to be obtained in advance. In other words, the device name needs to be obtained and received as a class definition, but the specific content of the class definition is uncertain. Therefore, in this case, the received class needs to be regarded as dynamic. Specifically, generics can be used at compile time to receive the class in order to obtain and call each first device name, and load the first device name after obtaining it, that is, load the obtained class.

[0097] It should be noted that this embodiment can be implemented using Java, or it can be implemented using C or C++. ++ Regarding the language implementation, the above-mentioned standardization process using Java is merely a specific example, and this embodiment does not specifically limit the languages ​​that can be used.

[0098] The code for standardizing the first device name can be embedded in the built-in camera application of the Android system or in a standalone third-party camera application. Based on the Android system environment set in this embodiment, the above standardization process can be performed using a reflection method.

[0099] Step S202: Use the first device name that has undergone the standardization process as the target device name.

[0100] The device name obtained after standardizing the first device name in step S201 is used as the target device name. In this embodiment, the target device names are Persist.sys.video0, Persist.sys.video1, and Persist.sys.video2.

[0101] In some embodiments, reference Figure 3 The step of generating the first device name under the first path includes the following steps:

[0102] Step S301: Determine the second path corresponding to the multiple inserted external devices.

[0103] The second path in this step refers to the path accessed through the interface. Specifically, the second path is the path connecting the Hardware Abstraction Layer (HAL) to the Android system interface; this second path is one that the HAL can directly call. When an external device connects to the system through the Android system interface, it establishes a connection with the HAL, thus determining the second path. Simultaneously, the driver for the external device, pre-installed in the kernel, can also recognize the insertion of the external device, establishing the first path. The first path is a connection to the kernel driver and does not connect to the Android system interface.

[0104] Step S302: Enumerate all the external devices to the second path, and generate a second device name corresponding to each external device under the second path.

[0105] It's important to note that the Hardware Abstraction Layer (HAL) primarily transforms kernel calls into direct access to and control of hardware, establishing hardware-related drivers. By mapping kernel driver functions to the HAL application programming interface (API), kernel drivers no longer interact directly with the hardware; instead, they access and control hardware resources through the HAL API.

[0106] In this embodiment, when an external device is inserted, the kernel driver for the external device recognizes the insertion and enumerates the external devices through the Hardware Abstraction Layer (HAL) application programming interface. When the inserted external device is a USB camera, the camera driver performs the enumeration operation; when the inserted external device is another device, the kernel driver corresponding to that other device can perform the enumeration.

[0107] The second device name is the original factory name of the external device. Since each external device has a different manufacturer, batch, etc., the second device name for each external device is also different. After enumerating each external device to the second path, a corresponding second device name is generated under the second path.

[0108] The second path can be specifically represented as:

[0109] / dev / videoX

[0110] Wherein, videoX represents the second device name. Based on the three USB cameras inserted in the above embodiment, the second paths of the three USB cameras can be determined as: / dev / videoX, / dev / videoY and / dev / videoZ, and the second device names generated under each second path are: videoX, videoY and videoZ, respectively.

[0111] Step S303: Generate the first device name under the first path according to the second device name.

[0112] Specifically, after the device driver completes the enumeration operation of the multiple inserted USB cameras, the generated second device names are videoX, videoY, and videoZ, respectively. By mapping under each first path, the generated first device names are videoX, videoY, and videoZ, respectively. The first device names are the same as the second device names. However, since they are under different paths, the first device names and the second device names are used to distinguish them here.

[0113] It should be noted that in related technologies, external devices associated with the second device name under the second path are called through the system interface to open the default external device, but this cannot satisfy the switching between multiple external devices. In this embodiment, all external devices are enumerated to the second path, and the second device name under the second path is mapped to the first device name under the first path. This allows subsequent calls to external devices to be made by reading the target device name under the first path, avoiding the problem that calling the second path can only open the default external device.

[0114] In some embodiments, such as Figure 4 As shown, reading the target device name corresponding to each of the external devices under the first path includes the following steps:

[0115] Step S401: Read the folders corresponding to each of the external devices under the first path.

[0116] Step S402: Obtain the name file of the external device from each of the corresponding folders, and determine the target device name of the corresponding external device based on the name file.

[0117] In this embodiment, based on the obtained first path, the kernel driver of the Android system, namely the camera driver in this embodiment, can be used to open the first path through the interface layer to read the folders generated under the first path corresponding to each USB camera; wherein, the interface layer in this embodiment is the Hardware Abstraction Layer (HAL).

[0118] Specifically, a folder corresponding to each USB camera is generated under each first path. For example, if three USB cameras are inserted, three folders are generated under the first path, each corresponding to the target device name of the USB camera.

[0119] Furthermore, in each folder, a corresponding name file is generated based on the target device name. The content recorded in each name file is used as the target device name for the corresponding first path. The target device name can be video0, video1, and video2.

[0120] In some embodiments, generating multiple visual buttons corresponding to each of the external devices based on the read target device names includes:

[0121] The number of external devices inserted is determined based on the number of folders read.

[0122] A corresponding number of visual buttons are generated based on the number of external devices, and the display name of the visual buttons is the same as the name of the target device.

[0123] Specifically, the camera driver can read the name files corresponding to the inserted USB cameras from various folders, identify the target device name of the corresponding inserted USB camera using the name files, and generate visual buttons based on the number of folders read and the target device names read.

[0124] In some embodiments, the camera driver can also determine the number of inserted USB cameras based on the number of name files read. There is no specific limitation on the execution order of obtaining the number of USB cameras and identifying the target device name of each USB camera.

[0125] In some embodiments, in the display interface of the camera driver, if the camera driver does not detect that a USB camera is plugged into the Android device, no visual buttons are displayed; if the camera driver detects that at least one USB camera is plugged into the Android device, a corresponding number of visual buttons are generated in the display interface and are in a first clickable state. This first state can be represented by a color such as green, a custom sound, or a custom graphic. Furthermore, based on the visual buttons generated above, when the camera driver detects that at least one USB camera plugged into the Android device has been unplugged, the visual button corresponding to that USB camera is removed, and a custom sound can be used to indicate that the USB camera has been unplugged.

[0126] In some other embodiments, the display interface of the camera application may have multiple visual buttons, each visual button corresponding to a USB port on the Android device and a USB camera plugged into the USB port, and the plugged USB camera can be controlled through the visual button.

[0127] Specifically, the display state of each visual button can be set to have a first state that allows clicking and a second state that disallows clicking.

[0128] Specifically, when the camera driver detects that at least one USB camera is plugged into the Android device, a corresponding number of visual buttons will appear in the first clickable state.

[0129] When the camera application does not recognize that a USB camera is plugged into the Android device, the visual buttons will enter a second state. This second state indicates that the visual buttons are not allowed to be clicked or are invalid after being clicked. This state can be represented by a color different from the first state, such as red, or by a custom graphic different from the first state.

[0130] Furthermore, based on the visual buttons generated above, when the camera application detects that at least one USB camera that has been plugged into the Android device has been unplugged, the display state of the visual button corresponding to each unplugged USB camera is updated to a second state where it is not allowed to be clicked, and a custom sound can be used to indicate that the visual button has entered the second state.

[0131] Furthermore, each visual button in the first state can generate a display name based on the name file in the aforementioned folder. Therefore, the display name of each visual button is the same as the name of its corresponding target device, and this display name is presented in the display interface of the visual button to prompt the user about the USB camera corresponding to the visual button.

[0132] For the visual button that is displayed in the first state, you can set two click states: on and off. You can turn the corresponding USB camera on or off by clicking the visual button in the first state.

[0133] Specifically, for at least one USB camera that is identified as being inserted into an Android device, the corresponding visual buttons are in a closed state before being clicked, and the visual buttons display the word "Start" on their respective display interfaces to prompt the user that the closed USB camera can be started by clicking.

[0134] In some embodiments, activating the corresponding external device in response to a selection operation on the visual button includes:

[0135] In response to the selection operation of the visualization button, the startup file path of the external device corresponding to the display name displayed by the visualization button is obtained;

[0136] Run the startup file located at the specified startup file path to start the corresponding external device.

[0137] Specifically, the startup file path of the USB camera corresponding to the visual button is obtained. By running the startup file under the startup file path, the corresponding USB camera is launched, so that the camera application can identify and select the device through the target device name under the first path to complete the selection and launch of multiple external USB cameras.

[0138] The camera application can use encryption and decryption procedures to restrict permissions for launching the USB camera.

[0139] Specifically, after clicking the visual button that displays the word "Start", the corresponding USB camera does not start immediately. The camera application will call the encryption and decryption program, prompting the user to enter the correct pre-set unlock key to start the USB camera. The encryption and decryption program can also use biometric technology instead of the character-based unlock key.

[0140] The biometric features involved in the biometric identification described in this application embodiment may include, for example, eye features, voiceprints, fingerprints, palm prints, heartbeats, pulses, chromosomes, DNA, and human dental bite marks. Among them, eye prints may include biometric features such as irises and sclera.

[0141] Furthermore, for USB cameras that are powered on, the corresponding visual button will be updated to display the word "Close" on the screen, prompting the user to close the powered-on USB camera by clicking it.

[0142] In some embodiments, running the startup file under the startup file path to start the corresponding external device includes:

[0143] Upon confirming that the startup file in the specified startup file path has been successfully executed, the corresponding external device is started.

[0144] In response to the failure to run the startup file at the specified startup file path, start other external devices besides the external device.

[0145] In this embodiment, a default camera can be set for the camera driver.

[0146] Specifically, for multiple USB hardware interfaces on an Android device used to plug in a USB camera, any one of them can be selected as the default interface, and the USB camera plugged into that default interface can be used as the default camera.

[0147] Furthermore, the camera driver can directly start a USB camera that is detected and plugged into the default interface, and display the word "Close" on the visualization button when it is not clicked.

[0148] In this embodiment, for multiple USB hardware interfaces on an Android device used for inserting USB cameras, the camera driver can select at least one of these interfaces as a backup interface and designate the USB camera inserted into the backup interface as a backup USB camera.

[0149] Furthermore, when the camera driver has alternative cameras set up, that is, when setting up alternative interfaces, if the default interface cannot directly start the default camera by running the corresponding startup file, in addition to starting other corresponding USB cameras by clicking other visual buttons in the first state, alternative USB cameras can also be started directly based on the pre-configuration of the camera application.

[0150] As can be seen, the switching method for multiple external devices provided in this application, based on the designed first path and target device name, comprehensively considers the reading of external devices and the generation of visual buttons when effectively switching between multiple external devices. This enables the identification of external devices according to the target device name through the first path, and the control of the corresponding external devices through the generated visual buttons, thus eliminating the defect of difficulty in switching between multiple external devices.

[0151] Furthermore, this method overcomes the barriers between different external device drivers on different system interfaces, enabling effective compatibility between the Android system's built-in camera driver and independent third-party camera drivers, and allowing switching between multiple USB cameras.

[0152] It should be noted that the method of the embodiments of this application can be executed by a single device, such as a computer or server. The method of this embodiment can also be applied in a distributed scenario, where multiple devices cooperate to complete the task. In such a distributed scenario, one of these devices may execute only one or more steps of the method of the embodiments of this application, and the multiple devices will interact with each other to complete the method described.

[0153] It should be noted that the above description describes some embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in a different order than that shown in the above embodiments and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0154] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, the embodiments of this application also provide a switching device for multiple external devices.

[0155] refer to Figure 5 The switching device for multiple external devices includes: a device name acquisition module 501, a visual button generation module 502, and a device switching module 503.

[0156] The device name acquisition module 501 is configured to: determine a first path corresponding to the multiple inserted external devices, and read the target device name corresponding to each of the external devices under the first path;

[0157] The visual button generation module 502 is configured to generate multiple visual buttons corresponding to each of the external devices based on the read multiple target device names;

[0158] The device switching module 503 is configured to: activate the corresponding external device in response to the selection operation of the visual button.

[0159] As an optional embodiment, a device name generation module 504 is also included, configured to:

[0160] Generate a first device name under the first path, and perform standardization processing on the first device name;

[0161] The first device name that has undergone the standardization process is used as the target device name.

[0162] As an optional embodiment, the device name generation module 504 is further configured to:

[0163] Determine the second path corresponding to the plurality of inserted external devices;

[0164] All external devices are enumerated to the second path, and a second device name corresponding to each external device is generated under the second path;

[0165] The first device name is generated under the first path based on the second device name.

[0166] As an optional embodiment, the device name acquisition module 501 is further configured to:

[0167] Read the folders corresponding to each of the external devices under the first path;

[0168] The name file of the external device is obtained from each of the corresponding folders, and the target device name of the corresponding external device is determined according to the name file.

[0169] As an optional embodiment, the visual button generation module 502 is specifically configured as follows:

[0170] The number of external devices inserted is determined based on the number of folders read.

[0171] A corresponding number of visual buttons are generated based on the number of external devices, and the display name of the visual buttons is the same as the name of the target device.

[0172] As an optional embodiment, the device switching module 503 is specifically configured as follows:

[0173] In response to the selection operation of the visualization button, the startup file path of the external device corresponding to the display name displayed by the visualization button is obtained;

[0174] Run the startup file located at the specified startup file path to start the corresponding external device.

[0175] In some embodiments, the device switching module 503 is further configured to:

[0176] Upon confirming that the startup file in the specified startup file path has been successfully executed, the corresponding external device is started.

[0177] In response to the failure to run the startup file at the specified startup file path, start other external devices besides the external device.

[0178] For ease of description, the above apparatus is described in terms of its functions, divided into various modules. Of course, in implementing the embodiments of this application, the functions of each module can be implemented in one or more software and / or hardware.

[0179] The apparatus described above is used to implement the switching method for corresponding multiple external devices in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0180] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, embodiments of this application also provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the switching method of multiple external devices as described in any of the above embodiments.

[0181] Figure 6This embodiment illustrates a more specific hardware structure of an electronic device, which may include a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. The processor 1010, memory 1020, input / output interface 1030, and communication interface 1040 are interconnected internally via the bus 1050.

[0182] The processor 1010 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application.

[0183] The memory 1020 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 1020 can store the operating system and other applications. When the technical solutions provided in the embodiments of this application are implemented by software or firmware, the relevant program code is stored in the memory 1020 and is called and executed by the processor 1010.

[0184] The input / output interface 1030 is used to connect input / output modules to realize information input and output. Input / output modules can be configured as components within the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Input devices may include keyboards, mice, touchscreens, microphones, various sensors, etc., while output devices may include displays, speakers, vibrators, indicator lights, etc.

[0185] The communication interface 1040 is used to connect a communication module (not shown in the figure) to enable communication between this device and other devices. The communication module can communicate via wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0186] Bus 1050 includes a pathway for transmitting information between various components of the device, such as processor 1010, memory 1020, input / output interface 1030, and communication interface 1040.

[0187] It should be noted that although the above-described device only shows the processor 1010, memory 1020, input / output interface 1030, communication interface 1040, and bus 1050, in specific implementations, the device may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the above-described device may only include the components necessary for implementing the embodiments of this application, and not necessarily all the components shown in the figures.

[0188] The apparatus described above is used to implement the switching method for corresponding multiple external devices in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0189] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this application also provides a non-transitory computer-readable storage medium storing computer instructions for causing the computer to execute the switching method of multiple external devices as described in any of the above embodiments.

[0190] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0191] The computer instructions stored in the storage medium of the above embodiments are used to cause the computer to execute the switching method of multiple external devices as described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0192] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of this application (including the claims) is limited to these examples; within the framework of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of the embodiments of this application as described above, which are not provided in detail for the sake of brevity.

[0193] Additionally, to simplify the description and discussion, and to avoid obscuring the embodiments of this application, the well-known power / ground connections to integrated circuit (IC) chips and other components may or may not be shown in the provided drawings. Furthermore, the apparatus may be shown in block diagram form to avoid obscuring the embodiments of this application, and this also takes into account the fact that the details of implementation of these block diagram apparatuses are highly dependent on the platform on which the embodiments of this application will be implemented (i.e., these details should be fully understood by those skilled in the art). While specific details (e.g., circuits) have been set forth to describe exemplary embodiments of this application, it will be apparent to those skilled in the art that the embodiments of this application can be implemented without these specific details or with variations thereof. Therefore, these descriptions should be considered illustrative rather than restrictive.

[0194] Although this application has been described in conjunction with specific embodiments thereof, many substitutions, modifications, and variations of these embodiments will be apparent to those skilled in the art from the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may be used with the embodiments discussed.

[0195] The embodiments of this application are intended to cover all such substitutions, modifications, and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the embodiments of this application should be included within the protection scope of this application.

Claims

1. A switching method of a plurality of external devices, comprising: determining a first path corresponding to a plurality of inserted external devices, and generating a first device name in the first path, including: determining a second path corresponding to the plurality of inserted external devices; the second path refers to a path accessed through an interface; enumerating all the external devices to the second path, and generating a second device name corresponding to each of the external devices in the second path; generating the first device name in the first path according to the second device name; reading a target device name corresponding to each of the external devices in the first path; the first path is established after the insertion of the external device is recognized by a driver of the external device pre-stored in a kernel, and the first path is a path connected to a kernel driver; generating a plurality of visual buttons corresponding to each of the external devices according to the read plurality of target device names; starting the corresponding external device in response to a selection operation on the visual button.

2. The method of claim 1, wherein, Before the reading of the target device name corresponding to each of the external devices in the first path, comprising: standardizing the first device name; taking the first device name after the standardization as the target device name.

3. The method of claim 1, wherein, The reading of the target device name corresponding to each of the external devices in the first path, comprising: reading a folder corresponding to each of the external devices in the first path; obtaining a name file of the external device from the corresponding folder, and determining the target device name of the corresponding external device according to the name file.

4. The method of claim 3, wherein, The generating of the plurality of visual buttons corresponding to each of the external devices according to the read plurality of target device names, comprising: determining the number of inserted external devices according to the number of read folders; generating a corresponding number of visual buttons according to the number of external devices; the display name of the visual button is the same as the target device name.

5. The method of claim 4, wherein, The starting of the corresponding external device in response to the selection operation on the visual button, comprising: obtaining a start file path of the external device corresponding to the display name displayed by the visual button in response to the selection operation on the visual button; running a start file in the start file path to start the corresponding external device.

6. The method of claim 5, wherein, The running of the start file in the start file path to start the corresponding external device, comprising: starting the corresponding external device in response to the determination that the running of the start file in the start file path is successful; starting other external devices except the external device in response to the determination that the running of the start file in the start file path is failed. 7.A switching device of a plurality of external devices, comprising: a device name obtaining module configured to determine a first path corresponding to a plurality of inserted external devices, and generate a first device name in the first path, including: determining a second path corresponding to the plurality of inserted external devices; the second path refers to a path accessed through an interface; enumerating all the external devices to the second path, and generating a second device name corresponding to each of the external devices under the second path; generating the first device name under the first path according to the second device name; reading a target device name corresponding to each of the external devices under the first path; the first path is established after the insertion of the external device is recognized by the driver of the external device pre-installed in the kernel, and the first path is a path connected to the kernel driver; a visual button generation module configured to generate a plurality of visual buttons corresponding to each of the external devices according to the read plurality of target device names; a device switching module configured to start the corresponding external device in response to a selection operation on the visual button.

8. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable by the processor, wherein, The processor implements the method of any one of claims 1-6 when executing the computer program.

9. A non-transitory computer-readable storage medium, comprising: The non-transitory computer readable storage medium stores computer instructions for causing a computer to execute the method of any one of claims 1-6.

Images