I'm sending this email to gauge interest in a proposed change to host-side ADB:
I'm currently using ADB in conjunction with a USB mass storage device that must be powered on/off repeatedly via the /sys interface on Linux[1]. This was working correctly until I recently added ADB into the workflow. The problem I now see is that this sequence won't work:
power off device run set of adb commands (that cause the daemon to run in background) power on device
It seems the probing of my devices entry under /dev/bus/usb is causing it to enter a weird state. The only way I've gotten it out of that state is to run "adb kill-server" and then physically unplug/plug the device.
My proposed solution (attached) gives you two options:
* ignore USB devices entirely * black list certain devices
I would like to see this patch make it to AOSP in some form, but I'm not sure if my use-case is too specific for you guys. Any interest?
On Tuesday 15 January 2013 09:06 PM, Andy Doan wrote:
I'm sending this email to gauge interest in a proposed change to host-side ADB:
I'm currently using ADB in conjunction with a USB mass storage device that must be powered on/off repeatedly via the /sys interface on Linux[1]. This was working correctly until I recently added ADB into the workflow. The problem I now see is that this sequence won't work:
I had been working on this for some time but without any success and faced the same problem as observed by you (kill adb server, unplug and plug it). Ultimately we had to move it over to WiFi (ADB over WiFi) and keep it permanently by modifying init.rc, though its crude and cannnot be opted by user. May be it would be a good idea to have AOSP support ADB over WiFi, along with ADB over USB and thus allowing user to choose it runtime.
power off device run set of adb commands (that cause the daemon to run in background) power on device
It seems the probing of my devices entry under /dev/bus/usb is causing it to enter a weird state. The only way I've gotten it out of that state is to run "adb kill-server" and then physically unplug/plug the device.
My proposed solution (attached) gives you two options:
- ignore USB devices entirely
- black list certain devices
I would like to see this patch make it to AOSP in some form, but I'm not sure if my use-case is too specific for you guys. Any interest?
There are embedded solutions being developed around Android, which feels the pinch of one USB port. Like, using ADB when the device is connected for real time debugging is a concern. A generic solution will help to overcome this hurdle.
1: http://people.linaro.org/~doanac/sdmux/sdmux.sh
linaro-android mailing list linaro-android@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-android
On 01/15/2013 11:09 PM, Venkat Raghavulu wrote:
On Tuesday 15 January 2013 09:06 PM, Andy Doan wrote:
I'm sending this email to gauge interest in a proposed change to host-side ADB:
I'm currently using ADB in conjunction with a USB mass storage device that must be powered on/off repeatedly via the /sys interface on Linux[1]. This was working correctly until I recently added ADB into the workflow. The problem I now see is that this sequence won't work:
I had been working on this for some time but without any success and faced the same problem as observed by you (kill adb server, unplug and plug it). Ultimately we had to move it over to WiFi (ADB over WiFi) and keep it permanently by modifying init.rc, though its crude and cannnot be opted by user. May be it would be a good idea to have AOSP support ADB over WiFi, along with ADB over USB and thus allowing user to choose it runtime.
power off device run set of adb commands (that cause the daemon to run in background) power on device
It seems the probing of my devices entry under /dev/bus/usb is causing it to enter a weird state. The only way I've gotten it out of that state is to run "adb kill-server" and then physically unplug/plug the device.
My proposed solution (attached) gives you two options:
- ignore USB devices entirely
- black list certain devices
I would like to see this patch make it to AOSP in some form, but I'm not sure if my use-case is too specific for you guys. Any interest?
There are embedded solutions being developed around Android, which feels the pinch of one USB port. Like, using ADB when the device is connected for real time debugging is a concern. A generic solution will help to overcome this hurdle.
Thanks for the feedback. To get things rolling, I've submitted my patch to gerrit:
I had been having issues with erratic loss of connection to a USB accessory. The log showed "could not open /dev/usb_accessory". Extensive troubleshooting revealed that adb was interfering with the USB connection and invalidating the filedescriptor for the accessory.
On Tuesday, January 15, 2013 9:36:45 AM UTC-6, Andy Doan wrote:
I'm sending this email to gauge interest in a proposed change to host-side ADB:
I'm currently using ADB in conjunction with a USB mass storage device that must be powered on/off repeatedly via the /sys interface on I Linux[1]. This was working correctly until I recently added ADB into the workflow. The problem I now see is that this sequence won't work:
power off device run set of adb commands (that cause the daemon to run in background) power on device
It seems the probing of my devices entry under /dev/bus/usb is causing it to enter a weird state. The only way I've gotten it out of that state is to run "adb kill-server" and then physically unplug/plug the device.
My proposed solution (attached) gives you two options:
- ignore USB devices entirely
- black list certain devices
I would like to see this patch make it to AOSP in some form, but I'm not sure if my use-case is too specific for you guys. Any interest?
On 02/05/2013 11:45 PM, luis.feliu@gmail.com wrote:
I had been having issues with erratic loss of connection to a USB accessory. The log showed "could not open /dev/usb_accessory". Extensive troubleshooting revealed that adb was interfering with the USB connection and invalidating the filedescriptor for the accessory.
here's a patch that fixes my issues:
https://android-review.googlesource.com/#/c/50011/
I'm trying to get it upstreamed, but I'm also changing jobs in 2 days, so I may need some help getting it in shape for Colin.
linaro-android@lists.linaro.org
-
Andy Doan -
luis.feliu＠gmail.com -
Venkat Raghavulu