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: None
Test: TreeHugger
Change-Id: Ib844aa4ab3ebb297ca8f6f4289bbe3212275275b
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
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
Test: treehugger
Change-Id: I821fa174cfcbfa8e29a4be10de4016b817adbaf8
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
Socket activation allows adb to be run as a system daemon that starts
only as needed and supports race-free transparent restarts of the adb
server after a client issues an "adb kill-server" command.
Test: see SOCKET-ACTIVATION.txt
Change-Id: Ieabf08710ce4365e5513102f3aa578560aa7355e
Call adb_notify_device_scan_complete when we finish enumerating USB
devices. The original intent of the code appears to have been to have
adb_wait_for_device_initialization return as soon as we've finished
looking around at the system USB environment on daemon startup, but at
some point, we forgot to actually notify the init thread that we
finished scanning all the USB devices, forcing the wait on init_cv to
time out after three seconds on every daemon initialization.
After this change, the daemon starts in a few milliseconds on my Linux
machine
Test: killall adb && sleep 1 && time adb server && adb shell ls
Change-Id: I0bc1da7a597d2077dd2b591560d03798b05905b7
Before we just got "Failed to read key". After:
adb E 10-07 08:20:14 258249 258249 auth.cpp:176] Failed to read key \
from '/usr/local/google/home/enh/.android/adbkey'
94390117965240:error:0900006e:PEM routines:OPENSSL_internal:NO_START_LINE:\
external/boringssl/src/crypto/pem/pem_lib.c:622:Expecting: ANY PRIVATE KEY
Also fix the misleading "Failed to generate" message from adb_auth_init.
Bug: http://b/141715453
Test: manually corrupted key; see above
Change-Id: I6732ee6b683c8548d596d7c22eeddab8ce9a3cea
- removed 2GB apk size cap,
- removed zip archive parsing on device (1.1M->236K agent size reduction),
- optimized matching entries search,
- added more robust matching entries search based on hash of CDr entry,
- reduced patch size by reusing Local File Header of matched entries,
- removed extra manifest parsing and extra agent calls,
- added device-side tests for agent,
- fix for Windows patch creation.
Test: atest adb_test fastdeploy_test FastDeployTests
Total time for 0-size patch reduction for 1.7G apk: 1m1.778s->0m36.234s.
Change-Id: I66d2cef1adf5b2be3325e355a7e72e9c99992369
dirname (on glibc, at least) preserves multiple leading slashes, and we
were looping until path != "/", which would lead to an infinite loop
when attempting to push to a path like //data/local/tmp.
Bug: http://b/141311284
Test: python -m unittest test_device.FileOperationsTest.test_push_multiple_slash_root
Change-Id: I182b3e89ef52579c716fdb525e9215f1fe822477
A regression from commit 8c2198c809
("adb: use shell for remount to forward return codes.") where the
optional argv[1] got missed for the remount command. This change
hands off _all_ the arguments if to a shell and activates some of
the extra features in the remount command.
$ adb remount --help
remount [-h] [-R] [-T fstab_file] [partition]...
-h --help this help
-R --reboot disable verity & reboot to facilitate remount
-T --fstab custom fstab file location
partition specific partition(s) (empty does all)
Remount specified partition(s) read-write, by name or mount point.
-R notwithstanding, verity must be disabled on partition(s).
$
SideEffects: adb remount [-h] [-R] [-T fstab_file] [partition]...
Test: adb-remount-test.sh
Bug: 138577868
Bug: 139283818
Bug: 139226412
Change-Id: I8223d4000ab20857e9b634e4d4a326eed530d7be
We've seen USB writes failing due to inability to allocate contiguous
chunks of memory in the kernel on devices, but it looks like the same
problem can occur on the host, as well. It's a mild performance
regression (90->80 MB/s on a blueline) to split the writes always, so
attempt the full write first, and fall back to splitting it up if that
fails with ENOMEM. Once we switch over the the asynchronous transport
API, we'll be able to submit multiple writes cheaply, like on devices,
so we won't need to retry at that point.
Bug: http://b/140985544
Test: test_device.py
Change-Id: I1517c348375b829dfff6796c4e9d394802b02d5b
