Same issue, this workaround helped,but in my case i know how to solve this problem without this workaround. I just installed xvnc plugin and check "Run Xvnc during build" in job and that helped.
Maybe new emulator needs x session.

Debian 6 x64,
Jenkins ver. 1.466.2,
SDK 20.0.3

I also have this issue and was able to get the plugin to recognize the launched plugin by renaming emulator-arm to emulator

I have this issue intermittently even after linking emulator to emulator-arm. The emulator processes keep piling up because the plugin does not kill them after unsuccessfully trying to connect to them.
I have tried to fix the issue by building a private version of the plugin with setting the ignore variable to true even for UNIX but it did not help.
My environment is Xen Linux 3.2.0-3-amd64 #1 SMP 86_64 Debian GNU/Linux wheezy/sid.
One problem I have had is that the emulator does not always get the display started by the xvnc plugin right because you cannot specify the display that the xvnc plugin starts.

Building remotely on madmax2 in workspace /var/lib/jenkins/projects/avt/tests
Starting xvnc
[tests] $ vncserver :11 -localhost -nolisten tcp

New 'X' desktop is madmax2.ecolane.com:11

Starting applications specified in /var/lib/jenkins/.vnc/xstartup
Log file is /var/lib/jenkins/.vnc/madmax2.ecolane.com:11.log

[android] Using Android SDK: /opt/adt-bundle-linux-x86_64/sdk
[android] Waiting 1 seconds before starting emulator...
$ /opt/adt-bundle-linux-x86_64/sdk/platform-tools/adb start-server
[android] Starting Android emulator
$ /opt/adt-bundle-linux-x86_64/sdk/tools/emulator -no-boot-anim -ports 56341,34347 -avd Android2.2GoogleAPIs -no-snapshot-load -no-snapshot-save

• daemon not running. starting it now on port 50229 *
• daemon started successfully *
  [android] Emulator did not appear to start; giving up
  $ /opt/adt-bundle-linux-x86_64/sdk/platform-tools/adb disconnect localhost:34347
  [android] Stopping Android emulator
  $ /opt/adt-bundle-linux-x86_64/sdk/platform-tools/adb kill-server
  Taking screenshot.
  [tests] $ import -window root -display :11 screenshot.jpg
  Terminating xvnc.
  $ vncserver -kill :11
  Killing Xtightvnc process ID 18436

We were having this precise issue. As indicated by this stackoverflow thread, we fixed the issue by setting the LD_LIBRARY_PATH as follows (using EnvInject):

LD_LIBRARY_PATH=/opt/android/android-sdk-linux/tool/lib

I think the fix is for the Android Emulator plugin to populate this for us?

Code changed in jenkins
User: Nicolas De Loof
Path:
src/main/java/hudson/plugins/android_emulator/AndroidEmulatorContext.java
http://jenkins-ci.org/commit/android-emulator-plugin/c96a6d0d7c7744bc7836f25047d0fb23a3ed827a
Log:
JENKINS-14901 set LD_LIBRARY_PATH for emulator to run on 64bit linux

I just discovered the pull request from Nicolas (and fixed my GitHub notification settings)...

I guess this shouldn't have any adverse affects on non-Linux systems, but I'll try and give it a quick test before the next release.
Have you guys managed to test this patch on other systems at all?

The pull request code did not work for me but I got the following error:

Starting xvnc
[tests] $ vncserver :10 -localhost -nolisten tcp

New 'X' desktop is madmax2.ecolane.com:10

Starting applications specified in /var/lib/jenkins/.vnc/xstartup
Log file is /var/lib/jenkins/.vnc/madmax2.ecolane.com:10.log

[android] Using Android SDK: /opt/adt-bundle-linux-x86_64/sdk
[android] Waiting 30 seconds before starting emulator...
$ /opt/adt-bundle-linux-x86_64/sdk/platform-tools/adb start-server
[android] Starting Android emulator
$ /opt/adt-bundle-linux-x86_64/sdk/tools/emulator -no-boot-anim -ports 32988,58093 -avd Android2.3GoogleAPIs -no-snapshot-load -no-snapshot-save
SDL init failure, reason is: No available video device

• daemon not running. starting it now on port 5037 *
• daemon started successfully *

[android] Emulator did not appear to start; giving up

Adding the -noaudio emulator option fixed this for me

Seems to be fixed since the patch above was merged.
Other bugs appear to be due to the emulator binary (i.e. out of our control), for which there are workarounds noted above (different emulator binaries, or emulator flags).

Marking old "resolved" issues as "closed".