This logic appears to be racy, and it shouldn't actually be needed, if
our devices follow the USB spec. Use libusb_set_interface_alt_setting
on device initialization as well, to add one more thing that should
reset the data toggles.
Bug: 67320882
Bug: http://b/32952319
Test: python test_device.py
Change-Id: I392198af3d72c524b893e5056afa2b4617cea49c
(cherry picked from commit 4b5d4da6f6)
Revert the write_msg_lock part of commit b5e11415. A write which hangs
will hold onto the mutex, preventing the device kick from ever
happening, which also causes lots of other stuff to hang, due to Kick
being called with the transport lock taken.
Bug: 67320882
Test: python test_devices.py
Change-Id: Ie7c958799c93cad287c32d6bbef30c07f40c2d51
(cherry picked from commit 33d14b8748)
For example, "adb.exe shell -list" crashes without this fix.
Test: adb.exe shell -list-packages
Bug: 67320882
Change-Id: I96be44128ff3ecab7804b70074cbde630b3fc3d1
(cherry picked from commit af39885c9f)
...otherwise it could have weird dates when the device clock is wrong.
Bug: 67320882
Test: m -j32 adb && ./out/host/linux-x86/bin/adb bugreport test.zip && ls -l test.zip
Test: m -j32 adb_test && ./out/host/linux-x86/nativetest64/adb_test/adb_test
Fixes: 63927360
Change-Id: I3f87277f1acb97212a87b89639e42b6d7d300faa
(cherry picked from commit 4bfddbd20e)
Name each service thread specifically to improve debuggability.
Bug: http://b/65648324
Bug: 64709603 (presubmit balking at the line above)
Test: adb shell debuggerd -b `adb shell pidof adbd` during a sync
Change-Id: I644e25fc2f14a26eafd19f596e4e8f3c2bb79967
(cherry picked from commit bcadc77550)
The comment that was previously here says that local_socket_list_lock
must be taken, but this function is exposed to external callers that
can't possibly take the lock.
Bug: http://b/65419665
Bug: 64709603 (presubmit balking at the line above)
Test: python test_device.py
Change-Id: I12d464933936b2a210a827ccf19ea201020d8d78
(cherry picked from commit 62c92f0c05)
This reverts commit 7e197ef833.
The mutex lock in transport_unref hides a race that seems otherwise
hard to fix. Specifically, there's no synchronization between acquiring
a transport and attaching it to an asocket*, leading to badness if the
transport is closed in between the two operations.
Fix the original problem the reverted patch addressed by manually
unlocking before calling unregister_usb_transport.
Bug: http://b/65419665
Bug: 64709603 (presubmit balking at the line above)
Test: python test_device.py
Change-Id: I0ed0044129b1671b2c5dd1b9fa2e70a9b4475dc5
(cherry picked from commit e48ecce671)
Extend device selection to allow selecting a specific transport via
monotonically increasing identifier (visible in devices -l).
This is useful when using multiple devices (like hikey960...) that
have identical bogus serial numbers like 0123456789ABCDEF.
Bug: http://b/37043226
Bug: 65419665
Test: adb -t {1, 2, 9999999} {get-serialno, shell, features}
Change-Id: I55e5dc5a406a4eeee0012e39b52e8cd232e608a6
(cherry picked from commit b122b17555)
Previously, kick_all_transports would deadlock if there were any
inaccessible transports, because the transport kick function would call
unregister_usb_transport, which attempts to take the already-held
transport lock.
Fix this by switching the transport lock over to a recursive mutex.
Bug: 65419665
Test: manual
Change-Id: If61296ff4745e1699f3e216811c1383582627604
(cherry picked from commit 1db71afe97)
This reverts commit f1d3dbc32f.
With the following changes to move /sbin/adbd to /system/bin/adbd,
we don't need this workaround anymore.
https://android-review.googlesource.com/#/q/topic:move-adbd-to-system+(status:open+OR+status:merged)
Bug: 63313955
Bug: 63381692
Bug: 64822208
Test: 'adb root' works in VTS for a non-A/B device (userdebug GSI + user boot.img)
Change-Id: Ic1249d6abd7d6e6e7380a661df16d25447853a48
Merged-In: Ic1249d6abd7d6e6e7380a661df16d25447853a48
(cherry picked from commit 0603ec4294)
Bug: http://b/64508974
Bug: 64709603 (presubmit balking at the line above)
Test: mma
Change-Id: Ifba6a9dea3138b6d2a62c91cc0532f63986c048a
(cherry picked from commit 1d6c01b53d)
We want repeatable builds for minimal OTAs.
Bug: http://b/64634017
Bug: 64709603 (presubmit balking at the line above)
Test: repeated builds after `touch daemon/main.cpp` keep same md5sum
Change-Id: Iedeb44377ea45bbf20e2212760802198a57dc14a
ALLOW_ADBD_ROOT ('adb root') and ALLOW_ADBD_NO_AUTH (ro.adb.secure = 0)
are false in user build. This prevents a non-A/B device from running
Treble VTS because it requires 'adb root'. Without ALLOW_ADBD_NO_AUTH,
adb still can work if ro.adb.secure = 1. However, allowing it to be 0
is better for test automation.
The image combination in VTS is:
- system.img (userdebug): provided by Googlg
- boot.img (user): provided by the OEM <-- adbd is here
- vendor.img (user): provided by the OEM
This change allows 'adb root' and 'ro.adb.secure = 0' when the device is
unlocked in user build. No changes for userdebug/eng builds.
Note that the device must be unlocked when running VTS. Otherwise,
verified boot will prevent it from booting the system.img provided by
Google (no verity metadata).
Bug: 63313955
Bug: 63381692
Test: use the above image combination, check 'adb root' and
'ro.adb.secure = 0' can work
Change-Id: I109d96c950e54c4fb0ac0c98b989a20593681e52
This reverts commit f2f0b31850.
libusb seems to be causing flakiness on some machines. Disable it for
now.
Bug: http://b/62962248
Test: python test_device.py (with DeviceOfflineTest commented out)
Change-Id: Ia9de78ab772c22574cf5ca7facb78f22af6d7a71
(cherry picked from commit 969110ca4a)
This reverts commit f2f0b31850.
libusb seems to be causing flakiness on some machines. Disable it for
now.
Bug: http://b/62962248
Test: python test_device.py (with DeviceOfflineTest commented out)
Change-Id: Ia9de78ab772c22574cf5ca7facb78f22af6d7a71
Relax the shell command length limits when talking to an adbd with the
shell protocol.
shell is pretty much the only service that takes an arbitrarily long
string, so this is somewhat safe.
Bug: http://b/37716055
Test: `adb shell $(python -c 'print "echo " + "f" * (32*1024)') | wc` on L and master
Merged-In: I0737fd2244530ef8080f300cd3a3549a1ab93465
Change-Id: I0737fd2244530ef8080f300cd3a3549a1ab93465
Fix a deadlock that happened when a reader/writer thread released a
transport while the hotplug thread attempted to handle a device
disconnection. Decrementing a transport refcount to zero would hold the
global transport mutex and attempt to take the usb handles mutex, while
the hotplug thread would hold the usb handles mutex and try to call
unregister_usb_transport, which would attempt to take the global
transport mutex.
Resolve this by making transport_unref not take the global transport
mutex.
Bug: http://b/62423753
Test: python test_device.py
Merged-In: Ib48b80a2091a254527f3a7d945b6a11fae61f937
Change-Id: Ib48b80a2091a254527f3a7d945b6a11fae61f937
(cherry picked from commit 7e197ef833)
Relax the shell command length limits when talking to an adbd with the
shell protocol.
shell is pretty much the only service that takes an arbitrarily long
string, so this is somewhat safe.
Bug: http://b/37716055
Test: `adb shell $(python -c 'print "echo " + "f" * (32*1024)') | wc` on L and master
Change-Id: I0737fd2244530ef8080f300cd3a3549a1ab93465
adbd currently decides to use the QEMUD pipe if ro.kernel.qemu=1, as set
for ranchu. The Android container in Chrome OS doesn't have that
property set and it can't be set to 1 because it's used as equivalent to
"runs inside an emulator" throughout Android and changes the way
graphics are handled, whether Bluetooth is supported, etc., behaviour
that we do not want to trigger in Chrome OS.
adbd now also checks service.adb.transport to decide whether to use the
QEMUD (goldfish) pipe.
adbd still first checks for ro.kernel.qemu to preserve existing
behaviour and will still fallback to TCP if it can't use Goldfish.
Bug: 38497992
Test: tested by jmgao@ -thanks!- on aosp_angler, adb still works.
Change-Id: I8370704145ae7301ac7aeef81c5cbd94cfcb7fd7
Fix a deadlock that happened when a reader/writer thread released a
transport while the hotplug thread attempted to handle a device
disconnection. Decrementing a transport refcount to zero would hold the
global transport mutex and attempt to take the usb handles mutex, while
the hotplug thread would hold the usb handles mutex and try to call
unregister_usb_transport, which would attempt to take the global
transport mutex.
Resolve this by making transport_unref not take the global transport
mutex.
Bug: http://b/62423753
Test: python test_device.py
Change-Id: Ib48b80a2091a254527f3a7d945b6a11fae61f937
For unclear reasons, it seems that for some people, devices are
becoming accessible, inaccessible, and then inaccessible again.
Switch to a sleep for now.
Bug: http://b/62200735
Test: manual
Merged-In: Id51dcb188c3534a57c35cbfd30a181c99115a23c
Change-Id: Id51dcb188c3534a57c35cbfd30a181c99115a23c
(cherry picked from commit 5b8b10e078)
If a device is unplugged while it's being processed, we can be inside
register_usb_transport still when we call unregister_usb_transport,
leading to bad things happening. Move the call of
register_usb_transport into the scope guarded by usb_handles_mutex.
Bug: http://b/62200735
Test: manual
Merged-In: I2517dcb9d30d9a08cebbb5f715ae3fd30c510109
Change-Id: I2517dcb9d30d9a08cebbb5f715ae3fd30c510109
(cherry picked from commit 7dd382ded9)
For unclear reasons, it seems that for some people, devices are
becoming accessible, inaccessible, and then inaccessible again.
Switch to a sleep for now.
Bug: http://b/62200735
Test: manual
Change-Id: Id51dcb188c3534a57c35cbfd30a181c99115a23c
If a device is unplugged while it's being processed, we can be inside
register_usb_transport still when we call unregister_usb_transport,
leading to bad things happening. Move the call of
register_usb_transport into the scope guarded by usb_handles_mutex.
Bug: http://b/62200735
Test: manual
Change-Id: I2517dcb9d30d9a08cebbb5f715ae3fd30c510109
Previously, we would attempt to delete a usb_handle in both
device_disconnected and usb_close. If the one in device_disconnected
happened to happen first, usb_close would abort when it failed to find
the handle it was supposed to own.
Bug: http://b/62020217
Test: unplugging device on darwin
Change-Id: I6c6bf61bf89a4d9a23458c00b457080d3d6cc744
