OS X reports maxPacketSize as wMaxPacketSize * (bMaxBurst + 1) in the
deprecated GetPipeProperties function. Use the also-deprecated
GetPipePropetiesV2 API to get bMaxBurst and figure out what
wMaxPacketSize is. (This file is going to go away eventually, so don't
bother with switching to the recommended GetPipePropertiesV3, since
it would be a substantially larger charge.)
libusb is unaffected.
Bug: http://b/77733422
Test: python test_device.py
Change-Id: I66517d699a4f39b93ba5eb7882bd8ee6c70f3672
Add an implementation of std::make_unique for Windows, where we're
currently stuck with C++11, and switch some uses of new over to it.
Test: treehugger
Change-Id: I99b85f07754adda7c525243480c3e0bce9a25ce7
* changes:
adb: remove meaningless const.
adb: convert Connection to a nonblocking interface.
adb: use soong version stamping.
adb: switch over to Android.bp.
Added by I7255d45335fa009dc9e5de99dff67af52bd70e06
Bug: None
Test: Ran the analyzer. Complaint is gone.
Change-Id: Id9b8debd8b9690210f5a8e19154ee3a5095b8fbd
Rearrange some files while we're doing this.
Bug: http://b/71721338
Test: manually ran adb on windows
Change-Id: Ie47bda82279e4b9521505ad0353bf9ef649fc7d7
Add a way to test LeakSanitizer with the server by adding an
environment variable that intentionally leaks.
Test: ASAN_OPTIONS=detect_leaks=1:leak_check_at_exit=1 ADB_LEAK=1 adb server nodaemon
Change-Id: I7255d45335fa009dc9e5de99dff67af52bd70e06
We don't actually need to use quick_exit to avoid calling static
destructors, since we have -Wexit-time-destructors to guarantee we
don't actually have any, and this precludes the use of asan's exit time
leak checking, so switch back to atexit/exit.
Test: ASAN_OPTIONS=detect_leaks=1:leak_check_at_exit=1 adb server nodaemon with a manually inserted leak
Change-Id: Id8178913f64cb02c820c5073351369a9e4d8c74d
This still doesn't work yet because libusb doesn't support hotplug on
Windows yet, but it's in the milestones for the next libusb release,
and this is enough to start poking around with the WinUSB device-side
stuff, so leave it broken for now.
Bug: http://b/68993980
Test: set ADB_LIBUSB=1; adb.exe server nodaemon aborts in the expected place
Change-Id: Icef7d46e31c847d6a8e724c6f58ae5db43673c16
OS X appears to be misreporting the maximum packet size on some
hardware. Disable this on OS X until we figure out what's going on.
Bug: http://b/65063965
Bug: https://issuetracker.google.com/70244520
Test: python test_device.py on linux with CHECK_PACKET_OVERFLOW disabled
Test: python test_device.py on darwin (but on hardware that wasn't reproducing this)
Change-Id: I57e1adfa162e40ed79f71f97af552b3f0519324e
Future adjustments triggered cleanup and transition of adb/adb.h and
adb/client/usb_windows.cpp to be moved to Android coding standard.
Test: build
Bug: 63736262
Bug: 38446744
Bug: 66912053
Change-Id: I6eb3f0665b9670b9b3d5f5397f271605b48f4ff0
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: http://b/32952319
Test: python test_device.py
Change-Id: I392198af3d72c524b893e5056afa2b4617cea49c
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
Test: python test_device.py
Change-Id: I0ed0044129b1671b2c5dd1b9fa2e70a9b4475dc5
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
Move the invocation of adb_notify_device_scan_complete to
the end of device_connected, where we decrement connecting_devices.
Also, create a dedicated thread for handling hotplug events, instead of
reusing the main thread for this, since the main thread blocks until
device scan is complete.
Test: `adb kill-server; adb devices`
Change-Id: Ia73b1a57538174282a48ef73ab0a3e58152d6f83
libusb hotplug callbacks are called with the libusb lock taken, and we
call into libusb with our local mutex, so we need to enforce an ordering
between the two. Instead of calling device_connected or
device_disconnected directly, enqueue them onto the main thread.
Bug: http://b/62200735
Test: manually hotplugged a device
Change-Id: Ic5d55db83b47f4bb60f124ce94ddfe06f5f1a0c6
A bug was introduced by commit 8bf37d7a wherein we accidentally only
look at the first interface of a device when checking whether a USB
device was an ADB device or not.
Bug: http://b/38201318
Test: none
Change-Id: I8e8e0963c77cd2cb03538d926ab735f4b57e52b7
Android's host linux libusb uses netlink instead of udev for device
hotplug notification, which means we can get hotplug notifications
before udev has updated ownership/perms on the device.
When detecting a new device, poll the device file for a while until we
can access it, before trying to open it.
Bug: http://b/38170349
Test: manually incrased timeout and chmodded a device betwen 0 and 664
Change-Id: I3c714f630940df02b407442592301e2bbb3d9653
Switch from polling in a loop to using libusb's hotplug API to detect
when devices arrive and leave. Use this to remove devices that were
inaccessible when they're unplugged.
Bug: http://b/38170349
Test: plugged in device
Change-Id: Id157412eb46834debecb0cd45b47b1ced50c2274
We want to explicitly define the order in which we teardown adb, so
move all of the at_quick_exits sprinkled throughout into one function
containing all of the cleanup functions.
Bug: http://b/37104408
Test: adb kill-server; adb start-server
Change-Id: I394f5782eb147e394d4b87df1ba364c061de4b90
Instead of sleeping for 500ms at the end of every device poll loop, use
a timed condition variable wait so that we can tell the device poll
thread to immediately commit suicide.
Bug: http://b/37869663
Test: adb kill-server; adb start-server
Change-Id: I597071866f7d9ef91900411727345d32c1a97556
The original code used continue to attempt to try to skip the current
device, but there was an loop between the outside one and the continue.
Move the device handling logic into a function and replace continue
with return.
Test: mma
Change-Id: Iaa7f4b5ddc26d2ce03f1172d37d6307190b44412
system/core/adb/client/usb_libusb.cpp:162:20: error: unused function 'get_device_serial_path' [-Werror,-Wunused-function]
static std::string get_device_serial_path(libusb_device* device) {
^
Bug: N/A
Test: no choice but to submit and see...
Change-Id: I0026d3273891588c27df5ccd71c41ad9907b038d
A couple of folks had trouble understanding the existing message.
Before:
8XV7N15917000596 no permissions (udev requires plugdev group membership); see [http://developer.android.com/tools/device.html]
After:
8XV7N15917000596 no permissions (user buttmunch is not in the plugdev group); see [http://developer.android.com/tools/device.html]
This also fixes a libusb regression where we wouldn't show anything for
devices where we don't have permissions.
Bug: http://b/37707122
Test: ran "adb devices" as user buttmunch
Change-Id: I2fcd735ff4178145432b532a6e4dc8c93b2743fd
Replace a hard-coded 3 second sleep with logic to wait until we've
scanned USB devices once and they've all come online.
Before:
adb shell true 0.00s user 0.00s system 0% cpu 3.047 total
After:
adb shell true 0.00s user 0.00s system 9% cpu 0.041 total
Bug: http://b/37869663
Test: `time adb shell true` after adb kill-server
Change-Id: I251d42afb885908ed9d03167287594ea16650d3f
Previously, adb was assuming a fixed maximum packet size of 1024 bytes
(the value for an endpoint connected via USB 3.0). When connected to an
endpoint that has an actual maximum packet size of 512 bytes (i.e.
every single device over USB 2.0), the following could occur:
device sends amessage with 512 byte payload
client reads amessage
client tries to read payload with a length of 1024
In this scenario, the kernel will block, waiting for an additional
packet which won't arrive until something else gets sent across the
wire, which will result in the previous read failing, and the new
packet being dropped.
Bug: http://b/37783561
Test: python test_device.py on linux/darwin, with native/libusb
Change-Id: I556f5344945e22dd1533b076f662a97eea24628e
When device goes offline, user usually has to manually replug the
usb device. This patch tries to solve two offline situations, all
because when adb on host is killed, the adbd on device is not notified.
1. When adb server is killed while pushing a large file to device,
the device is still reading the unfinished large message. So the
device thinks of the CNXN message as part of the previous unfinished
message, so it doesn't reply and the device is in offline state.
The solution is to add a write_msg_lock in atransport struct. And it
kicks the transport only after sending a whole message. By kicking
all transports before exit, we ensure that we don't write part of
a message to any device. So next time we start adb server, the device
should be waiting for a new message.
2. When adb server is killed while pulling a large file from device,
the device is still trying to send the unfinished large message. So
adb on host usually reads data with EOVERFLOW error. This is because
adb on host is reading less than one packet sent from device.
The solution is to use buffered read on host. The max packet size
of bulk transactions in USB 3.0 is 1024 bytes. By preparing an at least
1024 bytes buffer when reading, EOVERFLOW no longer occurs. And teach
adb host to ignore wrong messages.
To be safe, this patch doesn't change any logic on device.
Bug: http://b/32952319
Test: run python -m unittest -q test_device.DeviceOfflineTest
Test: on linux/mac/windows with bullhead, ryu.
Change-Id: Ib149d30028a62a6f03857b8a95ab5a1d6e9b9c4e
We have std::thread now, so we can delete this cruft.
Test: python test_device.py
Test: adb_test
Test: wine adb_test.exe
Test: /data/nativetest/adbd_test/adbd_test
Change-Id: Ie1c1792547b20dec45e2a62ce6515fcb981c3ef8
Calling libusb_reset_device() resets the usb connection with device
on linux platform. It can interfere with other usb interfaces and only
works on linux.
Removing it only affects when adb server is killed while doing IO with
device, which will be solved in later patches.
Bug: http://b/32952319
Test: none
Change-Id: I19522435eadd938ff95d49cbae3bcaa5c8f6d184
Test: Was able to discover a raspberry pi.
Bug: 28074466
(cherry picked from e292cd16760321fccc99c8c261cb92fa4b6462ab)
Change-Id: Id9571576457a4a0a078e48a274a4e8eac78bfe2b
Add a 'host-features' command to get the features of the currently
running host adb server. Abuse it to report libusb status.
Bug: http://b/34983123
Test: adb host-features; adb kill-server; ADB_LIBUSB=1 adb start-server; adb host-features
Change-Id: I0e8d503a2dbdff9002ebb6ce8a298498a9421422
The first time you run adb, it starts the adbd server and annoyingly
generates the following message:
adb I 02-01 11:57:58 99717 99717 usb_dispatch.cpp:30] using native
backend
Drop the severity of the message to avoid visible spammy messages only
intended for debugging.
Test: code compiles and no more log message in normal adb use
Change-Id: I882092a6cd14bc67980d88416397d51ab8393b1b
Add a libusb-based implementation alongside the existing native
implementations, controlled by the ADB_LIBUSB environment variable.
Windows will need more work for the usb driver.
Bug: http://b/31321337
Test: python test_device.py on linux/darwin, with ADB_LIBUSB=0 and 1
Change-Id: Ib68fb2c6c05475eae3ff4cc19f55802a6f489bb7
install_listener can fail if we told a previous adb server to quit and
it hasn't finished doing so yet. Retry it for a few hundred
milliseconds to avoid this.
Bug: http://b/28618716
Test: nc -l 5037; adb server nodaemon
Change-Id: Ibbda8f2718b85a2b6a08985aa8d29aa2204a3ead
Now that we have support for std::mutex and std::condition_variable on
Windows, remove our mutex compatibility layer in favor of the C++ one.
Bug: http://b/31653591
Test: mma && $ANDROID_HOST_OUT/nativetest64/adb_test/adb_test && \
python test_adb.py && python test_device.py
(also on Windows)
Change-Id: I5b7ed9c45cc2a32edcf4e77b56dc28e441f15f34
If the calling process has already been a leading process of session.
setsid just fail with EPERM, ignore such error.
Test: killall adb;exec 3>f;adb fork-server server --reply-fd 3 & cat f
Change-Id: I1aeac079f29e10aa63ed724b5a43663f25c25ad5
Signed-off-by: Tao Wu <lepton@google.com>
