How to speed up the Android Emulator by up to 400%

http://blogs.nuxeo.com/dev/2011/10/speeding-up-the-android-emulator.html

by DanielH • 15 years ago

205 54 15 years ago

blogs.nuxeo.com

shoota3• 15 years ago

It's not really an emulator if you're running the x86 port of Android virtualized on x86 hardware...

ketralnis• 15 years ago

Sure, but to most developers the functionality of seeing their mobile application running on their desktop machine is "emulation". And they probably don't need true emulation, they just need to test their application

shoota3• 15 years ago

That depends on whether or not there are any bugs or quirks in Android x86 that may or may not be present in Android for ARM and vice versa.

jamesu• 15 years ago

Makes me wonder why the SDK doesn't use an x86 vm by default in the first place.

sp332• 15 years ago

Wouldn't all the NDK programs at least have to be recompiled?

ConstantineXVI2• 15 years ago

You'll effectively have* to post ICS; Intel is an officially supported platform now (and Google TV is currently Intel only, provided you want to be on that platform).

* Presuming you want your NDK app to run any Intel-based tablets/phones.

shagrath• 15 years ago

At Google I/O, the sdk team said it was coming in the next months (along with GPU support), but the downside was that KVM is not readily available outside linux

cookiecaper2• 15 years ago

Not much of a downside imo. Serious non-.NET developers should be using Linux anyway.

imperialWicket3• 15 years ago

What system takes 55 seconds to boot an Android Virtual Device?

I get to the home screen with everything loaded in about 18 seconds. I'm on a fairly new system with decent processor and memory to spare, but even on my old single processor 4GB laptop I get the emulator launched in about 35 seconds.

calloc2• 15 years ago

An core i5 with 8 GB of ram and a 7200 RPM 500 GB hard drive.

Actually, it is closer to 70 seconds.

Then the lag while attempting to use it is unbearable, it stutters, input is completely ignored, or it crashes randomly when we try to replicate that bug on an actual device we can't.

imperialWicket3• 15 years ago

Wow. What OS?

Roritharr3• 15 years ago

What kind of Android? 3.1? the 2.3 emulators are much better than the honeycomb ones.

imperialWicket3• 15 years ago

For reference, I'm running Fedora 64bit on an i7 960 with 24GB RAM, and an intel 510 ssd. I haven't increased RAM at the AVD level.

ineedtosleep• 15 years ago

Older system here for comparison:

Core2 Duo, T7500 @ 2.20GHz 4GB RAM Patriot Inferno SSD

2.3 load time from start to lock screen: 65 seconds.

codenerdz• 15 years ago

based on the data in the article QEmu + Android ARM runs at approximately same speed as Nexus One phone which is a good thing, right? I dont want my development emulator to run twice as fast as actual hardware, do I.

The question is whether you can make the emulator run as fast as modern dual core android phones.

reemrevnivek• 15 years ago

> I dont want my development emulator to run twice as fast as actual hardware

Why not? A lot of programmers develop native apps on high-performance workstations because it makes development faster.

Once in a while, you might hit a bug in which the execution time on a phone or in a slow emulator will cause problems. These are the exception to the rule. Use good programming practices especially with respect to multithreading and time-sensitive code and use sensible algorithms (don't under- or over-optimize), and these will be few and far between.

In general, you want fast builds, fast tests, and fast iteration. Anything that allows you to iterate faster is a good thing.

chc3• 15 years ago

I think his point is that it's easy to ignore serious usability problems when you're using better hardware than your customers. For example, developers with big screens are more prone to create GUIs that do not work well on small screens. Similarly, some Xbox games are unplayable in 480i or 480p mode because nobody ever bothered to check whether the interface elements were readable at low resolutions.

shareme• 15 years ago

hmm why not set the avd ram size to 512?..even on my slow 32bit 4 gig ram 2-cpu core desktop ubuntu I do not get his slow figures..

simmons• 15 years ago

I've been using Android-x86 in a VirtualBox for development for a long time, and totally recommend it if your app is pure Dalvik (i.e. no native ARM code). It's a night and day difference after using the emulator.

One pain point I have, though, is the need to always hit the VirtualBox host key when switching between Eclipse and VirtualBox, since there's no true integration. Sometimes I also get some weird effects with the mouse pointer not being able to move around the entire framebuffer. (Hmm, maybe a VirtualBox integration module for android-x86 would be a good weekend project...)

Roritharr3• 15 years ago

This is for me the main reason google finally needs to release the Honeycomb Source, so we can have Honeycomb running on x86.

ConstantineXVI2• 15 years ago

Technically, it's out there. The Google TV SDK (which is Honeycomb) runs on x86. Running it requires a Linux distro with KVM though. I'd bet the ICS SDK will come with some form of x86-based images as well (since they've promised x86 support for all future Android releases)

nextparadigms2• 15 years ago

I think Android 4.0 will be optimized for Intel Atom at least.

thevectorist2• 15 years ago

This is another symptom of why Android development is such a pain. You have to jump through hoop after hoop after hoop just to get to the point where you can get actual work done. If a tool ends up wasting more time than it saves, it isn't a tool, it is an obstacle.

Roritharr3• 15 years ago

That is an overstatement. This was true in the beginning for the honeycomb sdk, but as you can easily develop against hardware this isn't an issue anymore.

The Android 2.2 and 2.3 Emulators are atleast on my machine fast enough for development, but i still prefer to develop against hardware just because it feels faster and more real. Multi-Touch is easier...

Even on iOS it's better to develop against actual hardware than the simulator, therefor it's not really that much of an issue.

camdykeman2• 15 years ago

"Such a pain" as compared to what exactly? This will depend entirely on what it is that youre trying to do. In all my experience, Android is notoriously easy to develope on, being fully open-source the way it is. Try developing for iOS beyond a the basics and I think you'll come to agree.

I dont think its fair to call the emulator an obstacle, it just comes with limitations. After all, emulators are only designed to emulate, they can't replace areal device. A hammer is still a tool, its just not the appropriate tool when you're trying to assemble a clock.

Maybe its just time to upgrade your tools.

thevectorist2• 15 years ago

Please don't put words into my mouth or make assumptions about me. I am primarily an iOS dev. An app I worked on won an Apple Design Award and multiple other apps are in the Top 5 paid apps for their category in the iTunes store. To say that I develop for iOS at a basic level is laughable at best.

XCode isn't perfect, but I don't need google for blog posts or spend hours writing scripts or messing with configuration files in order to get it into a usable state.

Being open source has nothing to do with how easy a platform is to develop on. All that means is that the platform's source code is available.

dpcan• 15 years ago

I think any experienced Android dev will tell you, the best solution is to buy a bunch of used Android devices, plug them in, and publish to the device directly for testing. Wasting any time with the emulator or this "virtual machine" isn't going to cut it in the end anyway.

The only time I fire up the emulators is to make sure my assets are scaling properly for the various screen sizes of devices I don't own yet.

sskates• 15 years ago

As an Android dev, I have to say this is very true. Emulators either don't simulate or don't simulate well enough a lot of stuff that you really want to test, like picking up audio from a microphone, or getting your location from GPS. There are also a lot of device specific quirks that make code run differently on different devices, meaning if you really want to make sure your code runs everywhere you can't just get one phone, you need to get a few.

danielrhodes• 15 years ago

Try using the iOS simulator to see what you're missing. The development time is greatly reduced because you're not having to constantly wait for the app to be deployed on the phone. The differences between the simulator and the actual phone are quite minimal.

bwblabs2• 15 years ago

Well, the Android emulation is pretty good with GPS & call simulation, only limitation is Eclipse which only let you control 1 emulator (or device) at a time, but if you connect to the emulator port, you can manage quite a lot.

If you start with video (or even audio) displaying/capturing then the emulator is pretty fast useless indeed.

aab• 15 years ago

Also, on the emulators you don't usually have Sense UI, Motoblur or any other custom crap the manufacturers decide to put on the real phones. At one point I had 10 Android phones for development & testing just to make sure everything runs the same way on all phones

dazmax• 15 years ago

Someone should sell a usb dongle with an ARM chip on it that can run android using the emulator on your dev machine for display and input.

Debugging on a phone is not so bad, but it's not quite as nice as the iOS simulator experience.

bmelton2• 15 years ago

That's exactly the purpose for which I bought the Nexus S, the Nexus One, and the HTC G1.

They are the Google Reference devices. Admittedly, it's perhaps not as lean as what you're referring to, but as a testing sandbox, I've tried a lot of different phones, but nothing has worked as well, in a general sense, as the reference models.

bwblabs2• 15 years ago

I ended up buying the popular phones (HTC Desire HD, Samsung Galaxy S2, etc.) just for testing, I'm on iOS myself.

But just working from (non reference) phones is dangerous too, it's so annoying to implement the volume controls with a BroadcastReceiver for the ACTION_MEDIA_BUTTON Intent (works great on Motorola's), but fails on HTC, and you should just override onKeyUp()... all (Android) phones behave differently, and not only in (screen) specs. Samsung Galaxy S (<2.2) is notorious in not following the Android specs, for example it shows the versionCode instead of versionName to the user [http://developer.android.com/guide/publishing/versioning.htm...] and if you do some (proxy) audio stream playback there is the [http://google.com/search?q=PVMFMemoryBufferReadDataStreamImp...] error with no real solutions...

The problem is, in the end, it should work on the popular devices, not the 'perfect' Android reference phones..

limmeau• 15 years ago

Android has been ported to the BeagleBoard, so half of that is already available. However, I don't know whether Android's GUI can run over X11/VNC or similar.

bigiain2• 15 years ago

For me, that "dongle" is a ~$70 prepaid android phone (a Huawei L8180). I strongly doubt any low volume developer aimed hardware could be built and sold for much less than that...

I figured it was important to test on a low end phone, right? ( see how I nicely justified my cheapness there?) The downside to that plan was the jQuery Mobile bug that only showed up on top end devices (now the Huawei has a Galaxy S2 siting next to it...)

slowpoison• 15 years ago

This doesn't help much if you are using Google APIs in your Android application. There are no x86 builds available for Google APIs AFAIK.

xthlc• 15 years ago

I've tried this. It's faster even than developing with a device -- once you get a good test/debug flow going it's awesome. Some big caveats though:

* No Google APIs. So no MapView.

* The various builds are quirky. I couldn't get networking to function in the "Stable" Froyo build. Meanwhile, the Gingerbread build used in the linked post reports the wrong SDK version (it claims Honeycomb but is actually Gingerbread). The deprecated Froyo build I tried didn't support Google Accounts. And so on.

Meanwhile, new builds are currently impossible due to the ongoing kernel.org outage (android-x86 has some hard submodule deps on git.android.kernel.org), so my attempts to go in and tweak the build were thwarted.

Still, very cool stuff. I think the iOS simulator is fantastic and I've been pining for something similar for Android. This doesn't quite meet my needs at the moment, but it would save me multiple hours per week if I could get it set up properly.

campnic2• 15 years ago

Ugh, no Google API support!? That is a pretty big deal.Wish I would have seen that earlier.

How to speed up the Android Emulator by up to 400%

Related Stories