We want repeatable builds for minimal OTAs.
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
ALLOW_ADBD_ROOT ('adb root') and ALLOW_ADBD_NO_AUTH (ro.adb.secure = 0)
are false in user build. This prevents a non-A/B device from running
Treble VTS because it requires 'adb root'. Without ALLOW_ADBD_NO_AUTH,
adb still can work if ro.adb.secure = 1. However, allowing it to be 0
is better for test automation.
The image combination in VTS is:
- system.img (userdebug): provided by Googlg
- boot.img (user): provided by the OEM <-- adbd is here
- vendor.img (user): provided by the OEM
This change allows 'adb root' and 'ro.adb.secure = 0' when the device is
unlocked in user build. No changes for userdebug/eng builds.
Note that the device must be unlocked when running VTS. Otherwise,
verified boot will prevent it from booting the system.img provided by
Google (no verity metadata).
Bug: 63313955
Bug: 63381692
Test: use the above image combination, check 'adb root' and
'ro.adb.secure = 0' can work
Change-Id: I109d96c950e54c4fb0ac0c98b989a20593681e52
This reverts commit f2f0b31850.
libusb seems to be causing flakiness on some machines. Disable it for
now.
Bug: http://b/62962248
Test: python test_device.py (with DeviceOfflineTest commented out)
Change-Id: Ia9de78ab772c22574cf5ca7facb78f22af6d7a71
(cherry picked from commit 969110ca4a)
This reverts commit f2f0b31850.
libusb seems to be causing flakiness on some machines. Disable it for
now.
Bug: http://b/62962248
Test: python test_device.py (with DeviceOfflineTest commented out)
Change-Id: Ia9de78ab772c22574cf5ca7facb78f22af6d7a71
Relax the shell command length limits when talking to an adbd with the
shell protocol.
shell is pretty much the only service that takes an arbitrarily long
string, so this is somewhat safe.
Bug: http://b/37716055
Test: `adb shell $(python -c 'print "echo " + "f" * (32*1024)') | wc` on L and master
Merged-In: I0737fd2244530ef8080f300cd3a3549a1ab93465
Change-Id: I0737fd2244530ef8080f300cd3a3549a1ab93465
Fix a deadlock that happened when a reader/writer thread released a
transport while the hotplug thread attempted to handle a device
disconnection. Decrementing a transport refcount to zero would hold the
global transport mutex and attempt to take the usb handles mutex, while
the hotplug thread would hold the usb handles mutex and try to call
unregister_usb_transport, which would attempt to take the global
transport mutex.
Resolve this by making transport_unref not take the global transport
mutex.
Bug: http://b/62423753
Test: python test_device.py
Merged-In: Ib48b80a2091a254527f3a7d945b6a11fae61f937
Change-Id: Ib48b80a2091a254527f3a7d945b6a11fae61f937
(cherry picked from commit 7e197ef833)
Relax the shell command length limits when talking to an adbd with the
shell protocol.
shell is pretty much the only service that takes an arbitrarily long
string, so this is somewhat safe.
Bug: http://b/37716055
Test: `adb shell $(python -c 'print "echo " + "f" * (32*1024)') | wc` on L and master
Change-Id: I0737fd2244530ef8080f300cd3a3549a1ab93465
adbd currently decides to use the QEMUD pipe if ro.kernel.qemu=1, as set
for ranchu. The Android container in Chrome OS doesn't have that
property set and it can't be set to 1 because it's used as equivalent to
"runs inside an emulator" throughout Android and changes the way
graphics are handled, whether Bluetooth is supported, etc., behaviour
that we do not want to trigger in Chrome OS.
adbd now also checks service.adb.transport to decide whether to use the
QEMUD (goldfish) pipe.
adbd still first checks for ro.kernel.qemu to preserve existing
behaviour and will still fallback to TCP if it can't use Goldfish.
Bug: 38497992
Test: tested by jmgao@ -thanks!- on aosp_angler, adb still works.
Change-Id: I8370704145ae7301ac7aeef81c5cbd94cfcb7fd7
Fix a deadlock that happened when a reader/writer thread released a
transport while the hotplug thread attempted to handle a device
disconnection. Decrementing a transport refcount to zero would hold the
global transport mutex and attempt to take the usb handles mutex, while
the hotplug thread would hold the usb handles mutex and try to call
unregister_usb_transport, which would attempt to take the global
transport mutex.
Resolve this by making transport_unref not take the global transport
mutex.
Bug: http://b/62423753
Test: python test_device.py
Change-Id: Ib48b80a2091a254527f3a7d945b6a11fae61f937
For unclear reasons, it seems that for some people, devices are
becoming accessible, inaccessible, and then inaccessible again.
Switch to a sleep for now.
Bug: http://b/62200735
Test: manual
Merged-In: Id51dcb188c3534a57c35cbfd30a181c99115a23c
Change-Id: Id51dcb188c3534a57c35cbfd30a181c99115a23c
(cherry picked from commit 5b8b10e078)
If a device is unplugged while it's being processed, we can be inside
register_usb_transport still when we call unregister_usb_transport,
leading to bad things happening. Move the call of
register_usb_transport into the scope guarded by usb_handles_mutex.
Bug: http://b/62200735
Test: manual
Merged-In: I2517dcb9d30d9a08cebbb5f715ae3fd30c510109
Change-Id: I2517dcb9d30d9a08cebbb5f715ae3fd30c510109
(cherry picked from commit 7dd382ded9)
For unclear reasons, it seems that for some people, devices are
becoming accessible, inaccessible, and then inaccessible again.
Switch to a sleep for now.
Bug: http://b/62200735
Test: manual
Change-Id: Id51dcb188c3534a57c35cbfd30a181c99115a23c
If a device is unplugged while it's being processed, we can be inside
register_usb_transport still when we call unregister_usb_transport,
leading to bad things happening. Move the call of
register_usb_transport into the scope guarded by usb_handles_mutex.
Bug: http://b/62200735
Test: manual
Change-Id: I2517dcb9d30d9a08cebbb5f715ae3fd30c510109
Previously, we would attempt to delete a usb_handle in both
device_disconnected and usb_close. If the one in device_disconnected
happened to happen first, usb_close would abort when it failed to find
the handle it was supposed to own.
Bug: http://b/62020217
Test: unplugging device on darwin
Change-Id: I6c6bf61bf89a4d9a23458c00b457080d3d6cc744
Version 2 of the framebuffer protocol in adb can now be used to read
the color space information of the screenshot: unknown (native),
sRGB or Display P3.
Bug: 29940137
Test: Manual
Change-Id: I037da58e1c4f6e9e874d72348140c067640c6931
Move the invocation of adb_notify_device_scan_complete to
the end of device_connected, where we decrement connecting_devices.
Also, create a dedicated thread for handling hotplug events, instead of
reusing the main thread for this, since the main thread blocks until
device scan is complete.
Test: `adb kill-server; adb devices`
Change-Id: Ia73b1a57538174282a48ef73ab0a3e58152d6f83
libusb hotplug callbacks are called with the libusb lock taken, and we
call into libusb with our local mutex, so we need to enforce an ordering
between the two. Instead of calling device_connected or
device_disconnected directly, enqueue them onto the main thread.
Bug: http://b/62200735
Test: manually hotplugged a device
Change-Id: Ic5d55db83b47f4bb60f124ce94ddfe06f5f1a0c6
Otherwise, it might take seconds to display the initial percentage,
and the user might thing something is wrong and CTRL-C the process.
Fixes: 62003852
Test: added BugreportTest.OkProgressZeroPercentIsNotIgnored
Test: m -j32 adb_test && ./out/host/linux-x86/nativetest64/adb_test/adb_test --gtest_filter=BugreportTest.*
Change-Id: I8e7dbb28666c825c1408d5d204f813064fc3048f
Elliott Hughes