Instead of sending the whole tree upfront use the same
streaming interface for it as for the data blocks
This improves installation speed by almost 200ms,
650-800ms -> 500-600ms
Bug: 153696423
Test: manual, adb install in various configurations
Change-Id: Ia83de2af54ca0b1969397514ea5d761719af9055
(cherry picked from commit e2e850f325)
Merged-In: Ia83de2af54ca0b1969397514ea5d761719af9055
To fix mac build error. Shouldn't be building this for the host.
Bug: N/A
Test: mma in system/core/adb on mac.
Change-Id: I8b86d265ef9b91eeaf7a4e5d6623a5399403ecaf
Also switch to #pragma once and s/__inline__/inline/g for consistency.
There are a handful of inlines that are missing static, which seems like
a bug, but I've left those for now.
Bug: http://b/153328340
Test: treehugger
Change-Id: I2353215c0a8a6154ce8b39ecde022b282f5c0cb9
Merged-In: I2353215c0a8a6154ce8b39ecde022b282f5c0cb9
(cherry picked from commit 681338dfb6)
Instead of sending the whole tree upfront use the same
streaming interface for it as for the data blocks
This improves installation speed by almost 200ms,
650-800ms -> 500-600ms
Bug: 153696423
Test: manual, adb install in various configurations
Change-Id: Ia83de2af54ca0b1969397514ea5d761719af9055
Merged-In: Ia83de2af54ca0b1969397514ea5d761719af9055
Instead of sending the whole tree upfront use the same
streaming interface for it as for the data blocks
This improves installation speed by almost 200ms,
650-800ms -> 500-600ms
Bug: 153696423
Test: manual, adb install in various configurations
Change-Id: Ia83de2af54ca0b1969397514ea5d761719af9055
The features are already cached in a static and don't change.
Let's return the cached set instead of copying it every time.
Bug: 150183149
Test: manual
Change-Id: Ifdca852cc3b32e09e50ea4771f7878987c46cce8
APEXes introduced in R need to set min_sdk_version to ensure that they
are built against correct version of stubs (libc/liblog/...).
Bug: 152655956
Test: m
Merged-In: Id3f94a2ac09bd7bf7f9a4a0c2f62b624f29509d0
Change-Id: Id3f94a2ac09bd7bf7f9a4a0c2f62b624f29509d0
(cherry picked from commit ab9dfa4321)
This reverts commit bfe3dac36d.
This seems to be correlated with an increase in the rate of devices
going offline. Revert it to see if failure rates improve.
Bug: http://b/150863651
Test: treehugger
Change-Id: Ia6163fd9e31d2bf812628e028249662594ac2024
This reverts commit d9684d5943.
This seems to be correlated with an increase in the rate of devices
going offline. Revert it to see if failure rates improve.
Bug: http://b/150863651
Test: treehugger
Change-Id: Ia6163fd9e31d2bf812628e028249662594ac2024
In the post-apocalypse, it's increasingly common for people to use ssh
port forwarding to use an adb client with a remote adb server. This
results in `adb kill-server` being catastrophic, because the client has
no way of restarting the server on the other end. Android Studio in
particular has an unforunate habit of trying to manage adb's life cycle
such that starting or exiting Studio will result in a kill-server.
Add the ADB_REJECT_KILL_SERVER environment variable which ignores
kill-server, to make this scenario a bit better.
Bug: http://b/152251952
Test: ADB_REJECT_KILL_SERVER=1 adb start-server; adb kill-server
Change-Id: I5533a6dcbdb9220526a6fcf9ca31d9fcef1cec17
Also switch to #pragma once and s/__inline__/inline/g for consistency.
There are a handful of inlines that are missing static, which seems like
a bug, but I've left those for now.
Bug: http://b/153328340
Test: treehugger
Change-Id: I2353215c0a8a6154ce8b39ecde022b282f5c0cb9
Make it easier to benchmark file sync performance by ignoring the file
system.
Bug: https://issuetracker.google.com/150827486
Test: test_device.py
Change-Id: Icfa4b28eb5206f1914c0c163833d070a3748c3ea
Add support for LZ4 compression, which compresses and decompresses far
more quickly than brotli, at the cost of worse compression ratio.
`adb sync -d system` speeds (in MB/s) on aosp_blueline-eng:
none brotli lz4
USB 3.0 120 110 190
USB 2.0 38 75 63
Bug: https://issuetracker.google.com/150827486
Test: python3 -m unittest test_device.FileOperationsTest{Uncompressed,Brotli,LZ4}
Change-Id: Ibef6ac15a76b4e5dcd02d7fb9433cbb1c02b8382
More groundwork to support more compression algorithms.
Bug: https://issuetracker.google.com/150827486
Test: python3 -m unittest test_device.FileOperationsTest{Uncompressed,Brotli}
Change-Id: I638493083b83e3f6c6854b631471e9d6b50bd79f
APEXes introduced in R need to set min_sdk_version to ensure that they
are built against correct version(30 or R) of stubs (libc/liblog/...).
Bug: 152655956
Test: /vendor/google/build/build_mainline_modules.sh
Change-Id: Id3f94a2ac09bd7bf7f9a4a0c2f62b624f29509d0
Temporarily delete adb_benchmark, since it seems difficult to make this
sensibly work with a single target that's used for both libadb and
libadbd benchmarking.
Bug: http://b/150317254
Test: treehugger
Change-Id: Ibf81fdff4f2b7304b586ce9a7955b4bc2c11484e
Merged-In: Ibf81fdff4f2b7304b586ce9a7955b4bc2c11484e
(cherry picked from commit c6cb89ea80)
This code path is effectively dead in adbd, and fastboot's dependency on
libadbd makes it hard to refactor adbd's dependencies.
Bug: http://b/150317254
Test: built and flashed aosp_walleye-eng
Change-Id: I5118136d32fdcbbd011559ed0a4a71e1dc7bf064
Merged-In: I5118136d32fdcbbd011559ed0a4a71e1dc7bf064
(cherry picked from commit 0871824de6)
Incremental doesn't support apex installation, but we were exiting
instead of returning -1 to fall back to regular installation.
Bug: http://b/151900478
Test: manual
Change-Id: Id27009250090a65fbb45bb65fc39c1799bf1f861
Merged-In: Id27009250090a65fbb45bb65fc39c1799bf1f861
This CL turns on the incremental installation for all
"adb install ..." commands where no explicit mode has been set.
To disable this, set the ADB_INSTALL_DEFAULT_INCREMENTAL
environment variable to 0/n/no/false. Unset to enable back
+ improve the install command argument parsing a bit: allow
--wait for all installation modes, --incr is enough for
an incremental install (and --no-incr to disable it)
Bug: 150183149
Test: adb install with different apks and command line switches
Change-Id: I1a237f34b70d920146746ab16104e28ef555a5fd
Merged-In: I1a237f34b70d920146746ab16104e28ef555a5fd
Incremental doesn't support apex installation, but we were exiting
instead of returning -1 to fall back to regular installation.
Bug: http://b/151900478
Test: manual
Change-Id: Id27009250090a65fbb45bb65fc39c1799bf1f861
Temporarily delete adb_benchmark, since it seems difficult to make this
sensibly work with a single target that's used for both libadb and
libadbd benchmarking.
Bug: http://b/150317254
Test: treehugger
Change-Id: Ibf81fdff4f2b7304b586ce9a7955b4bc2c11484e
This code path is effectively dead in adbd, and fastboot's dependency on
libadbd makes it hard to refactor adbd's dependencies.
Bug: http://b/150317254
Test: built and flashed aosp_walleye-eng
Change-Id: I5118136d32fdcbbd011559ed0a4a71e1dc7bf064
This CL turns on the incremental installation for all
"adb install ..." commands where no explicit mode has been set.
To disable this, set the ADB_INSTALL_DEFAULT_INCREMENTAL
environment variable to 0/n/no/false. Unset to enable back
+ improve the install command argument parsing a bit: allow
--wait for all installation modes, --incr is enough for
an incremental install (and --no-incr to disable it)
Bug: 150183149
Test: adb install with different apks and command line switches
Change-Id: I1a237f34b70d920146746ab16104e28ef555a5fd
The status line char* was getting converted to bool and used as the
compression argument, and the actual status line was defaulting to
nullptr. This didn't actually really change anything, since we only use
the name during transfer, and not for the final message at the end, so
the output is slightly uglier for 50 milliseconds.
This also had the side effect of turning on compression for the
already-compressed bugreport zip, which costs a bit of throughput with
brotli.
Bug: https://issuetracker.google.com/150827486
Test: adb bugreport foo.zip
Change-Id: I74bed9c09442c655a956eb1e8318c0123632ef4c
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 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
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
Bug: 150719467
Test: atest adb_pairing_auth_test
Test: check 'adb pair' command on all three platforms work
Change-Id: Idfc64fe7bed2d09f4da9d2f7df70f9d6ae4e8fa3
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
Bug: 150719467
Test: atest adb_pairing_auth_test
Test: check 'adb pair' command on all three platforms work
Change-Id: Idfc64fe7bed2d09f4da9d2f7df70f9d6ae4e8fa3
Exempt-From-Owner-Approval: approved in go/ag/10808153
This reverts commit 56a712f6c9.
Reason for revert: forward fix is at aosp/1265379
Exempt-From-Owner-Approval: relanding of an already approved CL
Change-Id: I0d93417939d570ce21f105ee4b3bae6414194dbe
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
Merged-In: 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
Merged-In: I223284c8a662bd8f2b8ba280cdcc8c930d3e5205
- Use one fewer heap allocation per fdevent object
- Lazy-init the fdevent context
Bug: 151239696
Test: various adb commands on Win/Linux
Change-Id: Ic7de207b30495e618f187e097c0276ad42c34005
Merged-In: Ic7de207b30495e618f187e097c0276ad42c34005
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
Merged-In: Ia6de620171ab696b8136dcb60a2b63af6f86419f
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
Merged-In: 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
Merged-In: Ie33505f9cc08fc6d60ad4a5d709526e7aa9a0ad1
To be submitted along with changes in apksigner tool and the framework.
Merged to AOSP after that.
Test: adb install --incremental <apk>
Bug: b/151241461
Change-Id: I26e187f8e389e31e2759037057b96fc6c9cb1e94
Merged-In: I26e187f8e389e31e2759037057b96fc6c9cb1e94
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)
Make it so that we can get the sizeof a member of syncmsg without having
an instance of syncmsg or doing something awful along the lines of
sizeof(reinterpret_cast<syncmsg*>(nullptr)->status).
Bug: http://b/150827486
Test: m adb adbd
Change-Id: I4830e7f90033c7706ff52cdd8d13e9cf40c73628
(cherry picked from commit eddae92928)
The marked library(ies) were available to the adbd APEX via the
hand-written whitelist in build/soong/apex/apex.go. Trying to remove the
whitelist by adding apex_available property to the Android.bp of the
libraries.
Exempt-From-Owner-Approval: already +2'ed by the owner (enh)
Bug: 150999716
Bug: 151398197
Test: m
Change-Id: I8b572e3c4e76bd10c0443a6c08b72e9519243ab5
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.
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
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
Make it so that we can get the sizeof a member of syncmsg without having
an instance of syncmsg or doing something awful along the lines of
sizeof(reinterpret_cast<syncmsg*>(nullptr)->status).
Test: m adb adbd
Change-Id: I4830e7f90033c7706ff52cdd8d13e9cf40c73628
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 one fewer heap allocation per fdevent object
- Lazy-init the fdevent context
Bug: 151239696
Test: various adb commands on Win/Linux
Change-Id: Ic7de207b30495e618f187e097c0276ad42c34005
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
abb links against libadbd_core for the shell protocol, and must be
on the system image because it links against cmd, so let's just
expose it to abb for now.
Bug: http://b/151398197
Test: treehugger
Change-Id: Id926bc4324d3259def21ea19d3bd72320311a6e3
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
We were ending up with multiple copies of the proto runtime in the
recovery image, when we need zero.
Before:
784K recovery/root/system/lib64/libadbd_services.so
832K recovery/root/system/lib64/libadbd.so
After:
360K recovery/root/system/lib64/libadbd_services.so
344K recovery/root/system/lib64/libadbd.so
Bug: http://b/150317254
Test: treehugger
Change-Id: I39fbb3959128994f0de2ae0ea47dbc0800c516fe
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
libselinux is currently being copied to APEXes. This is risky because
the library is not designed to be portable; part of it is tied to the
specific version of the Android that it was developed for.
This change fixes the problem by declaring that the library supports
a stub with the list of C APIs that are included in the stub. Then there
is only one copy of libselinux in /system/lib and other APEXes use the
copy by dynamically linking to it.
Also, adbd no longer statically links to it, because doing so brings
libselinux in it.
Bug: 151053366
Test: m com.android.adbd. It doesn't include libselinux in it.
Test: m com.android.adbd-deps-info. then inspect
out/soong/com.android.adbd-deps-info.txt. The dependency to libselinux
is shown as '(external)'.
Exempt-From-Owner-Approval: cherry-pick from AOSP
Merged-In: If418cbe3abdeacb759d59052e6dca4c2067678dd
(cherry picked from commit 3ffdad0cb5)
Change-Id: If418cbe3abdeacb759d59052e6dca4c2067678dd
libselinux is currently being copied to APEXes. This is risky because
the library is not designed to be portable; part of it is tied to the
specific version of the Android that it was developed for.
This change fixes the problem by declaring that the library supports
a stub with the list of C APIs that are included in the stub. Then there
is only one copy of libselinux in /system/lib and other APEXes use the
copy by dynamically linking to it.
Also, adbd no longer statically links to it, because doing so brings
libselinux in it.
Bug: 151053366
Test: m com.android.adbd. It doesn't include libselinux in it.
Test: m com.android.adbd-deps-info. then inspect
out/soong/com.android.adbd-deps-info.txt. The dependency to libselinux
is shown as '(external)'.
Change-Id: If418cbe3abdeacb759d59052e6dca4c2067678dd
For currently unknown reasons, sideloading is broken with
libadbd_services as a cc_library_static.
Partial revert of commit a9b62d5452.
Bug: http://b/151056300
Test: xunchang@ tested manually
Change-Id: Iaffad9c476ba0adcffc5db512ba4a7ee0fb5cb22
(cherry picked from commit 7f8a37c8c7)
With some internal API changing from "const char*" to
"const std::string&", we can change a couple calling sites to
directly pass a std::string reference, instead of getting the
c_str() version of the string. This avoids us creating a
temporary std::string for the call.
Test: TreeHugger
Change-Id: I2fe0760ce8bf7d352010a341005356c0a801d351
liblog is a platform library that provides stable C API. There is no
need to include the library, especialy by statically linking to it, in
any APEX. It not only wastes the storage/ram, but also is incorrect
because the socket interface to logd which is implemented in liblog is
not guaranteed to be stable.
Fixing this issue by converting static_libs: ["liblog"] into
shared_libs: ["liblog"], in which case the dependency to the library
is satisfied via the stub variant of the library.
As a result, we could restrict the availablity of the library to
the platform and the runtime APEX.
Exempt-From-Owner-Approval: already approved when this was in internal
master (ag/10572699)
Bug: http://b/151051671
Bug: http://b/150827719
Test: m
Merged-In: I5aab863cb12b8767b6979255c247000a59355b0e
(cherry picked from commit 95b6f45b0e)
Change-Id: I5aab863cb12b8767b6979255c247000a59355b0e
liblog is a platform library that provides stable C API. There is no
need to include the library, especialy by statically linking to it, in
any APEX. It not only wastes the storage/ram, but also is incorrect
because the socket interface to logd which is implemented in liblog is
not guaranteed to be stable.
Fixing this issue by converting static_libs: ["liblog"] into
shared_libs: ["liblog"], in which case the dependency to the library
is satisfied via the stub variant of the library.
As a result, we could restrict the availablity of the library to
the platform and the runtime APEX.
Exempt-From-Owner-Approval: already approved when this was in internal
master (ag/10572699)
Bug: http://b/151051671
Bug: http://b/150827719
Test: m
Change-Id: I5aab863cb12b8767b6979255c247000a59355b0e
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)
For currently unknown reasons, sideloading is broken with
libadbd_services as a cc_library_static.
Partial revert of commit a9b62d5452.
Bug: http://b/151056300
Test: xunchang@ tested manually
Change-Id: Iaffad9c476ba0adcffc5db512ba4a7ee0fb5cb22
* mdns.cpp:153:20: warning: an integer is interpreted as a character code
when assigning it to a string; if this is intended, cast the integer to
the appropriate character type; if you want a string representation, use
the appropriate conversion facility [bugprone-string-integer-assignment]
Test: WITH_TIDY=1 make
Change-Id: Id9a790ac31722c6ee8886703939977b913ce95fe
In particular, always include the file name in the log.
Bug: http://b/144462309
Test: adb kill-server && adb devices -l && cat /tmp/adb.*.log
Change-Id: I66b5e063b00381f9dfa9ace222cad3e415e4f43b
Add a "track-app" service in adbd. For every debuggable or
profileable-from-shell process, ART sends related info to
adbd and adbd surfaces the info through the "track-app"
service.
The output format of "track-app" is a line summarizing
the number of reported processes, followed by a protobuf
message in human readable form. For example,
Process count: 2
process {
pid: 3307
profileable: true
architecture: "arm64"
}
process {
pid: 3341
debuggable: true
profileable: true
architecture: "arm64"
}
Bug: 149050485
Test: manually unplugged/replugged, "adb track-app",
"adb track-jdwp"
Change-Id: Id1f1a920e1afc148c7e4d2add790baab796178e1
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
Will re-enable once flaky failure is fixed.
Bug: 150529485
Bug: 150388912
Test: atest adb_pairing_connection_test doesn't run above test.
Change-Id: I63ac3fc2fd2d289b977dd3b9f6eccfb65866769c
Add some requested logging options that can be turned on at runtime
without having to restart adbd.
Bug: http://b/141959374
Test: manual
Change-Id: Ib97acc6d199e0b91238a6758e18b7cb75f8688d9
(cherry picked from commit 52d0b67f19)
If we get unlucky and something else (or ourselves, in another thread)
beats us to listening on our hardcoded ports, we can deadlock.
Bug: http://b/149829737
Test: ./test_adb.py
Change-Id: I8f14004a6b2e77366abad6e88786ea8941629020
(cherry picked from commit e8829c6bfc)
Add some requested logging options that can be turned on at runtime
without having to restart adbd.
Bug: http://b/141959374
Test: manual
Change-Id: Ib97acc6d199e0b91238a6758e18b7cb75f8688d9
Also remove statically linking libc++, because these libraries are not
exported native shared libraries.
We are slightly over the 12MB limit for ramdisk recovery size, so let's
remove the adb pairing libraries, since they won't be used in recovery
mode.
These are only used in normal boot mode, and currently, only by adb
client. The pairing server is used by system server.
Bug: 150317254
Test: Check size of ramdisk-recovery.img in walleye, walleye-hwasam
build to be under 12MB. Also verify installed-files-recovery.txt no
longer contains libadb_pairing*.
Also put phone into recovery mode, check system/lib64 for no
libadb_pairing*.
Change-Id: Ida7c4fdc9dda2b09091b853feac8df8f125e4274
Merged-In: Ida7c4fdc9dda2b09091b853feac8df8f125e4274
(cherry picked from commit afc2cf0dec)
Exempt-From-Owner-Approval: cherry-pick
Also remove statically linking libc++, because these libraries are not
exported native shared libraries.
We are slightly over the 12MB limit for ramdisk recovery size, so let's
remove the adb pairing libraries, since they won't be used in recovery
mode.
These are only used in normal boot mode, and currently, only by adb
client. The pairing server is used by system server.
Bug: 150317254
Test: Check size of ramdisk-recovery.img in walleye, walleye-hwasam
build to be under 12MB. Also verify installed-files-recovery.txt no
longer contains libadb_pairing*.
Also put phone into recovery mode, check system/lib64 for no
libadb_pairing*.
Change-Id: Ida7c4fdc9dda2b09091b853feac8df8f125e4274
(cherry picked from commit afc2cf0dec)
Exempt-From-Owner-Approval: cherry-pick
If we get unlucky and something else (or ourselves, in another thread)
beats us to listening on our hardcoded ports, we can deadlock.
Bug: http://b//149829737
Test: ./test_adb.py
Change-Id: I8f14004a6b2e77366abad6e88786ea8941629020
Mark updatable APEXes as updatable: true so that they are opted-out from
optimizations that make sense only for non-updatable modules; such as
symlinking to the libs in the system partition.
Bug: 149805758
Test: m and check that there is no symlink from the APEX to the system
partition.
Exempt-From-Owner-Approval: cherry-pick from internal
Merged-In: Ic3edc7e285e9eafbdaa20b18ccbc0b2231370779
(cherry picked from commit 7c2ae1f02c)
Change-Id: Ic3edc7e285e9eafbdaa20b18ccbc0b2231370779
This broke because two CLs touching the Android.bp file both
independently passed presubmit, but failed when combined.
Clean up a misindentation while we're at it.
Bug: http://b/150032044
Bug: http://b/150032367
Test: mma in system/core/adb
Change-Id: I091ef9dec806c767ffb21a5fd73b2bb37ab29ff9
Merged-In: I091ef9dec806c767ffb21a5fd73b2bb37ab29ff9
(cherry picked from commit 6d949e89a4)
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)
Mark updatable APEXes as updatable: true so that they are opted-out from
optimizations that make sense only for non-updatable modules; such as
symlinking to the libs in the system partition.
Bug: 149805758
Test: m and check that there is no symlink from the APEX to the system
partition.
Change-Id: Ic3edc7e285e9eafbdaa20b18ccbc0b2231370779
This broke because two CLs touching the Android.bp file both
independently passed presubmit, but failed when combined.
Clean up a misindentation while we're at it.
Bug: http://b/150032367
Test: mma in system/core/adb
Change-Id: I091ef9dec806c767ffb21a5fd73b2bb37ab29ff9
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
Dynamic linker will use generated linker configuration in general. As
ld.config.txt file in the APEX module will not be used, we can remove
this to avoid confusion.
Bug: 149887007
Test: m -j passed
Test: Boot succeeded from cuttlefish and walleye
Change-Id: Ic98aca819b5a4d0e0af4fe0ea25145a483aa7d53
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
For privacy/security reasons, let's not broadcast the adb secure
services on startup automatically, and instead leave that up to
the rest of the adbd code somehow.
Instead, this CL adds an API in daemon/mdns.h that lets the user
control when registration happens, potentially only doing so if
the developer option is enabled or something.
Bug: 111434128, 119490749
Test: N/A
Exempt-From-Owner-Approval: already approved
Change-Id: Idc994a59ef9e5d48f08796c21989883497e19ef8
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
Treehugger Robot