Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-26930

Emulator fails to start with bogus error message

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • None
    • Ubuntu 12.04 x64, tomcat 7, java 7 x64

      When running a build from Jenkins, with a x86_64 ABI of android-21, it fails to start with the following error:

      [android] Starting Android emulator and creating initial snapshot
      [android] Erasing existing emulator data...
      $ /opt/android-sdk/tools/emulator -no-boot-anim -ports 5799,5800 -prop persist.sys.language=en -prop persist.sys.country=US -avd hudson_en-US_320_WVGA_android-21_x86-64 -no-snapshot-load -no-snapshot-save -wipe-data -no-window
      ERROR: 32-bit Linux Android emulator binaries are DEPRECATED, to use them
      you will have to do at least one of the following:

      • Use the '-force-32bit' option when invoking 'emulator'.
      • Set ANDROID_EMULATOR_FORCE_32BIT to 'true' in your environment.

      Either one will allow you to use the 32-bit binaries, but please be
      aware that these will disappear in a future Android SDK release.
      Consider moving to a 64-bit Linux system before that happens.

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

      Which is completely bogus, since:

      • it's a 64 bit box:

        $ uname -m
        x86_64

      • using 64-bit Java:

        $ java -version
        java version "1.7.0_60"
        Java(TM) SE Runtime Environment (build 1.7.0_60-b19)
        Java HotSpot(TM) 64-Bit Server VM (build 24.60-b09, mixed mode)

      And running the same command from cli works just fine

      HOME=. /opt/android-sdk/tools/emulator -no-boot-anim -ports 5799,5800 -prop persist.sys.language=en -prop persist.sys.country=US -avd hudson_en-US_320_WVGA_android-21_x86-64 -no-snapshot-load -no-snapshot-save -wipe-data -no-window
      Creating filesystem with parameters:
      Size: 69206016
      Block size: 4096
      Blocks per group: 32768
      Inodes per group: 4224
      Inode size: 256
      Journal blocks: 1024
      Label:
      Blocks: 16896
      Block groups: 1
      Reserved block group size: 7
      Created filesystem with 11/4224 inodes and 1302/16896 blocks
      Failed to Initialize backend EGL display
      emulator: WARNING: Could not initialize OpenglES emulation, using software renderer.
      emulator: warning: opening audio output failed

          [JENKINS-26930] Emulator fails to start with bogus error message

          Hmm. I couldn't reproduce this with the newest SDK tools on my Ubuntu 14.04 x86_64 machine (nor in a Docker image with Ubuntu 12.04), but it's strange that you get a different result on the command line.

          In the command line version, are you running as the same user that Jenkins is running under?

          Does the same happen if you run a Jenkins job, where you manually run the emulator command via a "Execute shell script" build step?

          Is there anything weird in the build's environment, e.g. env variables injected globally in Jenkins (or on that particular build slave)? Probably you can see this by running env in an execute shell build step.

          Christopher Orr added a comment - Hmm. I couldn't reproduce this with the newest SDK tools on my Ubuntu 14.04 x86_64 machine (nor in a Docker image with Ubuntu 12.04), but it's strange that you get a different result on the command line. In the command line version, are you running as the same user that Jenkins is running under? Does the same happen if you run a Jenkins job, where you manually run the emulator command via a "Execute shell script" build step? Is there anything weird in the build's environment, e.g. env variables injected globally in Jenkins (or on that particular build slave)? Probably you can see this by running env in an execute shell build step.

          Juan Sotuyo added a comment -

          Tomcat is running under that very same Java version that I showed.

          Yes, the output shown for CLI is under the tomcat7 user after using

          sudo su tomcat7 -

          so the environment is the same.

          I'll try and check to run the emulator manually and let you know.

          The only manually injected variables are, HOME (pointing to JENKINS_HOME) & PATH, both configured globally; and for that specific build ANDROID_EMULATOR_FORCE_32BIT as a work around for this issue on the meantime.

          I do get the same error running the emulator manually from Tomcat though.. yet I'm not sure why Tomcat consistently believes to be on a 32 bit machine...

          Juan Sotuyo added a comment - Tomcat is running under that very same Java version that I showed. Yes, the output shown for CLI is under the tomcat7 user after using sudo su tomcat7 - so the environment is the same. I'll try and check to run the emulator manually and let you know. The only manually injected variables are, HOME (pointing to JENKINS_HOME) & PATH, both configured globally; and for that specific build ANDROID_EMULATOR_FORCE_32BIT as a work around for this issue on the meantime. I do get the same error running the emulator manually from Tomcat though.. yet I'm not sure why Tomcat consistently believes to be on a 32 bit machine...

          Karim Varela added a comment -

          Is there a workaround for this? It's currently blocking me from running unit tests. I'm on Linux 3.13.0-45-generic x86_64.

          Tried to run emulator I created w/ the following command:
          android create avd -f -a -s 1080x1920 -n hudson_en-US_320_1080x1920_android-22_x86_64 -t android-22 --abi x86_64

          java -version
          Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)

          Karim Varela added a comment - Is there a workaround for this? It's currently blocking me from running unit tests. I'm on Linux 3.13.0-45-generic x86_64. Tried to run emulator I created w/ the following command: android create avd -f -a -s 1080x1920 -n hudson_en-US_320_1080x1920_android-22_x86_64 -t android-22 --abi x86_64 java -version Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)

          The problem seems to be the missing SHELL environment variable. You can see code of the bitness check of the emulator here:

          https://android.googlesource.com/platform/external/qemu/+/ee57375c96822790cc7f837b4fdf64a9c1d69b3a/android/utils/host_bitness.c

          As you can see, it tries to execute the following command:
          file -L "$SHELL" | grep -q "x86[_-]64"
          which fails because of the missing SHELL variable.

          A quick workaround is to define the environment variable in the global jenkins configuration as key "SHELL" with value "/bin/bash"

          Christoph Kaser added a comment - The problem seems to be the missing SHELL environment variable. You can see code of the bitness check of the emulator here: https://android.googlesource.com/platform/external/qemu/+/ee57375c96822790cc7f837b4fdf64a9c1d69b3a/android/utils/host_bitness.c As you can see, it tries to execute the following command: file -L "$SHELL" | grep -q "x86 [_-] 64" which fails because of the missing SHELL variable. A quick workaround is to define the environment variable in the global jenkins configuration as key "SHELL" with value "/bin/bash"

          Thomas Keller added a comment -

          I'm on an Jenkins Docker instance here (based on the non-alpine, Debian 8-based https://hub.docker.com/_/jenkins/).

          When I try to execute $ANDROID_HOME/tools/emulator, I get "No such file or directory", because no ia32 libs have been installed yet.

          If I do that via

          dpkg --add-architecture i386
          apt-get update
          apt-get install libc6:i386 libstdc++6:i386
          

          and then execute $ANDROID_HOME/tools/emulator again, I receive the said error

          ERROR: 32-bit Linux Android emulator binaries are DEPRECATED, to use them
                 you will have to do at least one of the following:
          
                 - Use the '-force-32bit' option when invoking 'emulator'.
                 - Set ANDROID_EMULATOR_FORCE_32BIT to 'true' in your environment.
          
                 Either one will allow you to use the 32-bit binaries, but please be
                 aware that these will disappear in a future Android SDK release.
                 Consider moving to a 64-bit Linux system before that happens.
          

          $SHELL is set on this instance (to /bin/bash), so the x64 check should go through, but I really wonder why the Android Tools team hasn't packaged an emulator64 binary, but only individual emulator executables for different emulation targets, but at the same time deprecated the 32bit emulator with this warning...

          Currently I'm exporting ANDROID_EMULATOR_FORCE_32BIT=true in my global environment to get around this issue.

          Thomas Keller added a comment - I'm on an Jenkins Docker instance here (based on the non-alpine, Debian 8-based https://hub.docker.com/_/jenkins/ ). When I try to execute $ANDROID_HOME/tools/emulator , I get "No such file or directory", because no ia32 libs have been installed yet. If I do that via dpkg --add-architecture i386 apt-get update apt-get install libc6:i386 libstdc++6:i386 and then execute $ANDROID_HOME/tools/emulator again, I receive the said error ERROR: 32-bit Linux Android emulator binaries are DEPRECATED, to use them you will have to do at least one of the following: - Use the '-force-32bit' option when invoking 'emulator' . - Set ANDROID_EMULATOR_FORCE_32BIT to ' true ' in your environment. Either one will allow you to use the 32-bit binaries, but please be aware that these will disappear in a future Android SDK release. Consider moving to a 64-bit Linux system before that happens. $SHELL is set on this instance (to /bin/bash ), so the x64 check should go through, but I really wonder why the Android Tools team hasn't packaged an emulator64 binary, but only individual emulator executables for different emulation targets, but at the same time deprecated the 32bit emulator with this warning... Currently I'm exporting ANDROID_EMULATOR_FORCE_32BIT=true in my global environment to get around this issue.

          Pedro Melo added a comment - - edited

          Same issue here but I moved a bit further along. You can use $ANDROID_HOME/emulator/emulator and bypass the (for some reason) broken 32bit test. If you use that emulator, I get this error message:

          emulator: ERROR: This AVD's configuration is missing a kernel file! Please ensure the file "kernel-ranchu" is in the same location as your system image.

           Apparently android-25 arm64 system images are missing the kernel-ranchu files, they are present on android-24.

          I still would like to know what is the problem with the 32-bit check though...

           

          Edit: for context - using Android SDK 7.1.1 inside a Docker container for build and automated tests

          Pedro Melo added a comment - - edited Same issue here but I moved a bit further along. You can use $ANDROID_HOME/emulator/emulator and bypass the (for some reason) broken 32bit test. If you use that emulator , I get this error message: emulator: ERROR: This AVD's configuration is missing a kernel file! Please ensure the file "kernel-ranchu" is in the same location as your system image.  Apparently android-25 arm64 system images are missing the kernel-ranchu files, they are present on android-24. I still would like to know what is the problem with the 32-bit check though...   Edit: for context - using Android SDK 7.1.1 inside a Docker container for build and automated tests

            Unassigned Unassigned
            jsotuyod Juan Sotuyo
            Votes:
            1 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated: