I would like to see, what ADB commands a Windows program is sending to my Android phone, to see how its functions operate.
Add a comment
|
2 Answers
ADB is a combination of three components: 1
- A client, which sends commands. The client runs on your development machine. You can invoke a client from a command-line terminal by issuing an adb command.
- A daemon (adbd), which runs commands on a device. The daemon runs as a background process on each device.
- A server, which manages communication between the client and the daemon. The server runs as a background process on your development machine.
Capture local TCP traffic
So you have multiple possibilities to capture ADB traffic. The easiest way would be to capture the TCP data sent from adb client to the server. Both are running by default on your computer on your user account, so they simply communicate via localhost (as far as I know not protected in any way). That communication can therefore be sniffed using Wireshark. I am not sure if Wireshark already contains a dissector for adb client-server communication (or at least there are third party dissectors available of adb traffic) but even if not you should see the commands in plain text in the traffic and you can execute sample commands where you exactly know the command to learn how such packets do look alike.
Capture USB traffic
The second way would be to capture the USB traffic. How that can be done depends on the used OS, but as far as I know there should be a possibility on each of the major OS (Windows, Linux, MacOS).
Capture used adb command-line
A third way (if the program that sends adb command executes commands using adb client, you could monitor the created processes and their command-line. On Windows you you for example use Sysinternals Process Monitor to monitor all process creation and their command-line.
In addition to the solutions that @Robert provided, one of the simplest ways to see adb logs is to use the command adb logcat.
Logcat is a command-line tool that dumps a log of system messages, including stack traces when the device throws an error and messages that you have written from your app with the Log class.
