Saturday, May 14, 2011

An alternative to the Android emulator and setting up ADB for TCP.

[Update 7/28/11 :See updated information at the end of this post]

I touched on it in my last post, but Android x86 running on Virtual Box can often (but not always) perform better than the standard Android emulator. OpenGL is painfully slow on either. I'm running one of their pre-built Froyo binaries, but Gingerbread source is on the site, if you're feeling adventurous.

The main advantages are:

  • it starts up faster
  • less prone to lockups the the SDK emulator
  • it depends somewhat on what you're app is doing, but many things, like file system IO and math intensive code, seem to execute much faster
The main disadvantages are:
  • Not very representative of a "main stream" Android device.
  • Cant be used if you're using NDK with native code targeting the Arm processor.
  • Configuration of things like screen dpi, and emulated hardware is not as easy or non existent.
  • You can't emulate certain operations like SMS
A guide to setting up your x86 virtual machine can found here: (It takes less than 10 minutes) Install Android Froyo on PC

Launching Android-x86 is not automated like the emulator and ADB takes slightly more effort to setup, but it's not hard. So here's my quick-start guide

Steps to get ADB working over TCP/IP on Windows

Step 1: Find the IP address of your Android device. 

We need to know what IP address to point ADB to. Unless you have set up your Android-x86 to have a static IP, you'll have to dig a little to find out what it is.

Open the "Dev Tools" app and run the terminal terminal emulator.

You should see a blue shell window. 
su <enter>
ifconfig eth0 <enter>

The output of the ifconfig command should give you the IP address of your device. 

Remember that ip address.

Step 2: connecting ADB

Open a DOS box.
(Note this assumes that the Android sdk is in your DOS path, if not you must type the full path to adb.exe)
adb kill-server <enter>
adb connect <enter>

where is your device's IP address from step one.

To verify it is working, try typing:

adb shell <enter>

If it's working you should get a "#" prompt.

And there you have it.


[Update 7/28/11]

I am working on switching Sedition to use OpenGL ES 2.0 with programmable pipeline support. OpenGL  ES 2.0 is not supported as of this writing in the Andorid emulator supplied with the SDK. The Android-x86 website claims that the latest version (2.2 r2) supports OpenGL ES 2.0. Sedition has never run fast on the emulator, but it run well enough(4-5 frames per second) to test some of the features. I discovered soon enough that when you configure your app for 2.0, it fails to create a render surface on the emulator. I'll make a new post and update this one once I get the latest Android-x86  up and running.

[Update 7/30/11]

I tried x86 Android 2.2 r2 under Virtual Box, and with a few quick tests, it does not appear to support OpenGL ES 2.0. I get the configChooser "no configs match configSpec" exception  when I try to create the GL render surface, which is exactly what the SDK's emulator gives me. I guess I'm developing on real devices for the foreseeable future. Android x86 no longed provides a "generic" iso, so I tried the "eepc" build. It may be that another build has better GL hardware support.


  1. hi Pedantite, I followed all step but when I run AVD manager, I found that it's not shown it devices list.
    But when I run adb devices from command line, it's listed as connected device

  2. @Winds:
    (sorry for the late response, I was on vacation, and I must have overlooked somehow that I had your comment in the moderation queue)

    If it's listed under the adb devices command, that should mean it's working. The AVD manager is only for the SDK-supplied emulator. For all intents and purposes, the SDK thinks this alternative emulator is a real device, not an emulated one. If you switch Eclipse to the "DDMS" perspective, you should see your x86 device listed.

  3. Any success with OpenGL ES?

  4. Since posting this, I've acquired several Android devices, so I haven't tried to run on the emulator lately. My uneducated guess is that Google probably feels that developers who want to do a lot of opengl development are going to use physical devices. Emulating a mobile device programmable graphics pipeline on a (wide array) of desktop computers at a reasonable speed just might be a pipe dream.


I welcome you're thoughts. Keep it classy, think of the children.