Annoyingly folks parse the "adb --version" output so we have the
less-interesting protocol version first. But at least now we'll
have the "real" version somewhere...
Bug: N/A
Test: "adb --version"/"fastboot --version"
Change-Id: Ia85b561bd8d84c6fd6995923730d36f53b2f800b
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
This will let us see (a) whether the user has a legit build or something they
built themselves and (b) what Android release it corresponds to.
This isn't as useful as showing what Platform Tools release we correspond to,
but I'm planning on doing that as a separate line.
Bug: N/A
Test: adb --version ; fastboot --version
Change-Id: Idca489295e3c6f8571146f95822c08808e36b382
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
Use fdevent_run_on_main_thread to initialize mDNS in a thread and
register an fdevent from the main thread upon success.
This reduces the startup time of `adb server` by ~3 seconds when mDNS
can't be successfully started. With an already running adb server,
`time adb server nodaemon` goes from:
adb server nodaemon 0.00s user 0.16s system 4% cpu 3.817 total
to:
adb server nodaemon 0.00s user 0.01s system 1% cpu 0.665 total
Bug: http://b/37869663
Test: `adb server nodaemon` with an existing adb server
Change-Id: Ia5a1a2a138610f3bf6792400050ca68f95ae3734
Add a function to run a function on the main thread, to allow fdevents
that depend on a blocking function to be registered.
Bug: http://b/37869663
Test: adb_test on linux
Change-Id: I84a0b372360420b7647057297b8f437e8afa874e
Delete the sysdeps/mutex tests that -Wthread-safety complains about.
We're using the standard library's std::mutex on all platforms now,
anyway.
Test: mma
Change-Id: I3bf958c72604b29dfb1d9c898d3c9aa34aed2685
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
Rather than quietly fall through to the legacy code with no explanation,
say why the first connection failed, and that the second attempt is only
going to be relevant for folks trying to sideload to a pre-KitKit device.
Before:
$ adb sideload mysid-ota-424425.zip
opening 'mysid-ota-424425.zip'...
connecting...
falling back to older sideload method...
error: closed
After:
$ adb sideload mysid-ota-424425.zip
adb: sideload connection failed: no devices/emulators found
adb: trying pre-KitKat sideload method...
adb: pre-KitKat sideload connection failed: no devices/emulators found
Also switch the legacy code to just read+write blocks rather than trying to
load the whole OTA package into RAM (which is in short supply on Win32).
This is probably of no practical use other than that it lets us report a
better error message (better than "terminate called after throwing an
instance of 'std::bad_alloc'").
Bug: https://issuetracker.google.com/37139736
Test: "adb sideload" with no device/a mysid/an angler
Change-Id: Ia568044aac61bd054301ebfd7fcd5ad5d6f3147a
The previous fix was taking account just the progress reported by dumpstate,
not progress/percentage. As such, it was not detecting the cases where the
percentage decreased but the progress didn't.
Bug: 37878670
Test: m -j32 adb_test && ./out/host/linux-x86/nativetest64/adb_test/adb_test --gtest_filter=BugreportTest.*
Change-Id: I5830028f3191a9b17f63aeed5c049b29fa7d1179
Link with libavb_user and use this to enable/disable dm-verity if AVB
is in use.
Bug: 34124301
Test: Manually tested.
Change-Id: Ic03651312b955081cb3c126f6dafc46d6eeec0da
In N we moved some code from C to C++ without realizing that EVP_EncodedLength
includes space for a terminating NUL and EVP_EncodeBlock writes one. Because
our key reading code copes with the NUL, we never noticed.
Distinguish between the required space returned by EVP_EncodedLength and the
actual number of bytes (not including NUL) used return by EVP_EncodeBlock.
Bug: http://b/36187819
Test: hexdump of ~/.android/adbkey.pub
Change-Id: I81a487ddbb5c884593b6426d1f41cfaece26ff90
Remove -p (which only applied to "adb sync"), explicitly mention
$ANDROID_PRODUCT_OUT in the "adb sync" help text, and add "adb sync all"
as a synonym for "adb sync" for ease of documentation.
Bug: http://b/33761074
Test: "adb sync" still works, "adb --help" looks good
Change-Id: Ie5b2459a7e5e4140298f78815be25fa7c7bb47d0
This reverts commit 05fe272a87.
Commit "adb: Do not signal gaget stack unless descriptors are written"
fixed the main issue for configfs devices where device wasn't enabled
until after the ioctl was attempted. Thus it is safe to bring up the
retry count so that the ioctl doesn't fail due to small delays in
usb stack.
Test: use adb, switch configs on configfs devices
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
`adb install` was writing success to stderr rather than stdout.
Server mismatch messages were going to stdout rather than stderr.
Error messages should consistently start with a lower case letter.
Also improve consistency of syntax error reporting.
Bug: https://issuetracker.google.com/37128706 (adb install success to stdout)
Bug: https://issuetracker.google.com/37140458 (server mismatch on stderr)
Bug: http://b/32413861 (consistency)
Test: ran tests
Change-Id: I0d6cb0c7482bec03483dacefd996644b7a28d273
