ADB Behavior

Problem Description

• The ADB client kills the server and starts a new one when it detects a version mismatch. Usually this is not needed because ADB is backward compatible and does not change much between Google releases.
• Users will (without knowing it) mix ADB versions. The typical scenario is manual use of a private version of ADB client in the terminal while AVE is using the version shipped by SWD Tools. The manual use kills the ADB server and thus all ongoing sessions.
• Handsets cannot be claimed by ADB server after a PC reboot due to permission problems if the server is started “too early” (whatever that means). Having a proper udev rule doesn’t help.
• The ADB server’s ability to claim the device (on USB level) after it has rebooted is higher when running the server as root. This is probably a variation of the problem with PC reboot.
• The ADB server does not daemonize correctly. If the server was started by the client, then the server may die immediately when the client returns. This causes a persistent error condition where all uses of the ADB client cause a server restart. If you were trying to use ADB socket forwarding, or waiting for a long-running shell command to complete, then this will be very noticable.

All of these can be addressed by running the ADB server as root. But that has its own problems:

If you really have to run a private version of ADB, all uses of the client will fail because the client can no longer kill the ADB server run by AVE.

What AVE Does

The ADB server is controlled by AVE through the program ave-adb-server. This wrapper is started by init and runs as root. It is configured to immediately kill off other ADB servers and start a new one if its own should terminate.

So, the owner of an AVE installation will find it difficult to stop the AVE controlled ADB server with adb kill-server. Of course, the client will try to do that for you if it detects a version mismatch. Then the error will look like this:

adb server is out of date.  killing...
cannot bind 'tcp:5037'
ADB server didn't ACK
* failed to start daemon *

Solution (well, sort of...)

• Stop the wrapper: sudo ave-adb-server --stop
• Stop the broker: ave-broker --stop

Stopping the broker is necessary because it continously polls connected devices with /usr/bin/adb. If no server is running when this happens, a new one is automatically started by the ADB client itself. This will conflict with any attempt to run a private version of ADB.

If you stop the wrapper but not the broker, you will see a message like this one before your command is evaluated:

adb server is out of date.  killing...

Closing Remarks

• Unfortunately there is no way to tell the client to not start a server if none was running. That would have made the problem a bit smaller as it would have given the user more control in the first place.
• There is also no way to tell the client to ignore version differences. That would also have helped.
• The stability problems listed under the problem description are sort of OK if you only make manual use of ADB with a very limited number of handsets. In larger setups with automation, this just doesn’t work.
• Regrettably the only currently known workaround is to run the ADB server as root. If there is a better way, please let us know!