How to speed up the Android Emulator by up to 400% | Hacker News Reader

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

blogs.nuxeo.com

205 pointsDanielH54 comments

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.

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.

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

Ahhh, "write once, debug everywhere", where have I heard _that_ before?

(for me, that was a lesson learned in 1995 doing Macromedia "cross platform" Mac and Windows development)

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.

What you're saying is true, but OTOH there is only one series of iPhones/iPad Apple has to worry about simulating whereas there are thousands of different Android devices, each potentially radically different than the next in terms of resolution, aspect ratio, cpu, device capabilities (gps, microphone, camera, etc).

Of course this diversity is both Android's largest blessing and its biggest curse.

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.

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...)

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.

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.

"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.

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.

My appologies, I didn't realize I was putting words in your mouth. I believe it was your post that called Android dev. a pain though, and unless I'm mistaken it was also you who referred to the emulator as an obstacle. Finally, I said all these things in relation to MY experience. As for my assumptions, i simply assumed you were an amatuer Android developer because, despite the fact that Android is known to be used on a wide selection of devices--all of which couldnt possibly be accomodated on one emulator in any effective way--you are still fixating on the fact that the emulator doesnt cater to your expert needs. I suppose I simply assumed that someone like yourself would have moved on from such a basic method of developement, since "to say that [you] develop for iOS at a basic level is laughable at best."

Just watch that your horse desn't fall off that precariously-high ledge and crush us lowly startup operators.

The Android application I'm developing is immensely easier because of Android's open-source nature. Not only are things simpler on my physical phone because of cyanogenmod, but the basis for my program is actually Google's Camera app -- I literally copy the code verbatim and make the necessary changes. My project would be many, many more times work if I had to start a camera application from scratch (for what I want to do, using the intent that exports to the native camera widgets that are pluggable into your application is not sufficient, I need full control of the process).

Why does being an iOS developer give your insight into the Android platform credibility?

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.

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...)

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.

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.

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..

Thanks for the insight. I personally have yet to have any issues running on any devices, but most of what I'm doing is internal to our company and doesn't have a very large user base. Also, our code is pretty standalone from the OS itself.

Regardless, there's always going to be the issue of supporting multiple devices, but I have found that if I develop in the 'perfect' environment first, it speeds development time considerably. It's akin to web development against standards. I feel very sorry for the developers (if there are any left, this used to be accepted practice) who developed for Internet Explorer, and then had to cobble in "support" for other browsers. In much the same vain, it's easier to work against the best possible outcome, and then revisit your code for the edge cases.

I don't know, or have any numbers to know whether or not the Galaxy S2 is 'edge' or not, as I'm guessing it's quite popular. :-\ Sorry.

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.

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

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

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)

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

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.

> 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.

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.

> I think his point is that it's easy to ignore serious usability problems when you're using better hardware than your customers.

Only if you don't test on real devices.

Testing is not a boolean. You won't notice if some item on a checklist took a couple of seconds during your daily device test, but a user will notice when that action is all he's doing, over and over.

You say "testing is not a boolean", then imply that testing "over and over" is? Developing on the emulator doesn't stop you from doing nice, lengthy real usage testing on the devices once you've got everything in decent shape.

That's true, and there's no reason most people can't use their gym memberships, but statistically they won't. Nobody's saying that you must do all your testing on average hardware — just that they prefer it because it forces them to put proper time into it.

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

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

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.

As an iOS developer that seems like a moot point. There are device bugs that cannot be replicate in the simulator, but everyone knows that. That's why you need devices.

But for general everyday development, I much prefer the simulator - I can look at the result of a code change in under 5 seconds with a simple keystroke, and not even have to pick up a device off my desk. It's empowering to be able to tweak your UIs and see the results in almost-real-time. I cannot do that if I'm forced to push the app to devices every single time.

Not to mention the debugger runs a hell of a lot faster on the host machine than any device - for the vast majority of bugs that isn't based on device quirks, it makes them much quicker to isolate and resolve.

Sure my point is that this article is mistitled. They're not increasing the emulator speed 400%, they're switching to Android x86 and achieving speed ups. This may be a good thing to do but is entirely different from improving the speed of the emulator itself.

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

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

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.

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

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

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.

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.

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.

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

Honeycomb emulator is slower because of the 1280x800 resolution. Google mentioned at I/O that it seems the emulator lags from the lack of hardware acceleration, and they said it would come by end of the year I think. I wonder if it's ready for 4.0. It should be.

Honeycomb emulator is also much slower because more parts of the UI use 3d acceleration which the emulator has to, well, emulate in SW

Wow. What OS?

Windows 7.

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.

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.

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..

Reply on news.ycombinator.com