We should have done this from the beginning. Thanks to Windows, we're not
going to be able to switch libbase over to std::string_view any time soon.
Bug: N/A
Test: ran tests
Change-Id: Iff2f56986e39de53f3ac484415378af17dacf26b
The checksum is unnecessary. Improves adb performance by 40% on USB2.
Test: new adb works with new + old adbd, old adb works with new adbd
bug 67327728
Change-Id: I761d8a5a62deaea9bbb092ea9926b2d6d312f00d
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
In https://github.com/torvalds/linux/commit/8db6c34f1dbc8 , namespaced
file capabilities were introduced. That change updated VFS_CAP_REVISION
from VFS_CAP_REVISION_2 to VFS_CAP_REVISION_3.
Android code is written assuming v2 capabilities, and the code will
break if we naively try to treat a v2 structure as a v3 structure.
So don't even try.
Android kernels prior to v4.14 will not support this extended capability
structure, so attempting to set such capabilities will ultimately fail.
With 8db6c34f1dbc8, it appears that attempting to read a v3 capabilities
xattr will always downgrade the capability to a v2 capability, so it
really doesn't make sense to look for a v3 capability.
Android capabilities are only created at /system and /vendor filesystem
creation time by host tools. Android processes, within or outside a
namespace, are not permitted CAP_SETFCAP
(https://android-review.googlesource.com/c/platform/system/sepolicy/+/547801/1/public/domain.te
line 1101). So we should never have to deal with a v3 capability other
than those that might appear on the /system / /vendor partition at a
future date by a future author.
Bug: 69617725
Test: build/test/boot/CTS passes
Change-Id: I0378b3f1195dc62dbeb771944ab378c881441118
This test actually belongs with the adb python wrapper, since it's not
affected by changes to adb itself.
Bug: http://b/64260633
Test: python test_device.py
Change-Id: I58e5dff760f35923f8dbbdc7de6ffd75254880dc
We want repeatable builds for minimal OTAs.
(cherrypick of 2e93eda69cf20d9c04d56ea6bf1e2ea62ad62eb4.)
Bug: http://b/64634017
Bug: 64709603 (presubmit balking at the line above)
Test: repeated builds after `touch daemon/main.cpp` keep same md5sum
Change-Id: Iedeb44377ea45bbf20e2212760802198a57dc14a
This probably doesn't have any actual effect, because there should only
be one smartsocket listener so this will happen to work, but this looks
sketchy.
Test: mma
Test: adb server nodaemon & (sleep 1; adb kill-server)
Change-Id: Id00ab1fc1fc029949c675ae6e3b1a77f3e9e4c69
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
bash sets this itself, but mksh doesn't.
This also makes interactive and non-interactive adb shells more similar,
because when we set this in mkshrc that wouldn't affect non-interactive
shells. (I'm not sure whether this is an improvement or not.)
This is certainly _cheaper_ than doing this in mkshrc by calling out to
getprop though.
Bug: N/A
Test: `adb shell printenv` and `adb shell`, `printenv`
Change-Id: I3ff724f19a5098313df83836253f1f7e7872d6a4
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
Name each service thread specifically to improve debuggability.
Bug: http://b/65648324
Test: adb shell debuggerd -b `adb shell pidof adbd` during a sync
Change-Id: I644e25fc2f14a26eafd19f596e4e8f3c2bb79967
Revert the write_msg_lock part of commit b5e11415. A write which hangs
will hold onto the mutex, preventing the device kick from ever
happening, which also causes lots of other stuff to hang, due to Kick
being called with the transport lock taken.
Test: python test_devices.py
Change-Id: Ie7c958799c93cad287c32d6bbef30c07f40c2d51
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
The comment that was previously here says that local_socket_list_lock
must be taken, but this function is exposed to external callers that
can't possibly take the lock.
Bug: http://b/65419665
Test: python test_device.py
Change-Id: I12d464933936b2a210a827ccf19ea201020d8d78
For reboot [reboot_arg] requests via either reboot or adb reboot,
if reboot_arg is empty then report "shell" or "adb" respectively.
Test: boot_reason_test.sh shell_reboot adb_reboot
Bug: 63736262
Change-Id: Ie613d9e62db6a705885e4e7520aede27af3aa1b9