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
Replace libcrypto with libcrypto_static, which can be protected through
visibility to ensure only modules that don't affect FIPS certification
can use it.
Bug: 141248879
Test: m checkbuild
Change-Id: I5f0b9acfb57f68570f6f58f2395f2bb1bc015365
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
We regressed handling of the old host transport selection syntax, which
broke users that reimplement adb themselves (e.g. Studio via ddmlib).
Bug: https://issuetracker.google.com/140369526
Test: adb raw "host-serial:822X0028S:forward:tcp:42929;localabstract:/com.example.ndktest-0/platform-1568299082100.sock"
Test: ./test_device.py
Change-Id: Iaaec8fde952316fe9bf2a6f6c6c4a3bc9f74bf72
Linux doesn't seem to actually support emitting them, so we can't check
that they're actually there, but commit the code to read them so that
if and when Linux gets support, it's easier to check.
This also adds some error checking for ill-formed binary object store
entries.
Test: check_ms_os_desc
Change-Id: I4baf6a16f0f96acbec468b843db65d4ab3a589fe
Protobuf 3.9.1 redefines google::protobuf::int64 from long long to
int64_t, which is sometimes long and sometimes long long. Use PRId64
to print it.
Bug: 117607748
Test: m checkbuild
Change-Id: I6699cfdb0f0424aa3e1c98b59d941beb9f133055
Merged-In: I6699cfdb0f0424aa3e1c98b59d941beb9f133055
Ensure that off64_t is defined when building adb for mac
Fixes: 139646013
Test: make # On mac
Change-Id: I32b68738d71c8a63a35c22434092933dcabac1ce
(cherry picked from commit 2167b9082d)
Implement an epoll-backed fdevent_context, that reduces overhead when
we're polling many file descriptors. FdeventTest.smoke goes from ~5.2s
to ~3.3s when run on the host (after this patch's modification to change
it from chaining 10 file descriptors together to 512).
Test: adb_test on host
Test: adbd_test on blueline
Test: test_adb.py
Test: test_device.py
Change-Id: Iacf0093aa7bebea31e447c2cb012af72d8c3297e
As a side effect, delete FDE_ACTIVE, which was always set on every
fdevent, and FDE_PENDING, which was an internal implementation detail.
This patch removes spin detection, which will be reimplemented
separately later.
Test: adb_test on host
Test: adbd_test on blueline
Change-Id: I40be3504ce03c4fae5e071fa018542a051b7511d
It fixes following issue when compiling adb with host libraries:
In file included from core/adb/client/adb_install.cpp:31:
In file included from core/adb/adb.h:30:
In file included from core/adb/socket.h:28:
core/adb/types.h:237:9: error: use of undeclared identifier 'memcpy'; did you mean 'wmemcpy'?
memcpy(copy->data(), first_block->data() + begin_offset_, copy->size());
^~~~~~
wmemcpy
/usr/include/wchar.h:262:17: note: 'wmemcpy' declared here
extern wchar_t *wmemcpy (wchar_t *__restrict __s1,
Change-Id: I233e533fa7a5e2ed98190e34e32ddbaddc528558
It fixes a compilation issue:
/fdevent/fdevent_poll.cpp -o core/adb/fdevent/fdevent_poll.cpp.o
In file included from core/adb/fdevent/fdevent_poll.cpp:20:
In file included from core/adb/fdevent/fdevent_poll.h:29:
core/adb/fdevent/fdevent.h:106:10: error: no template named 'atomic' in namespace 'std'
std::atomic<bool> terminate_loop_ = false;
~~~~~^
Change-Id: I5305a69a50e2638f514c5a7d47a9612b8ee38c69
1. Use bigger buffer for transfers - 64kb is the default size
for push, so let it be the same in streaming
2. Use abb when it's available for lower overhead
3. Add a posix_fadvise() on the source APK
4. Increase buffer sizes for the socketpair that's transferring
the data from adbd.
Overall this saves about 25% time for streaming installations
and makes it faster than the legacy push (at last!)
Test: manual
Change-Id: Ieb84284da2058944815e062ef6e4389b842565fa
Previously, we were calling acquire_one_transport with all empty
parameters, which would work when only one device is connected, but fail
when there are multiple. We've already acquired a transport and put it
into the socket as part of the forward request, so just use that
directly.
Bug: http://b/136198949
Test: test_device.py with multiple devices connected
Change-Id: I4d6bda45b36b71e418ecd9ead61b7379e68aa19b
Josh Gao