This improves performance when syncing by up to 2x (remote cuttlefish
goes from 11.9 MB/s to 21.3 MB/s, blueline over USB 2.0 from 36 MB/s
to 70 MB/s).
This results in a slight drop in push speeds over USB 3.0 (125 -> 115
MB/s on blueline), presumably because we're compressing and extracting
on only a single thread, but the gains over lower bandwidth transports
make this worth it to submit this now and parallelize later.
Bug: https://issuetracker.google.com/150827486
Test: ADB_COMPRESSION={0, 1} test_device.py (with new/old adbd)
Change-Id: Ic2a0c974f1b6efecda115f87d336e3caac810035
Merged-In: Ic2a0c974f1b6efecda115f87d336e3caac810035
(cherry picked from commit 939fc19aee)
This fixes the tls connection failure on Windows.
Bug: 150719467
Test: 'adb pair', 'adb connect' on Windows host machine.
Test: atest adb_tls_connection_test
Change-Id: I54b8945543ad8b430510fa51dd7bea64a119454f
adbd's file sync service doesn't handle a full socket gracefully,
immediately terminating the service as soon as it fails to write a
response. This would generally be fine if the socket's buffer were as
large as it claims (212992 by default with a 64-bit kernel), but this
buffer size is a giant lie, as each write has 576 bytes of overhead
that's used up in the send buffer. When setting the send buffer size,
the kernel helpfully doubles the value to attempt to account for the
overhead, but when writing 8 byte responses, only 2% of the buffer
actually gets used for responses, so we run out of buffer after 364
files instead of the 26624 that would be expected.
Fix this by processing the responses as they become available, and
calculate a maximum limit to how many sends we dispatch before we stop
and wait for responses to come in.
Bug: http://b/150827486
Test: manually modified adbd to respond with giant error messages, and
modified adb to not read responses until we choose to block
Change-Id: Ieb8c935662864211e2fd16c337ffed0992990086
(cherry picked from commit 672cdfeeff)
Print not more often than once a 100ms - it is smooth enough
and speeds up transfer even more on Windows, where a single
line output may take up to 5ms.
An added benefit is getting rid of some extra heap allocation
and string formatting when in the end the identical message
filtering would've dropped the line anyway. This is also
significantly more expensive on Windows.
Bug: 151900478
Test: manual, push/pull a file and a directory
Change-Id: I9038729e8a01d5f93fd301beaeb8a086f5039b77
Windows console IO is terribly slow. Reducing the number of
printed progress messages speeds up the transfer rate
from 80 to 130 MB/s on Windows laptop
Bug: 151900478
Test: adb push/pull
Change-Id: I223284c8a662bd8f2b8ba280cdcc8c930d3e5205
Use only the syscalls that work with the wrapped ADB fds, or
extract the native handles for the case when need to call one
not wrapped.
Bug: 151239696
Test: adb install --incremental <apk> on Windows
Change-Id: Ia6de620171ab696b8136dcb60a2b63af6f86419f
servingComplete_ was left uninitialized and only set to 'true'
in the code. We initialize it to the 'false' state to avoid
uninitialized references in SkipToRequest().
Bug: 150865433
Test: TreeHugger
Change-Id: Ia8a4d7135c432eb657543c5498fc9dbe8f4718b6
Before this change, "Success" is returned after all data is streamed,
around 7.5 seconds for Megacity.
After this change, "Success" is returned in about 1.5 seconds, before
streaming finishes.
BUG: 151676293
Test: manual
Change-Id: Ifda7de48da8e82623c99ae0194f70cb162fd72fa
Currently the server often quits before installation finishes. As a
result, there is no difference in the commandline output between a
successful installation and a failed one.
Let adb client wait till installation fails or succeeds by parsing the
output from the inc-server process.
Test: $ adb install --incremental ~/Downloads/base.apk
Test: Performing Incremental Install
Test: Serving...
Test: All files should be loaded. Notifying the device.
Test: Failure [INSTALL_PARSE_FAILED_NOT_APK: Failed to parse /data/app/vmdl749343150.tmp/base.apk: Failed to load asset path /data/app/vmdl749343150.tmp/base.apk]
Test: Install command complete (ms: 91 total, 0 apk prep, 91 install)
BUG: b/150865433
Change-Id: Ie33505f9cc08fc6d60ad4a5d709526e7aa9a0ad1
To be submitted along with changes in apksigner tool and the framework.
Merged to AOSP after that.
Test: adb install --incremental <apk>
go/apk-v4-signature-format
Bug: b/151241461
Change-Id: I26e187f8e389e31e2759037057b96fc6c9cb1e94
Previously, we were waiting for the other end to respond after every
file sent, which results in massive slowdown when there's any amount of
latency on the transport.
This improves performance on a cuttlefish instance with ~7ms RTT from:
system/: 2037 files pushed, 0 skipped. 2.8 MB/s (762803979 bytes in 262.964s)
to:
system/: 2037 files pushed, 0 skipped. 11.9 MB/s (762803979 bytes in 61.278s)
Bug: https://issuetracker.google.com/150827486
Test: ./test_device.py
Change-Id: I3a0c893faa5d455cc6ccbc86915a17e1b5abbfbe
(cherry picked from commit 64ff82ba68)
We were previously statically linking libcutils into adbd for several
different reasons, which were addressed as follows:
socket functions: extracted to a statically linked libcutils_network
fs_config: wrapped with a shared library on /system
ATRACE: deleted the single use in adbd
Bug: http://b/150032044
Test: treehugger
Change-Id: I821fa174cfcbfa8e29a4be10de4016b817adbaf8
Merged-In: I821fa174cfcbfa8e29a4be10de4016b817adbaf8
(cherry picked from commit a9b62d5452)
Without this, the caller is likely to assume that their buffer is
fully usable, which clang's analyzer doesn't believe is the case.
Another option is to set `*size` to nonzero.
Caught by the static analyzer:
system/core/adb/client/incremental_server.cpp:111:31: warning: 1st
function call argument is an uninitialized value
[clang-analyzer-core.CallAndMessage]
Bug: http://b/150032044
Test: TreeHugger
Change-Id: Ib844aa4ab3ebb297ca8f6f4289bbe3212275275b
Merged-In: Ib844aa4ab3ebb297ca8f6f4289bbe3212275275b
(cherry picked from commit 19b500bd50)
This command will be sent by adbd to notify the client that the
connection will be over TLS.
When client connects, it will send the CNXN packet, as usual. If the
server connection has TLS enabled, it will send the A_STLS packet
(regardless of whether auth is required). At this point, the client's
only valid response is to send a A_STLS packet. Once both sides have
exchanged the A_STLS packet, both will start the TLS handshake.
If auth is required, then the client will receive a CertificateRequest
with a list of known public keys (SHA256 hash) that it can use in its
certificate. Otherwise, the list will be empty and the client can assume
that either any key will work, or none will work.
If the handshake was successful, the server will send the CNXN packet
and the usual adb protocol is resumed over TLS. If the handshake failed,
both sides will disconnect, as there's no point to retry because the
server's known keys have already been communicated.
Bug: 111434128
Test: WIP; will add to adb_test.py/adb_device.py.
Enable wireless debugging in the Settings, then 'adb connect
<ip>:<port>'. Connection should succeed if key is in keystore. Used
wireshark to check for packet encryption.
Change-Id: I3d60647491c6c6b92297e4f628707a6457fa9420
Bug: 111434128, 119493510, 119494503
Test: Enable wireless debugging in Settings UI, click "pair with pairing code"
to generate pairing code.
On client, 'adb pair <ip_address>', enter pairing code at prompt and hit
enter. Pairing should complete.
'adb logcat'.
Change-Id: I86527bd3fc52e30a8e08ec5843dc3e100abf91fa
Exempt-From-Owner-Approval: approved already
In the context of secure connect, allows adbd and host adb to reject
each other based on incompatible versions without even having to
actually connect (since it is a DNS TXT).
Bug: 111434128, 119490749
Test: N/A
Exempt-From-Owner-Approval: already approved
Change-Id: I54312d8b67370c397ba81ecdbca1b27e3ee58572
This CL exposes a callback-based interface to perform some action for
each resolved pairing/connect service as a function of their hostname,
ip address, and port.
The ADB client can then use this information to either set up secure
connections directly, or to tell the adb host server to do so, or
something.
Bug: 111434128, 119490749
Test: N/A
Exempt-From-Owner-Approval: already approved
Change-Id: I2dd04c322df5b0597859f44703cfd2f3f29fd737
This CL adds functionality to the class ResolvedService where the ip
address associated with a resolved DNS service is recorded.
It also avoids connecting to the device unless it is the Things-related
DNS service.
Next step is to add some kind of interface in other parts of adb code
to retrieve these IP addresses.
Bug: 111434128, 119490749
Test: N/A
Exempt-From-Owner-Approval: already approved
Change-Id: I46895a7a5bf5660f524c7323a9454f1e2c7d385c
This CL makes it so the client looks for the adb secure pairing
and adb secure connect services. Nothing else should happen,
but this should be useful to see if the right packet traffic for
discoverability is happening.
Bug: 111434128, 119490749
Test: N/A
Exempt-From-Owner-Approval: already approved
Change-Id: I266bdb8526cf39bbfa131344dca2b1bb14c14a7b
Since both the client and daemon will now be generating keys.
BUG: b/111434128
Test: atest adb_crypto_test
Change-Id: I6fac562ae5629ab30b6639fbd88d822dae6e96bd
Previously, if we failed to read a file after successfully opening it,
(e.g. because it's a directory), we would return prematurely without
notifying our caller, which would then wait forever for a response that
isn't coming.
Switch all of the adb install callsites over to checking the result,
but leave the other callsites ignoring the result, because they're
either deprecated, or don't care.
Bug: http://b/145621968
Test: mkdir foo.apk; adb install foo.apk
Change-Id: Ia82f8280b144f7881e067a10cd17f9a89019cf3f
fwrite can cross windows platform to show log on terminal,
so we use it instead of WriteFdExactly.
Change-Id: I252c15a0bc72e1dbd98b7b5ec8000ecdcde16416
Signed-off-by: Junyong Sun <sunjy516@gmail.com>
This patch introduce "service.adb.listen_addrs", a new
string type property, while keeping the old properties.
The new property added in this patch is used to listen
on UNIX domain socket "localfilesystem".
"service.adb.listen_addrs" can be used to listen on
multiple addresses, such as tcp:5555 and tcp:5556.
It is separated by ',' (comma) character.
In the process of introducing the new socket type, the
method tcp_connect is removed and combined into
socket_spec_connect.
Without specifying using the new property, adb will
try to listen on both tcp and vsock (following the
previous implementation).
Some examples of the new property value are:
- "tcp:5555"
- "vsock:5555"
- "localfilesystem:/tmp/test"
- "tcp:5555,vsock:5555"
Bug: 133378083
Test: On master-arc-dev:
adb root;
setprop service.adb.listen_addrs localfilesystem:
<path_to_socket>;
adb connect localfilesystem:<path_to_socket>;
adb -s localfilesystem:<path_to_socket> shell;
inside Chrome OS.
Test: On aosp_bluefin:
setprop service.adb.listen_addr tcp:5555;
adb connect <IP>:5555; adb shell;
Test: On aosp_bluefin:
setprop service.adb.tcp.port 5555;
adb connect <IP>:5555; adb shell;
Test: On aosp_bluefin:
setprop service.adb.listen_addrs tcp:5555,tcp:6666;
adb connect <IP>:5555; adb shell;
adb connect <IP>:6666; adb shell;
Test: On aosp_bluefin:
./adb_test;
Test: On cuttlefish:
launch_cvd;
adb -s 127.0.0.1:6520 shell;
Test: Ran host tests:
./adb_test;
./adb_integration_test_adb;
./adb_integration_test_device;
Change-Id: I8289bf0ab3305cf23ce5695ffba46845d58ef6bb
Actually log results of adb commands, so we can see why this fails.
Fix the asan-detected use of a value from a reused part of the stack.
Test: atest FastDeployTest on Linux (with an asan adb)
Change-Id: I4d2bbae62a301e16065d604a2c9918077489cafb
When the adb client starts the adb server, it waits until the server
reports that it's fully-initialized (via reply-fd) before executing
its adb client operation. This wait prevent that adb client from
talking to the server while it's initializing and becoming confused.
But if a *different* adb client connects to the server while it's
initializing, *that* client can temporarily observe unexpected state
while the server initializes itself. For example, such a client can
observe a device that's alive and connected as being offline while the
server connects to it.
The new socket activation support makes this race more apparent, since
in the socket activation configuration, there's no initial adb client
waiting for the server's all-clear indication and so even the first
client observes the partially-initialized server state.
This CL prevents the server accepting *any* client connection until
the server has fully initialized itself, preventing all clients, not
just the initial client, from observing a
partially-initialized server.
Test: test_adb.py; test_adb gtest binary
Test: [with socket activation] adb kill-server; adb devices
Change-Id: I5d399ee62436eee63340b6b8b0f64131ad17ac65
