Hadn't caught this in the previous submission because I tested the
build with another change on top of it that also fixes this.
Bug: 17626262
Change-Id: Ia40127618a5466e382081760d614ff7fc09d50a3
Much of adb is duplicated in bootable/recovery/minadb and fastboot.
Changes made to adb rarely get ported to the other two, so the trees
have diverged a bit. We'd like to stop this because it is a
maintenance nightmare, but the divergence makes this difficult to do
all at once. For now, we will start small by moving common files into
a static library. Hopefully some day we can get enough of adb in here
that we no longer need minadb.
Bug: 17626262
Change-Id: Ic8d5653bfcc0fec4e1acbece124402355084b864
The kernel finally has the pt_regs structure properly defined for mips,
so we don't need to define it ourselves.
Change-Id: Ifdf75ed827cd2390962e9b3a182bdbbf02fe0732
There was a misinterpretation of how the v2 header works. The flags
in the header indicate what is in the rest of the structure.
Bug: 19127803
Change-Id: I5fa0dae6da51522c9afc4c94838eb6f462208683
If you run `adb tcpip`, adbd tries to process a string of 'tcpip:' using
this code:
} else if(!strncmp(name, "tcpip:", 6)) {
int port;
if (sscanf(name + 6, "%d", &port) == 0) {
port = 0;
}
ret = create_service_thread(restart_tcp_service, (void *) (uintptr_t) port);
If a zero-length string is passed to sscanf(), it returns EOF (-1) which
causes the if statement to skip the block, leaving the port variable
uninitialized.
I found this by running `adb tcpip` and sometimes getting 'invalid port'
and sometimes a device would start listening on a random port number.
The fix is to check the sscanf() return value for the success case (the
number of items successfully parsed), as is already done in other parts
of the adb code. I also fixed-up another instance of the same
code-pattern in services.c.
Change-Id: I8c9c33485ad076828da0ac74f048fdad561669d3
Signed-off-by: Spencer Low <CompareAndSwap@gmail.com>
logd suffers major performance degradation when persistent (blocking)
client reader connects to it (e.g. logcat). The root cause of the
degradation is that each time when reader is notified of the arrival
of new log entries, the reader commences its search for the new entries
from the beginning of the linked list (oldest entries first).
This commit alters the search to start from the end of the linked list
and work backwards. This dramatically decreases logd CPU consumption
when blocking reader is connected, and increases the maximum logging
throughput (before the logs start getting lost) by a factor ~ 20.
Change-Id: Ib60955ce05544e52a8b24acc3dcf5863e1e39c5c
- create a structure to depict the private header
expected at logd end of socket.
- utilize this new structure instead of unscalable
byte stream technique used to unpack in logd.
Change-Id: I2d0e5c3531c279f2dc1fbd74807210ff8d804de0
When mounting fstab entries it is practical to be able to specify
for example LABEL=data instead of a specific block device.
This is particularly important for the new Android Emulator code base,
which uses virtio block devices for the various partitions
(system,data,cache), because there is no defined ordering between the
way the filesystems are specified to the emulator and how they are
enumerated by the android kernel as /dev/vdX.
Change-Id: I7aef95f12e8f7b02ac2e33804ba7897fdcb9ad7f
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Due to a typo, the --no-rebind option never worked (it always failed).
The root of the problem was that the client was sending on the wire
a command like:
host:forward:norebind::tcp:<port>;tcp:<port>
^^
Instead of:
host:forward:norebind:tcp:<port>;tcp:<port>
^
Note the erroneous double-column.
The fix is local to the adb client and thus doesn't require a new
version of the server or guest adbd on the device-side.
This also fixes 'adb reverse --no-rebind'.
See https://code.google.com/p/chromium/issues/detail?id=451109
Change-Id: I680fd432b5470072f6a9968ca32a7f90c600ac68
Dan Albert