Skip to main content

Slow Android emulator


I have a 2.67 GHz Celeron processor, 1.21 GB of RAM on a x86 Windows XP Professional machine. My understanding is that the Android emulator should start fairly quickly on such a machine, but for me it does not. I have followed all instructions in setting up the IDE, SDKs, JDKs and such and have had some success in staring the emulator quickly but is very particulary. How can I, if possible, fix this problem?



Even if it starts and loads the home screen, it is very sluggish. I have tried the Eclipse IDE in Galileos, and Ganymede.


Source: Tips4allCCNA FINAL EXAM

Comments

  1. Android Development Tools (ADT) 9.0.0 (or later) has a feature that allows you to save state of the AVD (emulator) and you can start your emulator instantly. You have to enable this feature while creating a new AVD or you can just create it later by editing the AVD.

    Also I have increased the Device RAM Size to 1024 which results in very fast emulator.

    Refer the given below screenshots for more information.


    Creating a new AVD with the save snapshot feature.





    Launching the emulator from the snapshot.

    ReplyDelete
  2. Try Android x86. It works much more faster than the Google Android emulator. Follow these steps:


    Install VirtualBox.
    Download the ISO file that you need
    Create a virtual machine as Linux 2.6/Other Linux, 512 Mb RAM, HD 2 GB. Network: PCnet-Fast III, attached to NAT. You can also use a bridged adapter, but you need a DHCP server in your environment.
    Install Android x86 on the emulator, run it.
    Press Alt+F1, type netcfg, remember the IP address, press Alt+F7.
    Run cmd on your Windows XP system, change the directory to your Android tools directory, type
    adb connect <virtual_machine_IP>
    Start Eclipse, open the ADT plugin, find the device, and enjoy!

    ReplyDelete
  3. The startup of the emulator is very slow. The good thing is that you only need to start the emulator once. If the emulator is already running and you run your app again, the emulator reinstalls the app relatively quickly. Of course, if you want to know how fast it will run on a phone, it is best to test it on a real phone.

    ReplyDelete
  4. I've noticed that emulator starts much faster if there's no Dalvik Debug Monitor Server (DDMS) connected.
    So if you start the emulator from Virtual Device Manager "SDK Setup.exe" and Eclipse is not started, the emulator works faster.

    If you start the emulator from Eclipse - DDMS is there, so sometimes emulator is extremely slow, but sometimes it's faster.

    ReplyDelete
  5. It is not a problem with your environment, it is just that the emulator is very slow.

    Practically I use a real phone to do my tests. It is faster and tests are more realistic. But if you want to test your application on a lot of different Android versions and don't want to buy several phones, you will have to use the emulator from time to time.

    ReplyDelete
  6. You can create emulator.bat with follow command to start the emulator. It will start faster.

    emulator.exe -cpu-delay 0 -no-boot-anim -avd avd


    or on Unix (Mac or Linux flavors):

    emulator -cpu-delay 0 -no-boot-anim -avd <avd name>

    ReplyDelete
  7. The emulator seems to slow itself down when idle. This is made apparent by rapidly mousing over the keys on the side and observing the light-up responses. As a workaround, I pass -icount auto to qemu when starting the emulator. You can make a batch file called my_avd.bat to do it for you:

    emulator @my_avd -no-boot-anim -qemu -icount auto


    @foo -- launch a virtual device named 'foo'
    -no-boot-anim -- disable animation for faster boot
    -qemu args... -- pass arguments to qemu
    -icount [N|auto] -- enable virtual instruction counter with 2^N clock ticks per instruction


    This made animations buttery smooth and sped up adb install tenfold.

    ReplyDelete
  8. To add further information to this.

    I have recently upgraded my Ubuntu installation to Lucid Ubuntu 10.04 LTS which in turn updated my Java version to:

    Java version "1.6.0_20"
    Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
    Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode)


    And now the emulator (although takes a while to start) seems to be running faster than previously.

    It might be worth people upgrading their JVM.

    ReplyDelete
  9. The current (May 2011) version of the emulator is slow particularly with Android 3.0 (Honeycomb) primarily because the emulator does not support hardware GL -- this means that the GL code gets translated into software (ARM software, in fact) which then gets emulated in software in QEMU. This is crazy-slow. They're working on this problem and have it partially solved, but not with any sort of release quality.

    Check out the video Google I/O 2011: Android Development Tools to see it in action -- jump to about 44 minutes.

    ReplyDelete
  10. Try to disable your antivirus. Maybe it will make emulator a little bit faster.

    ReplyDelete
  11. Android emulator release 9 has new "snapshot" feature. You can save state of emulator (make image of emulator) and avoid booting when you start the emulator.

    ReplyDelete
  12. As of Revision 17 of Android SDK Tools, the emulator can use graphic aceleration and CPU provided extensions for better efficiency . The requisites and full configuration and user notes are at:

    http://developer.android.com/guide/developing/devices/emulator.html#acceleration

    for enabling gpu aceleration, run the emulator from the command line or add "-gpu on" to the additional emulator ommand line options in the avd config.

    emulator -avd <avd_name> -gpu on


    for using the cpu machine extensions, you have to install the driver (caution because it can conflict with existing virtualbox or vmware drivers). Once it's installed it will be used automatically whenever you use an x86-based AVD.

    ReplyDelete
  13. You can review the emulator issues on the Google I/O 2011: Android Development Tools talk, starting a 0:40:20.

    The emulator runs slowly because the complete Android environment is running on emulated hardware and the instructions are executed on a emulated ARM processor as well.

    The main choking point is rendering, since it's not running on any dedicated hardware but it's actually being performed through software rendering. Lowering the screen size will drastically improve emulator performance. Getting more/faster memory isn't going to help.

    They've mentioned, at the time, that they're developing an interface that would allow the emulator to pipe certain instructions through the host hardware, so eventually you'll be able to leverage emulator performances with the raw power of desktop hardware.

    ReplyDelete
  14. I installed LauncherPro APK from their website and my emulator got at least twice as fast. The system is Debian 6.0 (squeeze).

    ReplyDelete
  15. After developing for a while, my emulator became brutally slow. I chose wipe user data and it was much much better. I am guessing that it takes time to load up each apk you've deployed.

    ReplyDelete
  16. I had intermittent slow emulator (SDK v8.0) load times, up to 3 minutes on Intel Core i7 920 2.67GHz CPU running on Xubuntu 10.04 VirtualBox 3.2.12 guest with Eclipse (3.6.1) loaded. I changed the VBox guest memory from 1024 MB to 2048 MB and from that point on never experienced the slowness again (load times consistent at 33 seconds, CPU load consistent at 20%). Both Eclipse and the emulator are memory hogs.

    ReplyDelete
  17. I noticed that the my emulator (eclipse plugin) was significantly slowed by my nVidia graphics card anti aliasing settings. Removing 2x anti aliasing from the graphics menu and changing it to application controlled made it more responsive. it is still slow, but better than it used to be.

    ReplyDelete
  18. See Running Android Apps on Linux - Booting the Emulator Quickly for step by step instructions on setting up a snapshot that will boot in just a few seconds.

    ReplyDelete
  19. The older Android versions run a lot faster. When I'm on my netbook, I use Android 1.5 (API level 3). There are a couple of drawbacks, though--your apps need to support the older platforms (obviously), and ndk-gdb requires running Android 2.2 (API level 8) or higher. But regularly testing apps against older platforms is a good idea anyway.

    ReplyDelete
  20. The option -cpu-delay <delay> described in Emulator Startup Options can help.

    ReplyDelete
  21. Android SDK rev. 17 supports Virtual Machine Acceleration using AMD and Intel virtualization technologies.

    This feature can improve the emulator performance a lot!

    See the following section in the Android emulator documentation for more details: Configuring Virtual Machine Acceleration

    Don't forget to install the appropriate driver for your operating system:


    Configuring VM Acceleration on Windows
    Configuring VM Acceleration on Mac
    Configuring VM Acceleration on Linux


    After you have installed the drivers and downloaded an Android X86 system image (as described in the documentation) you should be able to create a new AVD using the x86 image:

    For example:


    Target: Intel Atom x86 System Image - API Level 10
    CPU/ABI: Intel Atom (x86)

    ReplyDelete
  22. On a 3.4 GHz quad core 6 GB of RAM, Windows 7, the emulator was unusably slow!
    I downloaded Launcher-Pro.apk through the emulator, installed it and set it as the default launcher. It doubled my emulation speed! The screens load much smoother and faster. It doesn't seem to download in 2.1 or 2.2, only in 2.0.

    ReplyDelete
  23. You need more memory.

    Here's why I say that:

    I'm using VirtualBox on Windows to run Ubuntu 10.10 as a guest. I installed Eclipse and the Android SDK on the VM. My physical box has 4GB of memory, but when I first configured the Ubuntu virtual machine, I only gave it 1GB. The emulator took about 15 minutes to launch. Then, I changed my configuration to give the VM 2GB and the emulator was running in less than a minute.

    ReplyDelete
  24. I've similar issues on a Mac. What I did;


    1) on the emulator, settings-display ->
    disable screen orientation
    2) on Eclipse, emulator startup options ->
    -cpu-delay 100


    Those had some effect in lowering CPU use (not it is around 40-60%), not ultimate solution.
    But again, the CPU use is NOT >100% anymore!

    ReplyDelete
  25. I tried booting the emulator from Eclipse (Indigo and Android 1.5, no Snapshot) and after 45 minutes I stopped it, because nothing had happened.

    Statistics: Phenom Quad @2.6 MHz with 4 GB DDR2 Corsair Dominator @800 MHz. The AVD is on an SSD drive and the emulator on a 7200 RPM HDD.

    I started the emulator manually with the -no-boot-anim option and it loaded in 30 seconds. :)

    In CMD, navigate to folder where the emulator.exe file is and type

    emulator.exe @<YourAVDFromEclipse> -no-boot-anim


    The emulator.exe file is located in the Android SDK folder under Tools.

    In Windows, you can find the the Android Virtual Device(AVD) under C:\Users\<NAME>\.android\avd.

    The projects run from inside Eclipse, targeting the AVD you booted, show up just nicely :D

    ReplyDelete
  26. Android ADT 18 now includes a (beta) GPU enabled option (simply enable the GPU acceleration from your AVD properties). It makes a huge difference and even ICS feels relatively comfortable now.

    ReplyDelete
  27. I switched from using the OpenJDK (on
    Ubuntu 10.04) to Sun Java and now
    (although still very slow) the
    emulator at least gets going. On the
    OpenJDK the emulator was hanging on
    the boot process (showing 'android'
    text in the mobile window) and never
    go to the mobile display.


    On Fedora I was able to use OpenJDK without issue. Slow though

    ReplyDelete
  28. Try scaling down the emulator, it makes it a bit faster, even if it doesn't it really feels faster.

    ReplyDelete
  29. I just took the default Android 3.1, and it was very slow, but since I realised my code was Android 2.3.3 compatible I switched to that. It's about 50% quicker and also the emulator looks more like my phone, and has a keyboard permanently displayed so that it is easier to use.

    ReplyDelete
  30. In AVD Manager select the VD and click edit, set the resolution to little as you are able to read the text on VD.

    I use 800x600 pixels, RAM set to 512 MB, and it works like a charm without high use of CPU time.

    ReplyDelete

Post a Comment

Popular posts from this blog

[韓日関係] 首相含む大幅な内閣改造の可能性…早ければ来月10日ごろ=韓国

div not scrolling properly with slimScroll plugin

I am using the slimScroll plugin for jQuery by Piotr Rochala Which is a great plugin for nice scrollbars on most browsers but I am stuck because I am using it for a chat box and whenever the user appends new text to the boxit does scroll using the .scrollTop() method however the plugin's scrollbar doesnt scroll with it and when the user wants to look though the chat history it will start scrolling from near the top. I have made a quick demo of my situation http://jsfiddle.net/DY9CT/2/ Does anyone know how to solve this problem?

Why does this javascript based printing cause Safari to refresh the page?

The page I am working on has a javascript function executed to print parts of the page. For some reason, printing in Safari, causes the window to somehow update. I say somehow, because it does not really refresh as in reload the page, but rather it starts the "rendering" of the page from start, i.e. scroll to top, flash animations start from 0, and so forth. The effect is reproduced by this fiddle: http://jsfiddle.net/fYmnB/ Clicking the print button and finishing or cancelling a print in Safari causes the screen to "go white" for a sec, which in my real website manifests itself as something "like" a reload. While running print button with, let's say, Firefox, just opens and closes the print dialogue without affecting the fiddle page in any way. Is there something with my way of calling the browsers print method that causes this, or how can it be explained - and preferably, avoided? P.S.: On my real site the same occurs with Chrome. In the ex