LXC does not emulate anything - this is a container, not a virtual machine. The architecture of the container matches the architecture of the worker. The LXC runs on the worker to isolate certain programs (like fastboot and adb) from the worker. This means that those programs only see specific devices in /dev/bus/usb and do not have access to the full list of USB devices on that worker.
Peripheral support depends on how the peripheral is connected. We routinely test with an energy probe which has a USB A connection to the worker and power measurement soldered connections onto the DUT. The probe therefore shows up on the worker in /dev/bus/usb/ - to have that visible inside the LXC, the device dictionary simply defines the serial number of the device in /dev/bus/usb. The probe does not show up on the DUT at all.
There are two methods:
Devices like energy probes remain connected to the worker (and therefore visible in /dev/bus/usb on the worker) whether the DUT is powered on or off - these are static devices and the details go into static_info - these devices will be added every LXC used with the DUT whether the test job needs them or not, before the DUT is powered on. There is no udev ADD event because that only happens when the cable is unplugged or the worker rebooted.
Often, devices with a static device will also have their own USB connection to the worker, so the device dictionary lists a static_info for the peripheral and device_info for the DUT.
Peripherals which are connected to the worker but which lose power when the DUT loses power need to be defined in exactly the same way as the DUT itself - device_info. These will be added to the LXC when udev detects an ADD event on the worker.
Only devices which show up in /dev/bus/usb on the worker can be added to the LXC.
Anything else can only be managed solely on the DUT - if there is a USB ethernet dongle, it is up to the kernel on the DUT to raise an interface using that device, this has nothing at all to do with the LXC.