Add the OUYA VID to the list of known USB VIDs to allow developers with OUYA
consoles to have their device automatically recognized.
Change-Id: I499114d8071747b972c24681fc0771f000ad9f9d
Both CS_RECOVERY and CS_SIDELOAD where not being checked by
connection_state_name which resulted in adb get-state returning
unknown when a device is in those modes.
Change-Id: I00716024d6a0bdb68d6e2380c8cd7b5d056bd15f
Signed-off-by: trevd <trevd1234@gmail.com>
- adds a library to compute the SHA-256 hash
- updates the RSA verifier to take an argument specifying either SHA-1
or SHA-256
- updates DumpPublicKey to with new "key" version numbers for
specifying SHA-256
- adds new argument to adb auth code to maintain existing behavior
Change-Id: I5b1406cf57c2b8993f6032eda3e29139f7740839
adbd can receive multiple AUTH_RSAPUBLICKEY packets. This happens for
example when booting with usb attached when we retry authenticating
after the framework is done booting. Make sure usb_disconnect is only
registered once, otherwise this creates a loop in the disconnects list.
Bug: 8504991
Change-Id: Ia1f9a37005dd17b7eefee1493d622e1679263eea
Set the CAP_SYS_BOOT filesystem capability on the new reboot
command and keep CAP_SYS_BOOT in adb bounding set so that the
shell user can run it.
Change-Id: I1dd6143445ee2a952254f0452ab6e544318431dd
The adb sideload utility referes to the filename as 'sideload' in some
places. This patch changes the printouts to display the filename instead.
Change-Id: I38ada01a08bed53a8d9697c03f55ce8cee2abe12
Signed-off-by: Magnus Eriksson <eriksson.mag@gmail.com>
run-as: don't require CAP_DAC_OVERRIDE.
Prevent an adb spawned application from acquiring capabilities
other than
* CAP_NET_RAW
* CAP_SETUID
* CAP_SETGID
The only privileged programs accessible on user builds are
* /system/bin/ping
* /system/bin/run-as
and the capabilities above are sufficient to cover those
two programs.
If the kernel doesn't support file capabilities, we ignore
a prctl(PR_CAPBSET_DROP) failure. In a future CL, this could
become a fatal error.
Change-Id: I45a56712bfda35b5ad9378dde9e04ab062fe691a
When booting with usb attached, the secure adb authentication happens
long before the framework is done booting, so adb can't notify the
framework to install the public key.
Change-Id: Id2af6cebece345022f56cb0c4b5af24e1d7a425c
# By Ray Donnelly
# Via Android Git Automerger (2) and others
* commit '282caf3bd0dfd81b92ac74e0b3ea970d195fee7b':
Windows adb: include stdint.h for uint8_t on MinGW-w64
# By Ray Donnelly
# Via Android Git Automerger (2) and others
* commit '6c3d3ccfa5d1d77b80e5c7619909a48b976c69ec':
Windows adb: initialize on to 1 in disable_tcp_nagle
Add a new connection state, so that devices, that require confirmation
to allow adb, appear as "unauthorized" in the adb devices lists.
Change-Id: Ib4264bc5736dedecf05bcf8e31896f4d7a91fad8
The framework can now clear the user key list, so we need to reload the
key list on every auth request instead of loading it once when adbd
starts.
This also fixes issues with encrypted devices, where the user key file
is only readable after the user has unlocked the device.
Change-Id: I350c5aab986f8ca86b95f316398d03012553e581
There are serious multithreading issues between the fdevent and transport
subsystems which both manipulate struct asocket and struct fde concurrently.
The prevalent symptom being around multiple socket closures which stomp
on each other, typically causing:
"glibc detected *** adb: double free or corruption ..."
This HACK allows forcing CPU affinity via an env var. E.g.:
export ADB_CPU_AFFINITY_BUG6558362=0
which will cause ONLY the adb server and all its threads to be pegged
to CPU 0.
The result is visible in valgrind's helgrind: no *socket_close() related
data races. But tons of other races are still there.
Bug: 6558362
Change-Id: I0f112390a6a921c64b2a783297be9e99ce27fd56
