This will make it easier to add new types of transports by combining the
logic the adb server and adb daemon use to connect to things.
Bug:121166534
Test: adb connect against a cuttlefish instance over the shm proxy.
Change-Id: Ic7fc848c60a85eef968c3735838c87cb7fdaf38b
This CL introduces two changes to adb install-multi-package:
- If there is at least one apex package in the list of packages, use the
--staged parameter for both the parent and the child sessions
- When the package being sent is an apex, use the --apex parameter
Bug: 118865310
Test: Printed out the resulting commands and verified that both
non-staged and staged workflow are accepted by PackageManager. Tried
scheduling install sessions for a mix of APK/APEX, only APKs, only APEX.
Change-Id: I8d1a6a7c5408fb95c10d79e38ddaf115a46f5d8b
This change adds an install-atomic command to adb that is shorthand for
creating an atomic install session and an individual session for each
APK supplied to the command.
Bug: 109941548
Test: run command with multiple APKs, observe atomic install
Change-Id: I2817a1ed2d312925d9c7bd621e6c82670a6275fd
Once launched, abb will listen for incoming Binder cli requests.
Executing in-process provides 6x latency improvement (125ms vs 25ms on
PixelXL) for commands like 'package path'
Intended usage by Android Studio for fast deployment and patching of APKs.
Test: manual
BUG: 111621042
Change-Id: Ica84eb2ec9628efa441ecd627b119f3361feaf9f
Before overlayfs, we supported deduplicated filesystems by undoing
deduplication in recovery. This required an extra reboot cycle, so we
changed "adb remount" to disable verity and boot to recovery in one
command.
After overlayfs, adb remount is still trying to undo deduplication,
which leads to very confusing messages. This patch makes things a bit
clearer. "adb remount" will disable verity, which installs overlayfs.
"adb remount -R" will do the same except automatically reboot.
Bug: N/A
Test: adb remount on dynamic partitions device
Change-Id: Id72f6b9e2297c2f4d5722d5679f6264fe660e631
--fastdeploy does not require -r anymore, and reverts to a normal install
if the application is not already on the device.
Bug: 120828611
Test: mm -j72
Test: adb install --fastdeploy --force-agent --local-agent /mnt/raid/boat-attack-apk/boat-attack-swappy.apk
Change-Id: Ice2a71493a34ee7d0debabcce6a9aebb0af79e62
Certain error conditions were getting lost because adb was wrongly
reading DeployAgent's return code as always 0.
Test: mm -j 72
Test: adb install -r --fastdeploy --force-agent --local-agent /mnt/raid/boat-attack-apk/boat-attack-swappy.apk
Bug: 120197330
Change-Id: If835fd6ca2051be8e5ff6c957e08b1e458053989
An adbkey/adbkey.pub pair that doesn't match up results in a
hard-to-diagnose scenario where "Always allow from this computer"
doesn't work. The private key contains all of the information that's
in the public key, so just extract the public key out of the private
key instead of storing them separately.
Bug: http://b/119634232
Test: rm ~/.android/adbkey.pub; adb kill-server; adb shell true
Test: rm ~/.android/adbkey*; adb kill-server; adb shell true
Change-Id: I0ae9033dbcd119c12cfb2b3977f1f1954ac800c1
It's possible to build against an SDK that's newer than the OS that
we're actually running via Xcode update, and Apple increments the
unversioned IOKit interface IDs to the newest version on every release,
which leads to mysterious failures to acquire an interface.
Pin the interface versions to IOUSBFamily 5.0.0, which shipped on OS X
10.7.3.
Bug: http://b/119264733
Test: ./test_device.py
Change-Id: Id26760bc62c89a1f7ef67511b21f9d9252ab69f3
This should fix the bloody Mac build, which doesn't have <error.h>. Since
we weren't entirely happy with error(3) anyway, switch to the toybox
style of error_exit and perror_exit, which are slightly briefer and quite
a bit more intention-revealing.
Bug: N/A
Test: builds
Change-Id: Ic8e411906c363af51657da5ce947b25a0b6bb1f3
Let's use LOG(FATAL)/PLOG(FATAL) for actual fatal stuff.
Add a Windows error(3) and move folks who didn't really mean "abort"
fatal over to it. Also get rid of syntax_error which wasn't adding a
lot of value, and most of the places it was adding "usage: " didn't seem
entirely appropriate anyway.
In particular, we seemed to have confused fastdeploy.cpp into aborting
in most user error cases, and none of the reviewers noticed. Clearly
we'd all lost track of far too many options.
(I've also cleaned up a few random instances of fprintf(3) + exit(2).)
Bug: N/A
Test: manual
Change-Id: I3e8440848a24e30d928de9eded505916bc324786
Removed call to external aapt2 process
Replaced several layers of error handling with calls to fatal()
Changed output messages for failures to be more useful for diagnostics
Bug: 116753196
Test: mm
Test: adb install -r --fastdeploy --force-agent --local-agent ~/example_apks/example.apk
Test: adb install -r --fastdeploy --no-streaming --force-agent --local-agent ~/example_apks/example.apk
Change-Id: I6006d8aa584e789a086a31e79a41d1416e54402a
Also stop using size_t (which will be 32-bit on Win32) for offsets in
adb_sideload_host, and stop truncating large file sizes in our
"sideload-host" messages.
Bug: http://b/112003354
Test: builds
Change-Id: If5b7cc9d1fc7ff7ca6eaebd20418f7b061846203
Bug: http://b/91353691
- libcxx has ETXTBSY for Windows
- adb/sysdeps/memory.h is no longer needed
Test: Build and test Windows binaries under Wine.
Change-Id: I9c27087d46c49cb25b391c4adae8d9e24724784d
Removed support for -f shortcut flag as this conflicts with some package manager flags
Renamed use_localagent global to match conventions
Fixed case where tmp files were created unnecessarily
Removed dead code (delete_host_file)
Cleaned up multiple layers of error handling by using fatal() as soon as error conditions occur
Fix: 113631900
Test: mm
Test: adb install -r --fastdeploy --nostreaming --force-agent --local-agent ~/example_apks/example.apk
Test: adb install -r --fastdeploy --no-streaming --force-agent --local-agent ~/example_apks/example.apk
Test: observe that fast deploy works as usual
Test: adb install -r -f --nostreaming --force-agent --local-agent ~/example_apks/example.apk
Test: adb install -r -f --no-streaming --force-agent --local-agent ~/example_apks/example.apk
Test: observe that fast deploy is no longer invoked by -f
Change-Id: Ic719df1003ac319e48b32f7f377f6f91d17f6a6f
(cherry picked from commit 0584689beaff604ceeccaf706dc368213d07b977)
deploypatchgenerator is now a dependency of adb
deployagent is now a java_binary target and uses the built in 'wrapper' parameter to bundle deployagent.sh
fastdeploy.cpp code in adb modified to reference deployagent rather than deployagent.sh (required to work with built in wrapper functionality).
removed near-redundant fastdeploy_init and TFastDeployConfig singleton as per:
https://android-review.googlesource.com/c/platform/system/core/+/740521/12/adb/client/fastdeploy.cpp#36
relocated kFastDeployMinApi to more appropriate location
Test: rm -rf $ANDROID_ROOT/out
Test: make sdk -j40
Test: find out/ -iname deploypatchgenerator
Test: observe that deploypatchgenerator.jar has been built as a dependency of the sdk target
Test: mm
Test: adb install -r -f --force-agent --local-agent ~/example_apks/example.apk
Test: adb install -r -f --no-streaming --force-agent --local-agent ~/example_apks/example.apk
Change-Id: I4e52d32f87774b44845bf6b5be0bae331a0b2324
It doesn't seem like b3c14ec693 was really
waiting for adb server death because the server would write OKAY to the
socket, causing the client to return from ReadOrderlyShutdown() before
the socket was actually closed.
The fix is to read the OKAY and then call ReadOrderlyShutdown() which
will then wait for the socket to be closed.
Test: Made the server hang in adb_server_cleanup() during kill-server
and kill-server would hang (as desired).
Test: To test resilience, tried preventing the server from sending OKAY and
adb kill-server still worked properly.
Change-Id: I4f0f11b86bbdc983670273ef5d3bb1dff7ab3697
Signed-off-by: Spencer Low <CompareAndSwap@gmail.com>
On Windows, when running adb server nodaemon and pressing Ctrl-C,
adb_server_cleanup (an atexit handler) would call kick_all_transports()
which would eventually fail a CHECK because the current thread was not
equal to the main thread. This is because Ctrl-C is implemented in
Windows by the OS creating a new thread in the process and calling the
Ctrl-C handler from there.
The CHECK fail would print out the CHECK expression and call abort()
which would record a crash in the Windows Event Log, plus would
potentially upload a crashdump to Microsoft's Watson service.
This might be a regression from d51c6df1ef.
The fix is to share more code between platforms, removing the call to
Win32 SetConsoleCtrlHandler() and just use the C Runtime's signal()
implementation which is built upon SetConsoleCtrlHandler(). The signal
handler still ends up being called from another thread, but the handler
is thread-safe enough so this seems to work.
Test: On Win10 and Vista, run adb server nodaemon and then try Ctrl-C,
Ctrl-Break and close console window.
Change-Id: I6603970616098d2b3ce68f2a3d4e5515ec859811
Signed-off-by: Spencer Low <CompareAndSwap@gmail.com>
