Support `adb rescue wipe` command on the host side. This command runs
under the rescue mode and wipes data (and cache/metadata).
Bug: 131037235
Test: run adb rescue wipe
Change-Id: Ib3a3f2d564cc19d0446540d616cc21489ba558c2
(cherry picked from commit c2265c5343)
This CL adds client support to recognize the rescue mode (which will be
served by recovery image). It also allows waiting for a device to enter
rescue mode. The support for the actual rescue commands will be added in
follow-up CLs.
Bug: 128415917
Test: `adb devices` recognizes devices under rescue mode.
Test: `adb wait-for-rescue` waits for device to be in rescue mode.
Change-Id: I367d7339fe68006aba09a1e3db6370d472296676
Merged-In: I367d7339fe68006aba09a1e3db6370d472296676
(cherry picked from commit 55d407ec4a)
Some USB controllers only support 16k writes, so drop down to that.
Bug: http://b/130622010
Test: treehugger
Change-Id: I836d5b2d0d6fcae05f290af11a6a19c6e8d7c1ba
(cherry picked from commit 770a6a4d46)
As raw protocol does not allow for splitting err - it has to be redirected to inout.
Before this change it was not done for in-process and all err data was lost.
Bug: 130086616
Test: manual + atest adbd_test
Change-Id: I6cd11c940673d73e2993a6eb23c46d31bd8bf504
(cherry picked from commit 704c97d6c2)
It seems like we don't actually always get these events in order, so
demote them to a log and restart the connection instead of aborting.
Bug: http://b/129464137
Test: mma
Change-Id: I7dffbf62f9dea665cf9f9f9e1bd18d444b6905ec
Occasionally, after we open the functionfs endpoint and write our
descriptors to it, we end up in a state where we never receive any
events from ep0, presumably due to a race against some other part of
the system, since adding sleeps reduces the likelihood. Add an
(arbitrarily chosen) timeout for the initial FUNCTIONFS_BIND we read,
and retry on failure.
Bug: http://b/128679787
Test: unplug and replug a blueline 14,000 times with a usb switch board
Change-Id: I4b3d5d552179ee7f3fefcc15f9575f793926f784
Monitor for FUNCTIONFS_UNBIND as well, so that in the case where we get
FUNCTIONFS_BIND, FUNCTIONFS_UNBIND, FUNCTIONFS_BIND, we don't trigger an
assertion failure from seeing two FUNCTIONFS_BINDs.
Bug: http://b/129134256
Test: manual
Change-Id: I80af5f4b833513e932262638b9f8d76bbcb35504
If we fail to submit writes for some reason (e.g. the USB cable was
unplugged), another thread that's waiting on the write mutex can enter
SubmitWrites and attempt to resubmit the writes that we already failed
to submit, leading to a failed assertion of !IoBlock::pending.
Increment writes_submitted_ before actually calling io_submit, so we
skip over these writes and fall through to exit.
Bug: http://b/129134256
Test: manually unplugged a blueline
Change-Id: I2fd0034e45db22c8f637c81039ce686b7aa6a03b
When a function argument takes a std::string, it's inefficient to
pass std::string::c_str(), since that creates an additional copy.
So we change these calling sites.
Test: TreeHugger
Change-Id: I1c0fde7275eb3ebd3baf05ec62581b0243655608
Allow disabling ro.adb.nonblocking_ffs via an ro system property, which
gets overridden by the currently supported persist.adb.nonblocking_ffs.
Bug: http://b/128679787
Test: mma
Change-Id: I28891d2da129e9654bf63ab8a4c330c4d2f5b336
Previously, we were initializing IoBlock::pending when submitting a read,
but leaving it uninitialized when doing a write, which would sometimes
result in an assertion firing when we received a previously allocated
block of memory that happened to have a nonzero value in pending.
Test: treehugger
Change-Id: I434c65f554ceed313fea9cfcc98788908f3ca8bc
When we introduced __adb_check_server_version() as a function
returning a 'bool', we missed missed converting once instance
of "return -1;" to "return false;". Thus, we're returning 'true'
in this case as our non-zero value gets implicitly converted to
'true'.
We fix this case as well with this CL.
Test: TreeHugger
Change-Id: I90b01567d927f36d2d963561b676b3bfabfcee49
Windows has int32_t return codes, which results in return codes 128-255
being sign extended into a negative number. Manually truncate the return
codes we get to preserve their values.
Test: test_device.py on windows
Change-Id: If41d6d469350301704f6ecff72ad17b412db3e04
As there is no security guarantee when the device is unlocked,
allowing adb root gives us more rooms to debug a USER build images.
Also, this makes it possible to run VTS on a USER build GSI, with
setting ro.debuggable=1 and unlocking the device.
This basically re-lands a reverted change:
https://android-review.googlesource.com/c/platform/system/core/+/437815
Which isn't needed after we moved /sbin/adbd to /system/bin/adbd in
USERDEBUG GSI. But it's still needed for USER build GSI.
Bug: 126493225
Test: unlock a USER build device, check 'adb root' can work
Change-Id: I93f12c8a3fe65c96c947e4602795eadfe591c521
If a device is unplugged, a BIND will happen without an ENABLE until the
device is plugged in, which would previously result in adbd crashing
every 5 seconds due to an attempt to join a thread that hadn't been
started.
Bug: http://b/128255355
Test: manually observed adbd via serial cable while unplugged
Change-Id: I90d6384e7e829df1ffaf73a95f2418a2ff97fb03
Our servers can comfortably run more than 16 emulators, and this is
much easier than messing with hypervisors or docker port allocation.
Assumes you know how to avoid clashes with Google Wear's default port.
Test: manual - still registers emulators.
Change-Id: I47cfd28725a550de0bd77fd11fcd94cdd11d2cc2
