
A better Android emulator - manymo
http://www.manymo.com
======
anigbrowl
Dear HN moderators: the original title (about 43 Android emulators within the
browser) was far more informative than this rewritten version.

~~~
hayksaakian
Agreed, I clicked on the title expecting some kind of great update to the
normal android emulator, with the old title I would not have been mislead.

------
dj2stein9
If you want a fast way to run Android, you can also use a VirtualBox image, it
is significantly faster than the emulator in the SDK:

<http://www.buildroid.org/blog/>

~~~
ConstantineXVI
I've found the official Intel-based emulator images (2.3+ only) plenty fast.
Details here[0] but the tl;dr is:

* Open SDK manager, install Intel image for your preferred SDK version and the "Intel Hardware Accelerated Execution Manager" from the Extras section

* Find the HAXM installer in SDK/extras and run

* Create Intel-based AVD

[0] <https://developer.android.com/tools/devices/emulator.html>

~~~
kerrishotts
Just an FYI -- this killed my Virtual Box install the last time i tried it.
Uninstalling HAXM fixed it all, but having Virtual Box was more important than
the Intel images, so I left it uninstalled.

~~~
pschwamb
This issue specifically, and others like it (snapshot management, bugs in the
interface to create emulators, such as setting the hw keyboard) really made
managing local android emulators a pain for us. We thought we could make the
experience better, so we made Manymo.

------
martin_bech
What irks me most about the regular Android emulators and actually also
testing on the devices themselves, is that alot of restrictions seems to be
off in dev mode. In my instance i was using a jsonp webservice over https.
Everything worked aces on the 2.1-2.3 emulators, and a device in dev mode, but
when I published the app, turns out that the SSL certs, or rather the ssl
trust chain, wasnt trusted in "Retail" mode on Android 2.1 and 2.2.. Why oh
why did it work in the emulators and on the devices while developing..

On topic, this looks great!

------
georgemcbay
This could be useful for mobile web developers who don't want to install the
full Android tools, but both this and the recent VirtualBox based Android
system are (for native app developers who have a CPU with VT-x, EM64T, and XD
-- basically all modern Intel chips) inferior to just using the Intel-x86
based emulator that has shipped since Android SDK API 10.

Both of these projects would have been extremely awesome to have a couple
years ago, though.

~~~
stoney
These projects are still extremely awesome for those of us running older CPUs!

------
lallouz
This looks extremely useful assuming it works. Although I never use the
emulator while building Android because it basically does not work on most
machines and does not give you any real indication how your code will run on
an actual device.

Very curious how they pulled this off.

~~~
drivebyacct2
> Although I never use the emulator while building Android because it
> basically does not work on most machines and does not give you any real
> indication how your code will run on an actual device.

This has not been my experience in the least...

~~~
lallouz
you find you get a consistent experience between running code on the emulator
and on a device?

Have you tried running your code on any of the OEM releases like HTC sense,
Samsung TouchWiz or Moto Blur?

------
andrewljohnson
What I really need is a way to emulate specific devices.

My Android app crashes on a Droid Razr Maxx right now, when it rotates, and I
don't have one to test on, so I have to get crash logs from users.

~~~
lmm
Device Anywhere might be what you want. They connect real phones to their
system for you to use, and have a large variety of models (or at least had - I
haven't used them in a couple of years). They're expensive, but worth it for
the convenience.

------
100k
The developers of this are friends of mine so I got to play around with it a
little last month.

Though I'm not an Android developer, I can see how useful it would be for
testing mobile web sites. You can launch an emulator in many different
resolutions and pixel densities to check out your web site/app.

You can also see a video of the product in action at the last MinneDemo:
<http://www.youtube.com/watch?v=3TXiDPlc3Fg>

------
duiker101
I keep getting the page with the Android-fail-whale image. No idea what is
going on... didn't last long this website. Can someone explain how does this
work?

~~~
tomtoday
We are adding servers right now. In the meantime here is a short screencast of
an earlier version in use: <http://vimeo.com/48571832>

------
kmfrk
I'll be the token Opera guy in the thread and reiterate that they have a
mobile simulator as well: Mobile Emulator.

It's annoying that it doesn't come with default iOS device settings, though,
but it's a great alternative to running a server to test on.

~~~
spartango
This(manymo) doesn't seem primarily meant to be used for web development, but
rather Android native application development. Opera's emulator is designed to
emulate a mobile browser, nothing more.

------
thejosh
Keep getting:

Failed to connect to server (code: 1000, reason: Target closed)

~~~
pschwamb
yeah, we're getting a bit more traffic than expected.. bringing more servers
online shortly.

~~~
thejosh
Yeah, that's the downside of having something awesome like this.

------
vitek
This is really cool, nice work. That said, many of the problems I've
experienced have more to do with weird behavior in the OEM code (i.e.
TouchWiz) than core android stuff. It would be beyond awesome if there was a
way to launch OEM versions by simply entering the model number of the device.

------
badhairday
Is there any difference between this and having a real device with the same OS
version and screen size?

~~~
LeFever
In addition to hardware capabilities and responsiveness mentioned by others,
the performance data (CPU usage, memory usage, battery usage, etc) of a real
device will be vastly different than the emulated version. In addition,
emulators typically do not run manufacturer or carrier ROMs, meaning that the
behavior on the emulator often differs from the actual device.

For testing initial layouts or on-the-fly development, emulators are fine
because they offer instant local access (After the setup, of course, but who
cares now that x86 emulators are so fast). For complete testing real devices
are a must. That's traditionally been expensive, but there are solutions to
that, such as the company I founded, AppThwack, and our competitors like
TestDroid. Test locally on emulators, and test periodically on real consumer
devices.

There's a reason nearly every development shop has a cupboard full of devices,
and it's not because they couldn't figure out how to get a few emulators
running.

------
CRidge
Finally got an emulator running :-D

"Start quickly." - not today, but hopefully in the future?

"Run smoothly." - ehmmm... Nope! Smooth as barbed wire...

"Are lightweight." - perhaps, but that makes little difference if it fails the
first two bullet points.

Fantastic idea - had it worked. Let's hope it will with some tweaking :-)

------
peteforde
I've been putting off porting an iOS app to Android specifically because of my
fear of testing on so many devices.

While I'm sad that there are 43 (and counting) possible variations, this looks
solid and helpful — I'm much more likely to attempt my port project now.

~~~
manmal
Get a low-end (HTC Legend), a mid-end (HTC Desire / Moto Droid), and a high-
end (Samsung Galaxy Nexus or S-II/III) device, and you are good to go. Also
get a cheap tablet if you need to support that. Always develop on the lowest
end device as a rule, and the optimizations you apply to make it usable on it
will make the app super snappy on higher end devices. Choose Android 2.2 as
your target platform and you include 96% of Android devices:
<http://developer.android.com/about/dashboards/index.html>

Always use dp instead of px, use dynamic layouts (like HTML/CSS) instead of
absolute ones (like in iOS), use 9-patch or XML drawables wherever you can,
don't fight the framework. Use the compatibility library for fragment support
and other cool stuff, and use them wherever you can. Be careful about bitmap
memory consumption, that's a gotcha on low-memory devices.

If you don't mess around with low-level stuff like NDK or OpenGL you should be
good to go on the very most devices. The well-tread Java API paths are not as
scary as some blogs want to make you believe. You don't have to own all the
10k devices which exist, because most of them have stock Android installed.
For special cases you will receive stacktraces from people's devices in the
Play dev console - or you use one of those crashlog services.

~~~
hayksaakian
by moto droid do you mean the original moto droid? if so, i'd think by now the
2+ year old handset would be considered low end

~~~
manmal
Yes, the original one. No, HTC Legends are still around, those are the real
low ends, also in terms of display resolution.

------
stuaxo
Really irks me there isn't a tool I can download to setup emulators that
mimick actual released devices - trying to find the settings and set it up
manually is a real PITA.

------
drnicwilliams
This looks really great. Very clever!

------
Legend
Awesome!! Care to share any technical details on how this was done for newbies
like me? Thanks!

------
wizche
Awesome! In my opinion a killer feature would be to add sharing/embedding
support.

------
ilija139
Such a bummer, getting number 1 on HN and can't show your product...

~~~
lnanek2
I guess it is part of the problem space in this case. The reason they can
compete with running the emulator locally is that is it so freaking slow.
There are some cases where you can speed it up, like Intel emulator images and
if you are lucky hardware OpenGL support, but these don't cover all the cases
you often need to test, and many developers don't know about them or don't
have systems that can use them anyway. So it being difficult to run the
emulator fast is the main point of pain, which is the same thing making it
tough for the company to scale in this case. Makes me wonder what they are
using themselves to speed things up, if anything. Intel images, x86 branch of
Android, ARM servers maybe somehow? Their solution would affect their
scaling/server obtaining.

------
aprasad
I wish I had this when I was doing Android development last year

------
donrhummy
Couldn't get it to work in Firefox 16.

