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
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
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
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
