A USB OTG compatible method and system for implementing communication of a hon gming device debugging

Abstract

The application relates to a USB OTG compatible method and system for realizing debugging communication of a Hongmeng device, the method is based on uevent of a Hongmeng device kernel, detects USB connection state change conditions, and loads USB Gadget function through a daemon process in a user space in the case that the Hongmeng device is a USB Device, unloads or disables the USB Gadget function in the case that the Hongmeng device is a USB Host, is generated according to a script of the daemon process, and can be recognized and enumerated by a host end; the method realizes dynamic loading and unloading of the USB Gadget function through efficient monitoring of USB role states by the user space, thereby adapting to debugging communication requirements of the device under different connections, solving the problem that debugging is interrupted due to the fact that the USB role cannot be dynamically switched, reliably supporting dynamic switching of the USB role, and improving the advantages of debugging continuity and user experience.

Description

Technical Field

[0001] This application relates to the field of HarmonyOS device debugging technology, and in particular to a USB OTG compatible method and system for implementing HarmonyOS device debugging communication. Background Technology

[0002] Currently, the debugging USB interface of OpenHarmony devices operates in a fixed USB Device mode, dedicated to connecting to a PC for development and debugging. This design is inflexible in dynamic mixed-use scenarios. For example, after booting the Harmony device, a user might first connect a USB flash drive via the OTG interface (a USB technology that allows the device to dynamically switch between Host and Device) to read data (in which case the Harmony device needs to act as a USB Host), and then connect it to a PC for debugging (in which case the Harmony device needs to switch back to USB Device). However, the existing technical architecture cannot reliably support this role switching process, exhibiting the following shortcomings:

[0003] (1) Service status and physical connection mismatch: HDC (HarmonyOS Device Connector) debugging service cannot perceive the dynamic changes of USB physical connection status and role, which causes the service to fail to automatically rebuild and complete USB enumeration after switching from Host mode back to Device mode (after the USB device is connected to the host, the host reads the device descriptor through control transfer to load the corresponding driver and complete the initialization process), causing the PC to fail to recognize the device.

[0004] (2) Disrupted user experience: The unreliability of mode switching severely disrupts the continuity of the debugging process. After switching functions, users often need to perform additional operations such as restarting the device to restore the debugging function, which greatly limits the flexibility of on-site debugging and user experience. Summary of the Invention

[0005] The following is an overview of the subject matter described in detail herein. This overview is not intended to limit the scope of the claims.

[0006] The main objective of this disclosure is to propose a USB OTG compatible method and system for implementing debugging communication on HarmonyOS devices. This method can solve the problem of debugging interruption caused by the inability to dynamically switch USB roles in the prior art. It has the advantages of reliably supporting dynamic switching of USB roles, improving the continuity of debugging work and user experience.

[0007] A first aspect of this application provides a USB OTG compatible method for implementing debugging communication on HarmonyOS devices, the method comprising:

[0008] uevent, based on the HarmonyOS device kernel, detects changes in USB connection status.

[0009] Based on the changes in the USB connection status, the current role of the HarmonyOS device is determined, wherein the current role includes USB Host or USB Device;

[0010] When the current role changes, a role change event is generated and reported to a daemon process in user space. Through this daemon process, if the current role of the HarmonyOS device is USB Device, the USB Gadget function is loaded; if the current role of the HarmonyOS device is USB Host, the USB Gadget function is unloaded or disabled. The USB Gadget function is generated based on the script of the daemon process, and the configuration of the USB Gadget function includes the necessary information for the HDC service so that the host can identify and enumerate it. The HDC service is a debugging tool for the HarmonyOS system.

[0011] The USB OTG compatible method for implementing debugging communication on HarmonyOS devices provided in this embodiment has at least the following beneficial effects:

[0012] This method establishes an efficient monitoring mechanism for the USB role status in user space, enabling dynamic loading and unloading of USB Gadget functions. This adapts to the debugging and communication needs of devices in different connection scenarios, solving the problem of debugging interruption caused by the inability to dynamically switch USB roles in existing technologies. It has the advantages of reliably supporting dynamic switching of USB roles, improving the continuity of debugging work and user experience.

[0013] A second aspect of this application provides a USB OTG compatible system for implementing debugging communication on HarmonyOS devices, the system comprising:

[0014] The status change detection module is used to detect changes in the USB connection status based on the HarmonyOS device kernel's uevent.

[0015] The current role determination module is used to determine the current role of the HarmonyOS device based on the changes in the USB connection status, wherein the current role includes USB Host or USB Device;

[0016] The USB function configuration module is used to generate a daemon process that reports a role switch event to user space when the current role changes. This daemon process loads the USB Gadget function when the current role of the HarmonyOS device is USBDevice, and uninstalls or disables the USB Gadget function when the current role of the HarmonyOS device is USB Host. The USB Gadget function is generated based on the script of the daemon process, and its configuration includes the necessary information for the HDC service, enabling the host to recognize and enumerate it. The HDC service is a debugging tool for the HarmonyOS system.

[0017] A third aspect of this application provides an electronic device including at least one control processor and a memory for communicatively connecting to the at least one control processor; the memory stores instructions executable by the at least one control processor, the instructions being executed by the at least one control processor to enable the at least one control processor to perform a USB OTG compatible method for implementing HarmonyOS device debugging communication as described above.

[0018] A fourth aspect of this application provides a readable storage medium storing computer-executable instructions for causing a computer to execute a USB OTG-compatible method for implementing debugging communication for HarmonyOS devices, as described above.

[0019] A fifth aspect of this application provides a computer program product in which instructions, when executed by a processor of an electronic device, cause the electronic device to perform a USB OTG compatible method for implementing HarmonyOS device debugging communication as described above.

[0020] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

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

[0022] Figure 1 This is a flowchart illustrating a USB OTG compatible method for implementing debugging communication on HarmonyOS devices, provided in an embodiment of this application.

[0023] Figure 2This is a structural diagram of a USB OTG compatible system for implementing debugging communication on HarmonyOS devices, provided in an embodiment of this application.

[0024] Figure 3 This is a structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0026] In the description of this application, the use of terms such as "first," "second," etc., is for the purpose of distinguishing technical features only and should not be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated or the order of the technical features indicated.

[0027] In the description of this application, it should be understood that the orientation descriptions, such as up, down, etc., are based on the orientation or positional relationship shown in the accompanying drawings, and are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed or function in a specific orientation, and therefore should not be construed as a limitation of this application.

[0028] like Figure 1 As shown in one embodiment of this application, a USB OTG compatible method for implementing debugging communication on HarmonyOS devices is provided, the method comprising:

[0029] Step S110: Based on the HarmonyOS device kernel's uevent, detect changes in USB connection status;

[0030] Step S120: Determine the current role of the HarmonyOS device based on the changes in USB connection status, wherein the current role includes USB Host or USB Device;

[0031] Step S130: When the current role changes, a daemon process is generated to report the role change event to the user space. Through the daemon process, when the current role of the HarmonyOS device is USB Device, the USBGadget function is loaded, and when the current role of the HarmonyOS device is USB Host, the USB Gadget function is uninstalled or disabled. The USB Gadget function is generated according to the script of the daemon process, and the configuration of the USB Gadget function includes the required information of the HDC service so that the host can recognize and enumerate it. The HDC service is a debugging tool for the HarmonyOS system.

[0032] For ease of understanding, the following explains some key terms in this embodiment:

[0033] HarmonyOS devices refer to smart devices running the HarmonyOS operating system. They have USB interfaces and can perform data transfer and debugging communication. USB OTG, or USB On-The-Go, is a technology that allows USB devices to dynamically switch their USB role as Host or Device without relying on a PC. Through OTG functionality, devices can flexibly act as host or slave depending on the type of external device connected. uevent is a mechanism in the Linux kernel used to notify user space events. When the state of a device in the kernel changes, such as the connection, disconnection, or role switch of a USB device, the kernel sends corresponding event messages to user space through the uevent mechanism. USB Host refers to the device that plays a leading role in USB communication, responsible for managing the USB bus, enumerating connected USB devices, and assigning addresses to them, such as a HarmonyOS device when a USB flash drive is connected. USB Device refers to the device that plays a subordinate role in USB communication, responding to the instructions of the USB Host and providing specific functions, such as a HarmonyOS device connected to a PC for debugging. A daemon process is a program that runs in the background of a computer operating system and is usually not associated with any user interface. In this embodiment, the daemon process is responsible for listening to system events and triggering corresponding USB function configuration operations based on the events. HDC service, or HarmonyOS Device Connector service, is a debugging tool service provided by the HarmonyOS system. This service allows developers to perform operations such as application installation, log viewing, file transfer, and remote debugging on HarmonyOS devices via USB connection on a PC. USB enumeration refers to the process by which, after a USB device is connected to a USBHost, the Host reads the device's descriptor information, identifies the device's type and function, loads the corresponding driver, and ultimately enables the device to function properly.

[0034] This embodiment provides a USB OTG compatible method for implementing debugging communication on HarmonyOS devices, and its main technical features are described in detail below:

[0035] The method is based on the uevent of the HarmonyOS device kernel to detect changes in USB connection status. One implementation involves periodically querying the USB controller register or a specific node in the file system to obtain the USB connection status. For example, the ` / sys / class / usb_role / otg_role` file can be read at regular intervals to determine the current role of the USB interface. Another implementation involves registering a callback function in the kernel, which then actively notifies user space when the USB physical connection status changes.

[0036] This embodiment determines the current role of the HarmonyOS device based on changes in the USB connection status, where the current role includes either USB Host or USB Device. In one implementation, the current role can be inferred by analyzing the type or related parameters of USB connection status change events. For example, when an external storage device is detected connected to the USB interface, it can be determined that the HarmonyOS device should switch to the USB Host role; when a personal computer is detected connected to the USB interface, it can be determined that the HarmonyOS device should switch to the USB Device role. In another implementation, the current role information can be directly obtained by reading the status register of the USB controller hardware.

[0037] Furthermore, when the current role changes, a role change event is generated and reported to the daemon process in user space. Upon receiving the event, the daemon process will execute the corresponding USB Gadget function operation based on the HarmonyOS device's current role. Specifically, if the HarmonyOS device's current role is USB Device, the USB Gadget function is loaded; if the HarmonyOS device's current role is USB Host, the USB Gadget function is unloaded or disabled. For example, when the device switches from Host mode to Device mode, the daemon process will start the corresponding USB Gadget function. Conversely, when the device switches from Device mode to Host mode, the daemon process will stop or disable the currently running USB Gadget module.

[0038] The USB Gadget functionality is generated based on a script from the daemon process, and its configuration includes the necessary information for the HDC service, enabling the host to recognize and enumerate it. The HDC service serves as a debugging tool for the HarmonyOS system. In one implementation, the daemon process can generate the USB Gadget functionality based on a preset configuration file or hard-coded parameters. For example, a script can be manually written, containing basic information such as the USB device's vendor ID, product ID, device class, and subclass, as well as the interface descriptors required by the HDC service. When the USB Gadget functionality needs to be loaded, the daemon process executes the script, thereby creating and configuring the corresponding USB Gadget instance in the kernel. This configuration information is crucial for the host to correctly recognize and enumerate HarmonyOS devices, ensuring that the HDC service can start normally and communicate with the host.

[0039] In existing technologies, the USB debugging interface of HarmonyOS devices is usually fixed in USB Device mode, which cannot flexibly support the dynamic switching between Host and Device roles. When the device switches from Host mode back to Device mode, the HDC debugging service often fails to rebuild automatically, causing the PC to be unable to recognize the device. Users need to perform additional operations such as restarting the device to restore the debugging function, which affects the continuity of the debugging process and the user experience.

[0040] In contrast, this embodiment introduces a USB connection status detection mechanism based on the HarmonyOS device kernel uevent, enabling real-time awareness of changes in the USB physical connection status. This mechanism can accurately determine the current USB role of the HarmonyOS device, whether it is a Host or a Device. More importantly, when a role switch is detected, the system can generate a role switch event and report it to the daemon process in user space. The daemon process, acting as the primary coordinator, can effectively load or unload USB Gadget functions based on the current role. For example, when the device switches to the USB Device role, the daemon process can automatically load USB Gadget functions containing the information required for HDC services, ensuring that the PC can successfully identify and enumerate the HarmonyOS device as an HDC debugging device.

[0041] This embodiment effectively solves the problem in existing technologies where the HDC debugging service cannot perceive the USB physical connection status and dynamic changes in role. It avoids mismatches between service status and physical connection, allowing the HDC service to automatically rebuild and complete USB enumeration after switching back from Host mode to Device mode, thus ensuring that the PC can stably recognize the device. Furthermore, by automating the loading and unloading of USB Gadget functions, this embodiment eliminates the need for users to perform additional operations or restart the device after mode switching, improving the continuity of the debugging process and enhancing the flexibility and user experience of on-site device debugging. Therefore, this embodiment provides a HarmonyOS device USB OTG compatible debugging method that improves efficiency, stability, and user experience.

[0042] In summary, this embodiment enables dynamic identification of HarmonyOS devices between the roles of USB Host and USB Device. After the role switch is identified, the HDC debugging service can automatically adapt and re-establish itself, solving the problems of service status mismatch and physical connection failure and user experience disconnect in the prior art.

[0043] In one embodiment of this application, detecting changes in USB connection status includes:

[0044] Step S210: Initialize the uevent listening mechanism;

[0045] Step S220: Subscribe to all uevent multicast messages;

[0046] Step S230: Parse the uevent message;

[0047] Step S240: Extract key fields from the uevent message;

[0048] Step S250: Detect changes in USB connection status based on key fields.

[0049] The initialization of the uevent listening mechanism aims to establish a stable channel, enabling user-space applications to receive device event notifications from the kernel. Subscribing to all uevent multicast messages means that user-space applications will receive all device-related kernel events, ensuring that no critical information that might affect the USB connection status is missed. Parsing uevent messages converts their raw byte streams or strings into a data structure that the program can recognize and process, allowing for the extraction of useful information. This can be achieved through string splitting, pattern matching, and other methods to parse the received uevent message strings according to a predefined format, breaking them down into a series of attribute keys and corresponding values. Alternatively, existing library functions or frameworks can be used; these libraries or interfaces typically provide well-encapsulated APIs to automatically parse uevent messages and provide structured access. Extracting key fields from uevent messages aims to filter out specific attributes from the parsed messages that clearly indicate USB connection, disconnection, role switching, and other state changes. This can be done by matching a pre-defined keyword list to identify USB device plugging / unplugging events, or by building a state machine or rule engine to determine the nature of the event based on combinations of different fields.

[0050] This embodiment establishes a communication channel with the kernel's uevent subsystem and fully subscribes to all relevant multicast messages, ensuring broad coverage of USB connection events. Subsequently, by performing structured parsing of the raw uevent messages and precisely extracting key fields indicating changes in USB connection status, the system can quickly locate and identify valid USB-related information from a massive amount of kernel events. Finally, logical judgments are made based on these key fields to accurately detect changes in the USB connection status. This meticulous process accurately captures events at the USB physical connection level and transforms them into signals that are understandable and responsive to by the user space. This precise detection capability is the foundation for HarmonyOS devices to correctly determine their USB role (Host or Device) and load or unload USB Gadget functions accordingly, thus ensuring the reliability and stability of the USB OTG compatible method in debugging communication scenarios.

[0051] This embodiment provides a refined and reliable USB connection status detection mechanism. By explicitly initializing uevent listening, subscribing to multicast messages, parsing messages, extracting key fields, and performing detection based on these key fields, it ensures that HarmonyOS devices can comprehensively, promptly, and accurately perceive any changes in USB connection status. This detailed detection process avoids status judgment errors caused by information omissions or improper processing, thus providing a solid foundation for the accurate identification of the subsequent USB role (USB Host or USB Device). Furthermore, this ensures that the loading or unloading of USB Gadget functions can be executed promptly and correctly during role switching, greatly improving the stability and user experience of HarmonyOS devices in USB OTG debugging communication scenarios.

[0052] In one embodiment of this application, when the current role of the HarmonyOS device is a USB Device, loading the USB Gadget function includes:

[0053] Step S310: When the current role of the HarmonyOS device is USB Device, call the trigger_usb_gadget_configuration function to trigger the preset configuration script init.usb.configfs.cfg based on the call to the trigger_usb_gadget_configuration function;

[0054] Step S320: Execute the configuration script init.usb.configfs.cfg; wherein, executing the configuration script init.usb.configfs.cfg includes at least the following:

[0055] Write a configuration string to identify the HarmonyOS device as an HDC debugging device to the host.

[0056] Create a symbolic link to associate the ffs.hdc function, which represents the HDC communication protocol, with the corresponding Gadget configuration;

[0057] Configure the Gadget to bind to the USB device controller to complete the enumeration of USB Devices.

[0058] The `trigger_usb_gadget_configuration` function is called. This function can be a system API call executed by a user-space daemon upon receiving a role switch event, or it can be an interface provided by the kernel space, triggered from user space via a specific system call. Triggering the preset configuration script `init.usb.configfs.cfg` means starting a predefined script file containing specific configuration instructions for the USB Gadget functionality. The script's purpose is to automate the USB Gadget setup process, ensuring the device can be recognized and used by the host as expected. The script can be a shell script or a C / C++ program.

[0059] Writing a configuration string to identify the HarmonyOS device as an HDC debugging device to the host means setting specific text information in the USB device descriptor to provide a text description of the device to the connected host. Creating a symbolic link to associate the ffs.hdc function representing the HDC communication protocol with the corresponding Gadget configuration means logically connecting a specific USB function to the current USB Gadget configuration through file system operations. Binding the Gadget configuration to the USB device controller means associating the predefined USB Gadget configuration (e.g., device descriptor, configuration descriptor, and function) with the actual USB hardware controller. Its function is to activate the configuration, causing the USB device controller to begin broadcasting its USB capabilities according to the configuration and responding to the host's enumeration request, thereby completing the USB Device enumeration process.

[0060] In this embodiment, when the HarmonyOS device is used as a USB device, precise configuration and loading of USB Gadget functionality can be achieved. Specifically, by calling a specific function to trigger a preset configuration script, the script completes the writing of configuration strings, the association between HDC functionality and Gadget configuration, and the binding of Gadget configuration to the USB device controller. This ensures that the HarmonyOS device can be accurately identified by the host as an HDC debugging device and successfully complete enumeration. This solves the technical problem of how to efficiently and accurately configure HDC debugging functionality for HarmonyOS devices in OTG-compatible scenarios, thereby significantly improving the debugging convenience and compatibility of HarmonyOS devices.

[0061] In one embodiment of this application, the required information includes at least: endpoint descriptors and vendor information.

[0062] In one embodiment of this application, unloading the USB Gadget includes:

[0063] Unbind the Gadget function from the USB device controller.

[0064] Unloading a USB Gadget refers to the process of disabling or removing previously loaded USB Gadget functionality. Its purpose is to free up system resources, release the USB device controller from the Gadget functionality, and ensure the system is in a clean state for other operations, especially when the device needs to switch to USB Host mode. Unloading can be achieved by sending a specific command to the kernel's USB Gadget driver interface to unbind or disable the configured functionality, or by executing a reverse script or a dedicated uninstallation routine to undo the configuration steps performed during loading. Unbinding the Gadget functionality from the USB device controller is the core operation of unloading a USB Gadget. The USB device controller is a hardware component inside the HarmonyOS device, responsible for physically managing USB connections and communication. When the device acts as a USB Device, the Gadget functionality is bound to the controller, meaning the controller is configured to present these functions to the connected host. Unbinding effectively separates the software-defined Gadget functionality from the physical USB device controller. This causes the USB device controller to stop presenting the configured functionality to the host, resulting in the host detaching or unenumerating the device.

[0065] In this embodiment, when the HarmonyOS device switches its current role from USB Device to USB Host, the daemon process receives the role switch event and actively unbinds the USB Gadget function from the USB device controller, thereby unloading the USB Gadget function. When the HarmonyOS device is running as a USB Device, the USB Gadget function is bound to the USB device controller, enabling the device to be recognized by the host and perform HDC debugging communication. Once the device needs to switch to the USB Host role, the daemon process triggers the unbinding operation.

[0066] In one embodiment of this application, the daemon process uses the poll mechanism to monitor uevent.

[0067] To address this, this application further proposes that the daemon process uses a poll mechanism to monitor uevents. A daemon process is a computer program that runs in the background, typically starting when the system boots and terminating when the system shuts down. It operates independently of any terminal and is responsible for performing specific system tasks or services, such as monitoring system events, managing hardware resources, or providing network services. In this embodiment, the daemon process is responsible for receiving and processing USB role switching events, thereby managing the loading and unloading of USB Gadget functions.

[0068] The poll mechanism is an I / O multiplexing technique that allows a program to listen to multiple file descriptors simultaneously and be notified when any of them is ready for I / O operations. Compared to traditional blocking I / O or busy-wait, the poll mechanism utilizes CPU resources more efficiently because it puts the process to sleep when no events occur, until an event occurs or a timeout occurs. Listening to uevents refers to the daemon process receiving uevent messages from the kernel through a specific interface. These messages contain notifications of changes in the state of system hardware devices, such as the connection, disconnection, and role switching of USB devices. By listening to these messages, the daemon process can obtain real-time changes in USB connection status without actively querying the device status.

[0069] This embodiment solves the problem of efficient response of the daemon to changes in USB connection status by enabling the daemon to listen for uevents using the poll mechanism. Compared to traditional busy-wait or timed polling mechanisms, the poll mechanism allows the daemon to enter a sleep state when no events occur, effectively reducing CPU usage and system power consumption. This optimization is particularly important for resource-constrained HarmonyOS devices. Simultaneously, when the USB connection status changes, the poll mechanism can promptly wake up the daemon to handle the situation, ensuring the rapid loading or unloading of USB Gadget functions. This guarantees the smoothness and stability of debugging communication in USB OTG mode on HarmonyOS devices, improving user experience and development efficiency.

[0070] This application provides an embodiment that establishes an efficient monitoring mechanism for the current role of USB in user space, enabling dynamic loading and unloading of USB Gadget functions to adapt to the debugging communication needs of devices in different connection scenarios. The embodiment provides a USB OTG compatible method for implementing debugging communication on HarmonyOS devices, the method including:

[0071] Step S910, USB role status monitoring and event reporting:

[0072] When a change in USB connection status is detected, determine the current role (Host or Device) of the HarmonyOS device.

[0073] The role switching event (key parameters include SUBSYSTEM=usb_role, ACTION=change) is reported to user space in real time through the kernel's uevent mechanism.

[0074] Step S920, Dynamic USB function configuration;

[0075] A daemon (hdcd) runs in user space, continuously listening for uevent events. When the current role switches to USBDevice, the daemon dynamically configures the configfs interface by executing a series of predefined commands. Specifically, this includes the following two points:

[0076] Step S9211 triggers system property setting: param set sys.usb.ffs.ready 1, preparing the function configuration ready signal.

[0077] Step S9212 calls the relevant configuration script in init.usb.configfs.cfg to dynamically load and enable a USB Gadget function specifically designed for HDC communication. The function's configuration includes the endpoint descriptors and vendor information required by the HDC service, enabling the host to correctly identify and enumerate them.

[0078] When the current role is switched to USB Host, the daemon does the opposite, uninstalling or disabling the corresponding Gadget function and releasing resources.

[0079] The implementation logic of the key component in this embodiment—the user space daemon (hdcd)—and the dynamic configuration process of the USBGadget are described in detail below:

[0080] (1) Implementation of the user space daemon (hdcd);

[0081] The daemon process, as the core control function, is responsible for monitoring kernel events in real time and driving subsequent configuration processes. Its software architecture and main execution logic are shown in the following pseudocode:

[0082] / / Main daemon process entry function: completes initialization and enters the event loop;

[0083] function MainDaemonEntry();

[0084] Step 1: Initialize the Uevent listening mechanism;

[0085] status = SetupUeventMonitor();

[0086] If status != SUCCESS, then;

[0087] log_error("Failed to initialize uevent monitoring subsystem");

[0088] exit(ERROR_INIT_FAILURE);

[0089] end if;

[0090] log_info("Uevent monitor started successfully");

[0091] / / Step 2: Enter the main event loop, continuously wait for and process events;

[0092] while true do;

[0093] wait_for_events() / / Blocks and waits, with callbacks scheduled by the underlying event loop mechanism;

[0094] end while;

[0095] end function

[0096] / / Function: Establish and configure the kernel Uevent listening channel;

[0097] function SetupUeventMonitor() returns status;

[0098] / / Create a Socket under the Netlink protocol family, specifying the type as KOBJECT_UEVENT to receive kernel events;

[0099] socket_fd = create_socket(domain: NETLINK, type: KOBJECT_UEVENT);

[0100] / / Set Socket options to increase the receive buffer to avoid event loss;

[0101] set_socket_option(socket_fd, SO_RCVBUFFORCE, large_buffer_size);

[0102] / / Bind the Socket address and subscribe to all Uevent multicast messages;

[0103] bind_socket(socket_fd, address: NETLINK, group: ALL_GROUPS);

[0104] / / Register the Socket descriptor to the asynchronous event loop and specify the callback function when data arrives;

[0105] register_to_event_loop(socket_fd, callback: OnUeventReceived);

[0106] return SUCCESS;

[0107] end function;

[0108] / / Callback function: parses and responds to specific Uevent messages;

[0109] function OnUeventReceived(received_message) returns boolean;

[0110] / / Extract key fields from the message body separated by empty characters;

[0111] action = extract_field(received_message, "ACTION");

[0112] subsystem = extract_field(received_message, "SUBSYSTEM");

[0113] / / Core decision logic: Identify USB role switching events;

[0114] if subsystem equals "usb_role" and action equals "change" then;

[0115] log_info("Detected USB role change event");

[0116] / / Trigger the dynamic configuration process to configure the USB Gadget according to the new role;

[0117] trigger_usb_gadget_configuration(role: DEVICE);

[0118] return true / / Indicates that this event has been handled;

[0119] end if;

[0120] return false / / Indicates that this event has not been handled and can be ignored or handled by other modules;

[0121] end function;

[0122] (2) Dynamic configuration process of USB Gadget

[0123] When the daemon process hdcd detects that the USB role has been switched to DEVICE in the OnUeventReceived function, it calls the trigger_usb_gadget_configuration function. This function triggers the execution of the predefined configuration script init.usb.configfs.cfg by setting system properties. The configuration script content is as follows:

[0124] {

[0125] "name": "param:sys.usb.ffs.ready=1&¶m:sys.usb.config=hdc&¶m:sys.usb.configfs=1";

[0126] "condition": "sys.usb.ffs.ready=1&&sys.usb.config=hdc&&sys.usb.configfs=1";

[0127] "cmds": [

[0128] "write / config / usb_gadget / g1 / configs / b.1 / strings / 0x409 / configurationhdc";

[0129] "symlink / config / usb_gadget / g1 / functions / ffs.hdc; / config / usb_gadget / g1 / configs / b.1 / f1";

[0130] "write / config / usb_gadget / g1 / UDC ${sys.usb.controller}";

[0131] "setparam sys.usb.state ${sys.usb.config}"; ]

[0133] }

[0134] The script execution completed the following key steps:

[0135] (1) Set configuration descriptor: Write the configuration string to identify this device as "HDC debugging device" to the host;

[0136] (2) Associate function: Create symbolic links to associate the ffs.hdc function, which represents the HDC communication protocol, with the specified Gadget configuration;

[0137] (3) Activate Gadget: Bind the configured Gadget to an available USB device controller (UDC) to complete the enumeration preparation of USB Device.

[0138] In summary, the USB Device functionality that can be correctly recognized and enumerated by the host is dynamically ready, enabling seamless establishment of the debug channel in OTG Device mode.

[0139] In summary, this embodiment has the following beneficial effects:

[0140] (1) The native support of HDC for USB OTG connection has been optimized, so that developers can use the same set of debugging commands in both Host and Device modes without having to modify their debugging habits;

[0141] (2) Based on event-driven, it can dynamically respond to changes in USB connection status, realize the automatic creation and destruction of the debug channel, and provide a smooth user experience;

[0142] (3) The kernel uevent is efficiently monitored by the user space daemon combined with the poll mechanism, and the corresponding action is triggered only when the USB state changes. This avoids the extra resident overhead caused by polling or running heavy middleware, and is especially suitable for resource-constrained embedded devices.

[0143] (4) It does not depend on specific hardware. As long as the HarmonyOS device supports USB OTG, this solution can be applied, which has wide applicability.

[0144] like Figure 2 As shown in one embodiment of this application, a USB OTG compatible system for implementing debugging communication of HarmonyOS devices is provided. The system includes:

[0145] The state change detection module 1100 is used by uevent, which is based on the HarmonyOS device kernel, to detect changes in USB connection state.

[0146] The current role determination module 1200 is used to determine the current role of the HarmonyOS device based on the changes in the USB connection status, wherein the current role includes USB Host or USB Device;

[0147] The USB function configuration module 1300 is used to generate a daemon process that reports a role switch event to user space when the current role changes. Through the daemon process, when the current role of the HarmonyOS device is USB Device, the USB Gadget function is loaded, and when the current role of the HarmonyOS device is USB Host, the USB Gadget function is unloaded or disabled. The USB Gadget function is generated according to the script of the daemon process, and the configuration of the USB Gadget function includes the necessary information for the HDC service so that the host can recognize and enumerate it. The HDC service is a debugging tool for the HarmonyOS system.

[0148] It should be noted that the USB OTG compatible system for implementing debugging communication of HarmonyOS devices in this application embodiment and the aforementioned USB OTG compatible method for implementing debugging communication of HarmonyOS devices are based on the same inventive concept. Therefore, the USB OTG compatible system for implementing debugging communication of HarmonyOS devices in this application embodiment corresponds to the aforementioned USB OTG compatible method for implementing debugging communication of HarmonyOS devices. For the specific implementation process, please refer to the aforementioned USB OTG compatible method for implementing debugging communication of HarmonyOS devices, which will not be repeated here.

[0149] like Figure 3 This application also provides an electronic device, which includes:

[0150] At least one memory;

[0151] At least one processor;

[0152] At least one program;

[0153] The program is stored in memory, and the processor executes at least one program to implement the USB OTG compatible method for implementing debugging communication of HarmonyOS devices as described above in this disclosure.

[0154] This electronic device can be any smart terminal, including mobile phones, tablets, personal digital assistants (PDAs), and in-vehicle computers.

[0155] The electronic devices according to embodiments of this application will now be described in detail.

[0156] Electronic devices include:

[0157] The processor 1600 can be implemented using a general-purpose central processing unit (CPU), 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 disclosure.

[0158] The memory 1700 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 1700 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 1700 and is called and executed by the processor 1600 to implement a USB OTG compatible method for debugging communication of HarmonyOS devices according to an embodiment of this disclosure.

[0159] The input / output interface 1800 is used to implement information input and output.

[0160] The communication interface 1900 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0161] Bus 2000 transmits information between various components of the device (e.g., processor 1600, memory 1700, input / output interface 1800, and communication interface 1900);

[0162] The processor 1600, memory 1700, input / output interface 1800 and communication interface 1900 communicate with each other within the device via bus 2000.

[0163] This disclosure also provides a storage medium that is a readable storage medium storing computer-executable instructions for causing a computer to execute the aforementioned USB OTG compatible method for implementing debugging communication of HarmonyOS devices.

[0164] Memory, as a non-transitory readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be linked to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0165] The embodiments described in this disclosure are for the purpose of more clearly illustrating the technical solutions of this disclosure and do not constitute a limitation on the technical solutions provided by this disclosure. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by this disclosure are also applicable to similar technical problems.

[0166] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this disclosure, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0167] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0168] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0169] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0170] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0171] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication links shown or discussed may be through some interfaces; the indirect coupling or communication links between apparatuses or units may be electrical, mechanical, or other forms.

[0172] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0173] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0174] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause an electronic device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0175] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of the present invention without departing from the spirit and scope of the claims. All of these forms are within the protection scope of the present invention.

[0176] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A USB OTG compatible method for implementing debugging communication on HarmonyOS devices, characterized in that, The method includes: uevent, based on the HarmonyOS device kernel, detects changes in USB connection status. Based on the changes in the USB connection status, the current role of the HarmonyOS device is determined, wherein the current role includes USB Host or USB Device; When the current role changes, a role change event is generated and reported to a daemon process in user space. Through this daemon process, if the current role of the HarmonyOS device is USB Device, the USB Gadget function is loaded; if the current role of the HarmonyOS device is USB Host, the USB Gadget function is unloaded or disabled. The USB Gadget function is generated based on the script of the daemon process, and the configuration of the USB Gadget function includes the necessary information for the HDC service so that the host can identify and enumerate it. The HDC service is a debugging tool for the HarmonyOS system.

2. The USB OTG compatible method for implementing debugging communication on HarmonyOS devices according to claim 1, characterized in that, The detection of changes in USB connection status includes: Initialize the uevent listening mechanism; Subscribe to all uevent multicast messages; Parse uevent messages; Extract the key fields from the uevent message; Detect changes in USB connection status based on the key fields mentioned above.

3. The USB OTG compatible method for implementing debugging communication of HarmonyOS devices according to claim 1, characterized in that, When the current role of the HarmonyOS device is USB Device, loading the USB Gadget function includes: When the current role of the HarmonyOS device is USB Device, the trigger_usb_gadget_configuration function is called to trigger the preset configuration script init.usb.configfs.cfg. Execute the configuration script init.usb.configfs.cfg; wherein, executing the configuration script init.usb.configfs.cfg includes at least the following: Write a configuration string to identify the HarmonyOS device as an HDC debugging device to the host. Create a symbolic link to associate the ffs.hdc function, which represents the HDC communication protocol, with the corresponding Gadget configuration; Configure the Gadget to bind to the USB device controller to complete the enumeration of USB Devices.

4. The USB OTG compatible method for implementing debugging communication on HarmonyOS devices according to claim 3, characterized in that, The required information includes at least: endpoint descriptors and vendor information.

5. A USB OTG compatible method for implementing debugging communication on HarmonyOS devices according to claim 4, characterized in that, Uninstalling a USB Gadget includes: Unbind the Gadget function from the USB device controller.

6. The USB OTG compatible method for implementing debugging communication on HarmonyOS devices according to claim 1, characterized in that, The daemon process uses the poll mechanism to monitor uevent.

7. A USB OTG compatible system for implementing debugging communication on HarmonyOS devices, characterized in that, The system includes: The status change detection module is used to detect changes in the USB connection status based on the HarmonyOS device kernel's uevent. The current role determination module is used to determine the current role of the HarmonyOS device based on the changes in the USB connection status, wherein the current role includes USB Host or USB Device; The USB function configuration module is used to generate a daemon process that reports a role change event to user space when the current role changes. This daemon process loads the USB Gadget function when the current role of the HarmonyOS device is USB Device, and uninstalls or disables the USB Gadget function when the current role of the HarmonyOS device is USB Host. The USB Gadget function is generated based on the script of the daemon process, and its configuration includes the necessary information for the HDC service, enabling the host to recognize and enumerate it. The HDC service is a debugging tool for the HarmonyOS system.

8. An electronic device, characterized in that, It includes at least one control processor and a memory for communicatively connecting to the at least one control processor; the memory stores instructions executable by the at least one control processor, which, when executed by the at least one control processor, enable the at least one control processor to perform a USB OTG compatible method for implementing debugging communication of HarmonyOS devices as described in any one of claims 1 to 6.

9. A readable storage medium, characterized in that: The readable storage medium stores computer-executable instructions for causing a computer to execute a USB OTG compatible method for implementing debugging communication of HarmonyOS devices as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, When the instructions in the computer program product are executed by the processor of the electronic device, the electronic device performs a USB OTG compatible method for implementing HarmonyOS device debugging communication as described in any one of claims 1 to 6.

Images