
How to speed up the Android Emulator by up to 400% - DanielH
http://blogs.nuxeo.com/dev/2011/10/speeding-up-the-android-emulator.html
======
dpcan
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
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.

~~~
aab
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

~~~
bigiain
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)

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

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

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

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

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

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

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

~~~
bwblabs
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...](http://developer.android.com/guide/publishing/versioning.html)]
and if you do some (proxy) audio stream playback there is the
[[http://google.com/search?q=PVMFMemoryBufferReadDataStreamImp...](http://google.com/search?q=PVMFMemoryBufferReadDataStreamImpl)]
error with no real solutions...

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

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

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

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

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

~~~
ConstantineXVI
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)

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

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

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

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

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

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

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

~~~
ketralnis
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

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

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

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

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

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

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

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

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

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

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

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

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

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

