
Android Needs A Simulator, Not An Emulator - wallflower
http://jakewharton.com/android-needs-a-simulator/
======
stusmall
For a bit of history, once upon a time Android did have one of sorts. You can
still see sprinklings are references to it in AOSP but I think the simulator
lunch target has been removed. It was from the early early days and allowed
them run to run parts of it on the desktop. You can see some of the reasoning
on why they preferred the QEMU solution here:
[https://groups.google.com/forum/#!msg/android-
porting/fLObl9...](https://groups.google.com/forum/#!msg/android-
porting/fLObl9n4KkA/ErHBctDIJ58J)

I guess I don't see the point of a simulator either. If the performance is
that bad, why not just use hardware?

~~~
jo_
The point of a simulator is it drives deployment time to zero and increases
the number of virtual devices on which you can run without adding a new AVD
for each. Deploying to a phone takes maybe 40-60 seconds? Maybe less? But I'm
not a very patient person. At 60 seconds per deploy, if I make a tiny tweak
and then have to wait a full minute for feedback on how it feels, it has
become a slow and arduous process to develop. If I deploy to device and
immediately discover a null-pointer exception, then that's 120 seconds of my
day gone. The amount of time is even longer for an emulator, where it can be
as long as five or ten minutes.

~~~
stusmall
It is much much less. I just timed it on my machine. It was 8 seconds for a
decent sized(~12M) app. A build and deploy takes much longer, but the long
pole isn't the time it takes to install the app on the hardware. If you are
having a lot of latency, I don't think a simulator will help.

~~~
christop
This is still far longer than it should be.

I just built a not-particularly-large app after making a single-line change
and it took 16 seconds to compile, dex, package and install on a running x86
emulator. The installation time is appreciable (4 seconds for my 10MB APK),
which would be cut to zero for a simulator. Similarly, removing the dexing and
packaging would be a great help.

I'm jealous when I see how fast my iOS colleagues can make code tweaks and see
them running on a simulator one second later.

------
IgorPartola
I wonder if an Android device as a service would work. No, I don't mean
loaning devices. I mean by the hour remote control of an Android device you
can take over. Your end looks like the simulator, my end is a farm of Android
devices which get a factory reset between every client connecting. You reserve
it for as long as you want, or just do one-off testing.

Edit: I suppose I should ask a more concrete question: would you pay for a
service like this? If not, what would you use instead?

~~~
nnnnni
How would you avoid/handle abuses like using it as a proxy to access extremely
illegal things?

~~~
IgorPartola
How does AWS do that with their remote desktop in the cloud service? If you
use this service, I have your name and credit card number.

~~~
mentat
You have a name and credit card number which may or may not belong to the
person using the service.

~~~
coralreef
Nothing is 100% in this world, its a good enough filter.

------
lnanek2
First party support for Robolectric would be wonderful. It is a nightmare any
time you need something Robolectric doesn't implement, particularly in Context
classes because there are so many different types of Context: Application,
Context, ContextWrapper, ContextImpl, Activity, etc. and I've never gotten
Robolectric's @Config and @Implementation annotations to successfully add to
them without blowing up about weird super class not matching errors.

------
smrtinsert
The only thing I'd like is maybe a gradle build for ADT. I like my workflow I
just hate placing required android libs on the path by hand, so time
consuming. I only test on devices so the emulator thing to me is really a non
issue.

That said, I would love a "simulator" since it would probably mean that Google
has wrapped the JDK with an Android interface which frees me from having to
every use Swing/SWT/ _any other java gui toolkit here_ ever again.

~~~
sgarman
Are you doing your integration and instrumentation tests on actual devices as
well?

~~~
smrtinsert
I only do manual testing since Im a hobbyist android dev.

------
mtdewcmu
When I started a new job doing iOS development, I was a bit surprised that
Apple provided a simulator and not an emulator for iPhone/iPad development. An
emulator seemed like a better choice, because it would be more realistic.
Realism turned out not to be a big issue, at least for the kind of app we were
developing, and I guess iOS and Android devices are just too fast to emulate
on a desktop with reasonable performance.

~~~
MBCook
I'm not sure how necessary true emulation really is. The fact that you can
easily plug a phone in and run there means that the emulator isn't as valuable
so would be if it took 20 minutes of hoops to get your code on a device.

~~~
mtdewcmu
True, and I think Apple's simulator turned out to be the right move.

------
mwcampbell
What platform(s) would the simulator support? Just GNU/Linux? Even that is
quite different from actual Android in some ways, e.g. glibc instead of
bionic. It's easy by comparison for Apple to provide a simulator, because the
simulator only has to run on Mac OS X, which basically shares everything below
the UI toolkit with iOS.

~~~
lambda
You're not forced to use glibc on GNU/Linux. You could link against bionic if
you want, assuming it runs in a stock kernel.

------
junk3d
When I develop in Android, I have this feeling that Google was thinking
something along the lines "Its good enough and now we can just switch it into
maintenance mode"

------
mantraxB
> "The most well known simulator to any Android developer is probably (and
> ironically) the one that iOS developers use from Apple."

I get it. Ironically Google didn't copy Apple for once, and their solution
turned out bad. So now they need to ironically copy it, please, Google, pretty
please. But the real irony is that Android developers both get to boast about
Android being open source, yet when they need something, they go beg Google
implement it for them.

And Google really can't implement an efficient iOS simulator for them, because
there's no Android desktop operating system.

You see, while it's getting a bit old to hear Tim Cook brag at every keynote
about how _" only Apple can make everything work seamlessly together"_, truth
is, they indeed share a kernel and over half their APIs between their desktop
and mobile operating systems. This is why the iOS simulator is that good. Tim
Cook knows it.

While a supposed "thin layer" Android simulator has to interface _all its
APIs_ with Windows and then do it _all over again_ for OSX, and then _again_
for Linux (common POSIX APIs notwithstanding), every version with its unique
quirks and bugs, not matching the platform it's simulating.

So instead of that ball of pain, Google chose the easier task of virtualizing
the actual hardware and then running the whole Android stack on top of that.

In their particular circumstances, this was, and remains the only feasible way
of doing it, and no amount of blog whining will change that.

Turns out you really can't copy some things so easily.

~~~
nailer
> Google really can't implement an efficient iOS simulator for them, because
> there's no Android desktop operating system.

The x86 Android build provided by GenyMotion (cited in the article) performs
at the same speed as the x86 iPhone simulator.

It has two major issues:

\- The UI is quirky (but usable)

\- It's expensive

\- GenyMotion devices have no Google Play by default. Want to test how your
website runs in Chrome? Spend ages hacking Google Play onto the Android
device.

Google could fix all of these things easily.

~~~
ZoFreX
The x86 images provided by Google run just as fast as the Genymotion images,
and have Google Play. Just FYI.

~~~
nailer
Thanks for the suggestion. I spent an hour setting these up today - despite
supposedly using x64, HAXE etc they're unusably slow. I have no idea what's
wrong. The UI tools run at unacceptable latency (they're Java based) so I
can't debug easily.

This is on a 2013 Haswell MBA with 8GB RAM and a 512GB SSD.

Google may as well throw the official emulator away.

~~~
ZoFreX
When you run the emulator, do you get this message (on stdout): "HAX is
working and emulator runs in fast virt mode"?

Did you enable the "Use host GPU" option?

------
Birdy_0
Have you guys heard of GennyMotion? It's way faster than the actual Android
Emulator. My Professor for my Android Class in college recommended it to use
for debugging for our assignments if we didn't have an Android Device.

[http://www.genymotion.com/](http://www.genymotion.com/)

~~~
recursive
Wow, that page has a 2.5mb png as a background image on one of the elements.

~~~
smrtinsert
wow, how many jqueries is that?

~~~
recursive
80, counting gzipped jquery.

