| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rename the existing Connection to BlockingConnection, add a nonblocking
Connection, and add an adapter between the two, to enable future work
to reduce the impedance mismatch from implementing a blocking interface
on top of nonblocking primitives.
While we're here, delete A_SYNC, and remove one layer of pipes when
sending a packet (replacing it with a condition variable when using
BlockingConnectionAdapter).
Test: python test_device.py, manually plugging/unplugging devices
Change-Id: Ieac2bf937471d9d494075575f07e53b589aba20a
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Try to improve the documentation by adding, for each commands explained
on the adb/protocol.txt file (CONNECT, WRITE, AUTH, ...), the
corresponding constant used by the protocol (A_CNXN, A_WRTE,
A_AUTH, ...).
I've seen a few engineers having problems matching these both
information by simply reading the doc and they loose time before
getting it. Most of the time they understand it by finally reading the
source code.
By adding this simple information at the end of each command
description I'm sure it will help onboarding developers to
understand more quickly the way the ADB protocol works.
Change-Id: Ibb949fd6a6d34a2bc7f47f0e7af2f57138c9a369
Signed-off-by: Eyal Lezmy <eyal.lezmy@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The reason behing this change is to increase the adb push/pull speed
with reduceing the number of packets sent between the host and the
device because the communication is heavily bound by packet latency.
The change maintains two way compatibility in the communication
protocol with negotiating a packet size between the target and the
host with the CONNECT packets.
After this change the push/pull speeds improved significantly
(measured from Linux-x86_64 with 100MB of data):
| Old push | Old pull || New push | New pull |
-----------------------------------------------------------
Hammerhead | 4.6 MB/s | 3.9 MB/s || 13.1 MB/s | 16.5 MB/s |
-----------------------------------------------------------
Volantis | 6.0 MB/s | 6.2 MS/s || 25.9 MB/s | 29.0 MB/s |
-----------------------------------------------------------
Fugu | 6.0 MB/s | 5.1 MB/s || 27.9 MB/s | 33.2 MB/s |
-----------------------------------------------------------
Change-Id: Id9625de31266e43394289e325c7e7e473379c5d8
|
| |
|
|
|
|
|
|
|
| |
Prior to the documentation told users to pass 0 in as
the first argument to write messages, when they should
be outting in their local-id. It is now corrected.
Change-Id: Ia2c6c84f95383baa5ca471493a29a39e5173b604
Signed-off-by: Derrick Bonafilia <dbonafilia@google.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Secure adb using a public key authentication, to allow USB debugging
only from authorized hosts.
When a device is connected to an unauthorized host, the adb daemon sends
the user public key to the device. A popup is shown to ask the user to
allow debugging once or permanantly from the host. The public key is
installed on the device in the later case. Other keys may be installed
at build time.
On the host, the user public/private key pair is automatically generated,
if it does not exist, when the adb daemon starts and is stored in
$HOME/.android/adb_key(.pub) or in $ANDROID_SDK_HOME on windows. If needed,
the ADB_KEYS_PATH env variable may be set to a :-separated (; under
Windows) list of private keys, e.g. company-wide or vendor keys.
On the device, vendors public keys are installed at build time in
/adb_keys. User-installed keys are stored in /data/misc/adb/adb_keys.
ADB Protocol change:
If the device needs to authenticate the host, it replies to CNXN
packets with an AUTH packet. The AUTH packet payload is a random token.
The host signs the token with one of its private keys and sends an AUTH(0)
packet. If the signature verification succeeds, the device replies with
a CNXN packet. Otherwise, it sends a new AUTH packet with a new token so
that the host can retry with another private key. Once the host has tried
all its keys, it can send an AUTH(1) packet with a public key as
payload. adbd then sends the public key to the framework (if it has been
started) for confirmation.
Change-Id: I4e84d7621da956f66ff657245901bdaefead8395
|
| |
|
|
| |
This reverts commit f4ed516643ee8ed3a59ad1a8048f7ce5f47f93fb.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Secure adb using a public key authentication, to allow USB debugging
only from authorized hosts.
When a device is connected to an unauthorized host, the adb daemon sends
the user public key to the device. A popup is shown to ask the user to
allow debugging once or permanantly from the host. The public key is
installed on the device in the later case. Other keys may be installed
at build time.
On the host, the user public/private key pair is automatically generated,
if it does not exist, when the adb daemon starts and is stored in
$HOME/.android/adb_key(.pub) or in $ANDROID_SDK_HOME on windows. If needed,
the ADB_KEYS_PATH env variable may be set to a ;-separated list of private
keys, e.g. company-wide or vendor keys.
On the device, vendors public keys are installed at build time in
/adb_keys. User-installed keys are stored in /data/misc/adb/adb_keys.
ADB Protocol change:
If the device needs to authenticate the host, it replies to CNXN
packets with an AUTH packet. The AUTH packet payload is a random token.
The host signs the token with one of its private keys and sends an AUTH(0)
packet. If the signature verification succeeds, the device replies with
a CNXN packet. Otherwise, it sends a new AUTH packet with a new token so
that the host can retry with another private key. Once the host has tried
all its keys, it can send an AUTH(1) packet with a public key as
payload. adbd then sends the public key to the framework (if it has been
started) for confirmation.
Change-Id: Idce931a7bfe4ce878428eaa47838e5184ac6073f
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
protocol.txt says that the connect message should have three
fields:
<systemtype>:<serialno>:<banner>
In reality, what is transmitted is simply:
<systemtype>::
The serialno is obtained via other means so doesn't really need
to be a part of the connect message. This change puts the
ro.product.name, ro.product.model and ro.product.device
properties in the <banner> for devices. Each property is
terminated by a semicolon (;) with the key and value separated by
an equals sign (=). Example message:
device::ro.product.name=<prd>;ro.product.model=<mdl>;ro.product.device=<dev>;
Making this change will enable the device list to provide more
information to the user and to give the potential for being able
to select which device to talk to with the -s option.
Change-Id: I09200decde4facb8fc9b4056fdae910155f2bcb9
Signed-off-by: Scott Anderson <saa@android.com>
|
| | |
|
| | |
|
| | |
|
| |
|
