Gitiles
Code Review Sign In
review.blissroms.org / platform_packages_modules_adb / c0aca05770cadc9520aa00ef7a835ffdbb2f0c44
commitc0aca05770cadc9520aa00ef7a835ffdbb2f0c44[log] [tgz]
authorShaju Mathew <shaju@google.com>Wed Aug 23 17:46:43 2023 -0700
committerShaju Mathew <shaju@google.com>Fri Sep 15 03:51:31 2023 +0000
tree696d89c64a57e3f228c06ab3ebb4ae949470d9bf
parentf78ea1a444c2220c831095ef11d2173220e4b0ae [diff]
wait_service() needs to handle wireless/remote device(s).
Currently, `adb wait-for-disconnect` returns (no-op) for non-USB.

Bug: 290267160

Test: For these tests, use the hotspot network (which will allow wireless
adb). Alternatively, a non-corp wireless network (with less stringent
security config) would also work out (tested with both these setups).

aosp-osx/aosp-master-with-phones$adb kill-server
aosp-osx/aosp-master-with-phones$adb devices
List of devices attached
35081FDJG001TR	device

aosp-osx/aosp-master-with-phones$adb tcpip 5555
restarting in TCP mode port: 5555
aosp-osx/aosp-master-with-phones$adb shell ifconfig | grep 'inet'
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope: Host
          inet6 addr: fe80::a47b:7bff:fefc:62bc/64 Scope: Link
          inet addr:10.0.0.101  Bcast:10.0.0.255  Mask:255.255.255.0
          inet6 addr: 2601:644:8e80:620:7fe:431:2c23:ecf3/64 Scope: Global
          inet6 addr: fe80::2040:22ff:feaa:8d09/64 Scope: Link
          inet6 addr: 2601:644:8e80:620:2040:22ff:feaa:8d09/64 Scope: Global
aosp-osx/aosp-master-with-phones$adb connect 10.0.0.101:5555
connected to 10.0.0.101:5555
aosp-osx/aosp-master-with-phones$adb devices
List of devices attached
35081FDJG001TR	device
10.0.0.101:5555	device

Test ambiguity:
aosp-osx/aosp-master-with-phones$adb  wait-for-disconnect
error: ambiguous: -s needs to be specified
Test disconnect of the wirelessly connected device - you can either
switch to 'Airplane Mode', disable Wifi on-device, or manually
disconnect from the network(on-device).
aosp-osx/aosp-master-with-phones$adb -s 10.0.0.101:5555  wait-for-disconnect
A noiceable delay is to be expected since the behavior of TCP/IP is to
expect polling (to detect disconnects).
Verify that the target device goes offline.
aosp-osx/aosp-master-with-phones$adb devices
List of devices attached
35081FDJG001TR	device
10.0.0.101:5555	offline

Test reconnect (when 'Airplane mode' is turned off, for e.g.):
aosp-osx/aosp-master-with-phones$adb devices
List of devices attached
35081FDJG001TR	device
10.0.0.101:5555	device

(Regression) Test wait-for-disconnect for the USB transport:
aosp-osx/aosp-master-with-phones$adb -s 35081FDJG001TR wait-for-disconnect
Disconnect USB device physically.
aosp-osx/aosp-master-with-phones$adb devices
List of devices attached
10.0.0.101:5555	device

Test wait-for-disconnect without a -s parameter:
Since there is only one (wirelessly connected) active transport, the -s param is not needed.
aosp-osx/aosp-master-with-phones$adb  wait-for-disconnect
aosp-osx/aosp-master-with-phones$adb devices
List of devices attached
10.0.0.101:5555	offline

Test reinstatement to kCsDevice (from offline) mode:
Turn wifi on (or 'Airplane mode' off) on-device.
aosp-osx/aosp-master-with-phones$adb devices
List of devices attached
10.0.0.101:5555	device

Test disconnect from a secondary terminal:
For this, run `adb disconnect 10.0.0.101:5555` from an other terminal
(make sure `adb wait-for-disconnect` below is launched first).
aosp-osx/aosp-master-with-phones$adb  wait-for-disconnect
aosp-osx/aosp-master-with-phones$adb devices
List of devices attached

Change-Id: I3c94dafb8a2a5769c73416e8a3eba45ce53959f0
1 file changed
tree: 696d89c64a57e3f228c06ab3ebb4ae949470d9bf
  1. apex/
  2. client/
  3. coverage/
  4. crypto/
  5. daemon/
  6. docs/
  7. fastdeploy/
  8. fdevent/
  9. libs/
  10. pairing_auth/
  11. pairing_connection/
  12. proto/
  13. sysdeps/
  14. test_utils/
  15. tls/
  16. tools/
  17. .clang-format
  18. adb.bash
  19. adb.cpp
  20. adb.h
  21. adb_auth.h
  22. adb_integration_test_adb.xml
  23. adb_integration_test_device.xml
  24. adb_io.cpp
  25. adb_io.h
  26. adb_io_test.cpp
  27. adb_listeners.cpp
  28. adb_listeners.h
  29. adb_listeners_test.cpp
  30. adb_mdns.cpp
  31. adb_mdns.h
  32. adb_trace.cpp
  33. adb_trace.h
  34. adb_unique_fd.cpp
  35. adb_unique_fd.h
  36. adb_utils.cpp
  37. adb_utils.h
  38. adb_utils_test.cpp
  39. adb_wifi.h
  40. adbd_test.xml
  41. Android.bp
  42. benchmark_device.py
  43. bugreport_test.cpp
  44. compression_utils.h
  45. file_sync_protocol.h
  46. mdns_test.cpp
  47. MODULE_LICENSE_APACHE2
  48. NOTICE
  49. OVERVIEW.TXT
  50. OWNERS
  51. PREUPLOAD.cfg
  52. protocol.txt
  53. README.md
  54. security_log_tags.h
  55. services.cpp
  56. services.h
  57. SERVICES.TXT
  58. shell_protocol.h
  59. shell_service_protocol.cpp
  60. shell_service_protocol_test.cpp
  61. SOCKET-ACTIVATION.txt
  62. socket.h
  63. socket_spec.cpp
  64. socket_spec.h
  65. socket_spec_test.cpp
  66. socket_test.cpp
  67. sockets.cpp
  68. sockets.dia
  69. SYNC.TXT
  70. sysdeps.h
  71. sysdeps_test.cpp
  72. sysdeps_unix.cpp
  73. sysdeps_win32.cpp
  74. sysdeps_win32_test.cpp
  75. test_adb.py
  76. test_device.py
  77. TEST_MAPPING
  78. trace.sh
  79. transfer_id.h
  80. transport.cpp
  81. transport.h
  82. transport_benchmark.cpp
  83. transport_fd.cpp
  84. transport_test.cpp
  85. types.cpp
  86. types.h
  87. types_test.cpp
README.md

ADB Internals

If you are new to adb source code, you should start by reading OVERVIEW.TXT which describes the three components of adb pipeline.

This document is here to boost what can be achieved within a "window of naive interest". You will not find function or class documentation here but rather the "big picture" which should allow you to build a mental map to help navigate the code.

Three components of adb pipeline

As outlined in the overview, this codebase generates three components (Client, Server (a.k.a Host), and Daemon (a.k.a adbd)). The central part is the Server which runs on the Host computer. On one side the Server exposes a "Smart Socket" to Clients such as adb or DDMLIB. On the other side, the Server continuously monitors for connecting Daemons (as USB devices or TCP emulator). Communication with a device is done with a Transport.

+----------+              +------------------------+
|   ADB    +----------+   |      ADB SERVER        |                   +----------+
|  CLIENT  |          |   |                        |              (USB)|   ADBD   |
+----------+          |   |                     Transport+-------------+ (DEVICE) |
                      |   |                        |                   +----------+
+-----------          |   |                        |
|   ADB    |          v   +                        |                   +----------+
|  CLIENT  +--------->SmartSocket                  |              (USB)|   ADBD   |
+----------+          ^   | (TCP/IP)            Transport+-------------+ (DEVICE) |
                      |   |                        |                   +----------+
+----------+          |   |                        |
|  DDMLIB  |          |   |                     Transport+--+          +----------+
|  CLIENT  +----------+   |                        |        |  (TCP/IP)|   ADBD   |
+----------+              +------------------------+        +----------|(EMULATOR)|
                                                                       +----------+

The Client and the Server are contained in the same executable and both run on the Host machine. Code sections specific to the Host is enclosed within ADB_HOST guard. adbd runs on the Android Device. Daemon specific code is enclosed in !ADB_HOST but also sometimes with-in __ANDROID__ guard.

"SMART SOCKET" and TRANSPORT

A smart socket is a simple TCP socket with a smart protocol built on top of it. This is what Clients connect onto from the Host side. The Client must always initiate communication via a human readable request but the response format varies. The smart protocol is documented in SERVICES.TXT.

On the other side, the Server communicates with a device via a Transport. adb initially targeted devices connecting over USB, which is restricted to a fixed number of data streams. Therefore, adb multiplexes multiple byte streams over a single pipe via Transport. When devices connecting over other mechanisms (e.g. emulators over TCP) were introduced, the existing transport protocol was maintained.

THREADING MODEL and FDEVENT system

At the heart of both the Server and Daemon is a main thread running an fdevent loop, which is a platform-independent abstraction over poll/epoll/WSAPoll monitoring file descriptors events. Requests and services are usually served from the main thread but some service requests result in new threads being spawned.

To allow for operations to run on the Main thread, fdevent features a RunQueue combined with an interrupt fd to force polling to return.

+------------+    +-------------------------^
|  RUNQUEUE  |    |                         |
+------------+    |  POLLING (Main thread)  |
| Function<> |    |                         |
+------------+    |                         |
| Function<> |    ^-^-------^-------^------^^
+------------+      |       |       |       |
|    ...     |      |       |       |       |
+------------+      |       |       |       |
|            |      |       |       |       |
|============|      |       |       |       |
|Interrupt fd+------+  +----+  +----+  +----+
+------------+         fd      Socket  Pipe

ASOCKET, APACKET, and AMESSAGE

The asocket, apacket, and amessage constructs exist only to wrap data while it transits on a Transport. An asocket handles a stream of apackets. An apacket consists in a amessage header featuring a command (A_SYNC, A_OPEN, A_CLSE, A_WRTE, A_OKAY, ...) followed by a payload (find more documentation in protocol.txt. There is no A_READ command because an asocket is unidirectional. To model a bi-directional stream, asocket have a peer which go in the opposite direction.

An asocket features a buffer where the elemental unit is an apacket. If traffic is inbound, the buffer stores the apacket until it is consumed. If the traffic is oubound, the buffer stores apackets until they are sent down the wire (with A_WRTE commands).

+---------------------ASocket------------------------+
 |                                                   |
 | +----------------APacket Queue------------------+ |
 | |                                               | |
 | |            APacket     APacket     APacket    | |
 | |          +--------+  +--------+  +--------+   | |
 | |          |AMessage|  |AMessage|  |AMessage|   | |
 | |          +--------+  +--------+  +--------+   | |
 | |          |        |  |        |  |        |   | |
 | |  .....   |        |  |        |  |        |   | |
 | |          |  Data  |  |  Data  |  |  Data  |   | |
 | |          |        |  |        |  |        |   | |
 | |          |        |  |        |  |        |   | |
 | |          +--------+  +--------+  +--------+   | |
 | |                                               | |
 | +-----------------------------------------------+ |
 +---------------------------------------------------+

This system allows to multiplex data streams on an unique byte stream. Without entering too much into details, the amessage fields arg1 and arg2 are used alike in the TCP protocol where local and remote ports identify an unique stream. Note that unlike TCP which feature an "unacknowledged-send window", an apacket is sent only after the previous one has been confirmed to be received.

The two types of asocket (Remote and Local) differentiate between outbound and inbound traffic.

adbd <-> APPPLICATION communication

This pipeline is detailed in daemon/jdwp_service.cpp with ASCII drawings! The JDWP extension implemented by Dalvik/ART are documented in:

  • platform/dalvik/+/master/docs/debugmon.html
  • platform/dalvik/+/master/docs/debugger.html