Using a Linux android emulator server

Situation: You have a fast lots-of-memory Linux desktop box (perhaps remote) to run your Android emulators on and a desktop machine running your IDE.  How best to debug remotely?
SSH port-forwarding instructions for Windows (and others) after the break.

So ideally one could tell the emulator to listen for connections on a non-localhost address but convincing the emulator to do this seems hard (*A).  Instead, use good old SSH port tunnelling to solve it for you!


Tell your local SSH to forward local connections to 5555 to your Linux server's 5555 (or better, forward local 5559 to remote 5555 so you can still use local emulators on 5555) .  Since most Windows users are likely using PuTTY, this is done by...

1. editing the settings
1. either for your stored connection
2. or via "System Menu | Change settings..."
2. select "Connection | SSH | Tunnels"
3. under "Add new forwarded port:" populate as follows:
1. Source port: 5559
2. Destination: localhost:5555
4. Hit "Add"
5. [If  updating a saved profile, don't forget to go save it!]

Once done, you need to tell local ADB to connect to the new tunnel.  Run command-line (either <WINDOWS-R> or in a DOS box)...

adb connect :5559

...and you should be set.  "adb devices" and "adb logcat -d" should show devices and remote logs respectively and Eclipse's DDMS view (etc) should now show logging from the Linux-based Android emulator.  (if not, try "adb kill-server" then "adb connect :5559" again.)

HTH!

*A: The CLI provides for changing the port (with -port!) but not to specify which address (interface) to bind to.  Obviously, if one can rearrange the default interface, this would likely work.  The downsides: that requires root powers and would likely be inadvisable since it'd probably mess with your Linux box's efficiency (since it'd likely route many more packets via full ethernet stack rathern their being sent much faster purely over loopback).  Better, we update the emulator code to provide an extra argument to supply bind interface (or somesuch).

p.s. I can supply SSH CLI instructions but I'm sure anyone on CLI knows how to use man(1) ;-)