Obsolete
Status Update
Comments
ja...@gmail.com <ja...@gmail.com> #2
Please also ask your question at http://android.stackexchange.com/ and provide us with a link to the thread there.
en...@google.com <en...@google.com>
dj...@gmail.com <dj...@gmail.com> #3
@jasonspiro4, Will do. A Googler friend of mine encouraged me to enter this as a bug.
sa...@google.com <sa...@google.com> #4
This problem of bad cables, usb protocol issues dovetails well with the logcatd service being introduced. Sadly, because of security concerns, it is only available on eng and userdebug builds (we will rationalize trying to resolve the security concerns in the future).
But it does demonstrate a workaround, for example:
# adb shell
$ HOME=/data/local/tmp nohup /system/bin/logcat -b all -v threadtime -v usec -D -f /data/local/tmp/logcat -r 64 -n 256&
[1] 9882
$
. . . (even disconnect)
# adb shell
$ kill 9882
But it does demonstrate a workaround, for example:
# adb shell
$ HOME=/data/local/tmp nohup /system/bin/logcat -b all -v threadtime -v usec -D -f /data/local/tmp/logcat -r 64 -n 256&
[1] 9882
$
. . . (even disconnect)
# adb shell
$ kill 9882
sa...@google.com <sa...@google.com> #5
This issue is really a USB hardware reliability question. ASking for comment from badhri@ to determine the scope of the problem, if possible, and how we can mitigate. Perhaps we can address USB failures more gracefully over an adb connection, perhaps even within adb to retry and re-establish the connection automatically?
IMHO a continuous wired (or wireless) connection is always to be consider suspect, expectations still need to be managed.
Since this original response in #4, logcatd, or rather logpersistd, has been incorporated into the Developer Options as Persistent Logging feature. Bugreports will collect the results in the filesystem at FS/data/misc/logd/ for interpretation. This makes the feature easier to access under the scenario identified in #1.
However, because of security concerns it still is only available on eng and userdebug builds. b/36179643 has been created to re-evaluate if there are options to allow this to be enabled on user builds. The general consensus of engineering is still a strong NO at this moment so do not get your hopes up.
IMHO a continuous wired (or wireless) connection is always to be consider suspect, expectations still need to be managed.
Since this original response in #4, logcatd, or rather logpersistd, has been incorporated into the Developer Options as Persistent Logging feature. Bugreports will collect the results in the filesystem at FS/data/misc/logd/ for interpretation. This makes the feature easier to access under the scenario identified in #1.
However, because of security concerns it still is only available on eng and userdebug builds.
sa...@google.com <sa...@google.com>
ba...@google.com <ba...@google.com> #6
Without a bugreport, it is very hard to say what caused the USB disconnection.
Given that most of these are 3rd party devices, I am not sure what debug facilities are enabled by default when they get shipped.
Also, the bug seems to be really old and does not have any evidence of whether is it still seen.
Closing this as obselete for now. Please re-open if still seen and attach a bug report as well.
If not sure how to capture one, follow the instructions here:https://developer.android.com/studio/debug/bug-report.html
Given that most of these are 3rd party devices, I am not sure what debug facilities are enabled by default when they get shipped.
Also, the bug seems to be really old and does not have any evidence of whether is it still seen.
Closing this as obselete for now. Please re-open if still seen and attach a bug report as well.
If not sure how to capture one, follow the instructions here:
Description
1. Get into a car a passenger.
2. Open your laptop and plug in your phone.
3. Watch logcat
4. Ask the driver to make their way to the freeway using a route that take more than 5 minutes.
Roughly, after about 5 minutes the phone will disconnect from adb. Unplugging the phone and plugging it back in, the phone will reconnect but disconnect. Maybe it's an illusion but it seems the faster the car is driving, the quicker it will disconnect.
I've tested this with an HTC One M7 and a OnePlus One. If the OnePlus is not involved, the HTC always seems to be able to reconnected. However, once the OnePlus can't connect enough times, nothing can connect, not even the HTC One. The OnePlus seems to "poison the well" as it were.
I've tried several different usb cables and ports on my computer. I have not tried this with other computers or other phones. I'll be on a road trip this summer and can debugging more with a third phone.
If there are any tools that I can use or commands I can run to help debug this issue, please advise and I'll use them the next time I'm debugging my app in the car.
Lastly, sometimes my OnePlus disconnects while on my desk but it's far less frequent and usually only after a long period of not being used.