We can double the speed of "adb sync" (on N9) if we increase SYNC_DATA_MAX
from 64KiB to 256KiB. This change doesn't do that, because I still haven't
managed to plumb through the information about whether we're a new adb/adbd
to file_sync_client.cpp and file_sync_service.cpp. But this is already a big
change with a lot of cleanup, so let's do the cleanup and worry about the
intended change another day...
This change does improve performance somewhat by halving the number of
lstat(2) calls made on the client side, and ensuring that most packets are
sent with a single write. This has the pleasing result of making the null
sync on an AOSP N9 go from just over 300ms to around 100ms, which means it
now seems instantaneous (https://en.wikipedia.org/wiki/Mental_chronometry).
Change-Id: If9f6d4c1f93ec752b95f71211bbbb1c513045166
- handle_host_request
- When the host:kill command comes in, shutdown the socket before
calling exit(). If we don't do this, the client will output error info
even though everything is working ok.
- adb_connect()
- If we can't parse the version string, explain this in error output
and don't goto error which would try to close an fd we already closed.
- If host:kill doesn't work, output error info. Don't try to close
already closed fd.
- adb_main()
- If writing the ACK somehow has an error, output error info (I doubt
this will ever get hit).
- adb_commandline()
- Fix typo about max port number.
- Make 'adb kill-server' and 'adb start-server' output any detailed
error info.
Change-Id: Id1a309cc1bf516f7f49bd332b34d30f148b406da
Signed-off-by: Spencer Low <CompareAndSwap@gmail.com>
The win32 version of 9f2d1a9cfc. The big
technique is to fit a Win32 HANDLE value in an int because it only uses
32-bits. This allows most of the other adb code to stay the same.
Also, fix a regression in the 'adb server nodaemon' command that was
erroneously returning an error when --reply-fd was not used, which
should not be necessary for this particular command.
Change-Id: I37e9c609014b813af93bf0d6c12f665b59c93c41
Signed-off-by: Spencer Low <CompareAndSwap@gmail.com>
When "adb start-server" is issued, and a server needs to be launched,
adb client forks itself and the child process runs the server routine.
Once the server initializes its various components, it sends an "OK\n"
back to the client via its stderror (or stdout on Windows).
This sequence breaks down if before sending the "OK\n", the server
happens to log something on its stderr. In order to avoid this, the
client now expects the ack to come on a different fd rather than one
of the standard streams.
Bug: https://code.google.com/p/android/issues/detail?id=182150
Change-Id: I9d58a08068d71eb3b77e8a7377e934631c016466
This removes adb_dirstart and adb_dirstop. It also fixes a couple of memory
leaks by switching to std::string. This also fixes the bug in the previous
change --- mkdirs is given input like "/system/bin/sh" and only expected to
create "/system/bin". In a later change, we should remove mkdirs and only
expose the intended "unlink && mkdirs && create" functionality.
Change-Id: I30289dc1b3dff575cc1b158d993652178f587552
~ Rewrote mkdirs to be in C++ style.
~ Replaced adb_dir{start,stop} with std::string params and (r)find.
+ Added test for mkdirs.
Also make base/test_utils.h public and support temporary directories
as well as files.
Change-Id: I6fcbdc5e0099f3359d3aac6b00c436f250ca1329
This causes build failures in google3 where they use GCC. glibc only
provides const-correct overloads for string functions for GCC >= 4.4,
but clang -- which is what we use -- pretends to be GCC 4.2.
Change-Id: I2a054823ea6201ebcea46d5e77b80a975eefc622
One of my build aliases doesn't play nice with USE_MINGW=1, so my build lied to me. Will revert until I fix it up.
This reverts commit 459df8f3a1.
Change-Id: I7905c5ae5ee85fb2d228ce63d81c79f140998c18
Apparently there are two classes of this warning in clang.
-Wformat-security is only emitted for cases of
`func(nonliteral_fmt_string)` (no args), and -Wformat-nonliteral is
emitted for cases *with* arguments. For whatever reason, the latter
isn't included in -Wextra and must be manually enabled.
To make this more easily portable to Windows, move the existing
gnu_printf/__printf__ decision into base/macros.h as ATTRIBUTE_FORMAT.
Change-Id: I3b0990e1d1f0a2e9c13b32f5cd60478946cb5fc6
One day we should slim this down. (Maybe implement the "help" versus
"help all" distinction that doesn't currently exist but was documented
before this change.)
Bug: https://code.google.com/p/android/issues/detail?id=158394
Change-Id: Ie24b588ffea00d262ce7ab0e5c328120ba8af240
adb exec-in and exec-out are designed to read/write binary data
according to the commit description at:
https://android.googlesource.com/platform/system/core/+/5d9d434%5E!/
On Windows, when adb_read and adb_write are used, they are always in
binary mode (because sysdeps_win32.cpp calls Windows APIs direct). But
unix_read, unix_write, fread, fwrite, read, write use the text
translation mode of the C Runtime file descriptor, which is by default
textmode.
adb exec-in and exec-out use copy_to_file() which uses unix_read() and
fwrite() when reading/writing stdin and stdout, thus, copy_to_file()
should switch to binary mode for those cases (it already uses binary
mode for file descriptors other than stdin and stdout).
copy_to_file() is also called by adb backup, adb restore, and adb
install-multiple, but those do not use stdin or stdout, so those
codepaths should not be affected by this change.
Change-Id: I3446d9b363d20a2c2f6be2b96e55b653d99df2f9
Signed-off-by: Spencer Low <CompareAndSwap@gmail.com>
We really need better infrastructure for parsing adb subcommands, but
in the meantime...
At least this cleans up a little more of the implementation too.
Bug: http://b/20736014
Change-Id: I76209847da3724906c71924017bcb69fa31e0b49
At runtime, vsnprintf (and android::base::StringPrintf which calls it)
call a mingw version of vsnprintf, not the vsnprintf from MSVCRT.DLL.
The mingw version properly understands %zd and PRIu64 (the latter,
provided that you #include <inttypes.h>).
The problem was that android::base::StringPrintf was causing
compile-time errors saying that %zd and PRIu64 were not recognized. It
seems that this was because the attribute on the function prototypes
specified `printf' instead of `gnu_printf'. Once that was fixed to match
vsnprintf's attribute, the warnings went away.
This uses similar preprocessor techniques as <android/log.h>.
Also restore a %zd usage to avoid a static_cast<>, and make
print_transfer_progress()'s format string compile-time checkable (and
tweak some types and %llu => PRIu64).
Change-Id: I80b31b9994858a28cb7c6847143b86108b8ab842
Signed-off-by: Spencer Low <CompareAndSwap@gmail.com>
On a device without an oem partition, we now have an /oem directory
anyway. This causes find_mount to fail, and that was returning nullptr
from a std::string-returning function. Boom!
Also clean up the bits of code I had to trace through between "adb remount"
on the host to the crash on the device as I debugged this.
The only other meaningful change is the error checking in
adb_connect_command --- adb_connect can also return -2.
Bug: http://b/20916855
Change-Id: I4c3b7858e13f3a3a8bbc7d30b3c0ee470bead587
(cherry picked from commit 5677c23e8d)
On a device without an oem partition, we now have an /oem directory
anyway. This causes find_mount to fail, and that was returning nullptr
from a std::string-returning function. Boom!
Also clean up the bits of code I had to trace through between "adb remount"
on the host to the crash on the device as I debugged this.
The only other meaningful change is the error checking in
adb_connect_command --- adb_connect can also return -2.
Bug: http://b/20916855
Change-Id: I4c3b7858e13f3a3a8bbc7d30b3c0ee470bead587
