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
- moved __android_log_is_debuggable to a new public header
(log_properties.h)
- vendor version of sched_policy uses ALOG* instead SLOG*
Test: (sanity) liblog-unit-tests
Test: (sanity) libcutils_test (noting b/b/32972117, two tests continue
to fail)
Test: system/core as a whole makes with BOARD_VNDK_VERSION := current
now with no problems.
Test: boots/works on internal marlin
Bug: 33241851
(cherry picked from commit 1f83aa424f)
Merged-In: I5bc1f348dc0f0c8814bec5b5c3d2c52c825ab640
Change-Id: I5bc1f348dc0f0c8814bec5b5c3d2c52c825ab640
- moved __android_log_is_debuggable to a new public header
(log_properties.h)
- vendor version of sched_policy uses ALOG* instead SLOG*
Test: (sanity) liblog-unit-tests
Test: (sanity) libcutils_test (noting b/b/32972117, two tests continue
to fail)
Test: system/core as a whole makes with BOARD_VNDK_VERSION := current
now with no problems.
Test: boots/works on internal marlin
Bug: 33241851
Change-Id: I5bc1f348dc0f0c8814bec5b5c3d2c52c825ab640
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
Misconfigured systems can have localhost pointing to an address that
isn't 127.0.0.1 or ::1.
adb is the only caller of the libcutils socket_loopback functions, so
move them into adb and switch the implementations over to using
INADDR_LOOPBACK and in6addr_loopback, instead of resolving 'localhost'
when connecting.
Bug: http://b/37282612
Test: `killall adb; adb shell`
Test: `killall adb; ip addr del 127.0.0.1/8 dev lo; adb shell`
Change-Id: I01c1885f1d9757ad0f7b353dd04b4d1f057741c8
Key/value support for adb backup was added in ag/1946677, and help text
for adb shell bu is added in ag/2088937. This CL points the user to this
helptext instead of keeping it here, since it can quickly get out of
sync.
BUG=36170696
Test: adb
Change-Id: Ic40679f421a32e60f292ad20b726a89bfff03349
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
