A better Android emulator(manymo.com)
manymo.com
A better Android emulator
http://www.manymo.com
57 comments
Dear HN moderators: the original title (about 43 Android emulators within the browser) was far more informative than this rewritten version.
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.
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/
http://www.buildroid.org/blog/
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
* 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
Agreed. The Intel images turn the emulator into a generally useful tool. If you enable graphics acceleration in the AVD performance is more than good enough for testing the apps I've tried so far.
The emulator does take a while to start but that's a one-time cost.
The emulator does take a while to start but that's a one-time cost.
Don't forget to enable GPU Acceleration too. I've posted about this here: http://codebutler.com/2012/10/10/configuring-a-usable-androi...
Testing inapp billing without a physical device is still my biggest reason staying with the VirtualBox-based approach.
Installing Play Store app on emulator still requires some hacky workarounds.
Installing Play Store app on emulator still requires some hacky workarounds.
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.
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.
I didn't know this, I'll try it out, thanks!
Thank you for the link. I'm already up and running. It's much faster than the SDK VM, boots almost instantly. Works perfectly with ADB and is just a pleasure to use.
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!
On topic, this looks great!
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.
Both of these projects would have been extremely awesome to have a couple years ago, though.
These projects are still extremely awesome for those of us running older CPUs!
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.
Very curious how they pulled this off.
[deleted]
I'm one of the founders of Manymo.
I feel your pain re: trouble running emulators for dev work. We built Manymo to address this pain. While it does not (yet) emulate custom android builds, like the dreaded HTC Sense builds, it does give me an emulator faster than I can spin one up locally.
I typcially develop with a phone and a tablet but using Manymo I can spin up a larger tablet or an odd-sized phone emulator to check how my Fragment code is laying out on a variety of device configurations. All of that without soaking up memory on my laptop. It helps testing against OS versions too. We also find it extrememly helpful when working with designers that do not have the SDK setup. The list goes on but suffice to say we are excited to see more people use this tool.
I feel your pain re: trouble running emulators for dev work. We built Manymo to address this pain. While it does not (yet) emulate custom android builds, like the dreaded HTC Sense builds, it does give me an emulator faster than I can spin one up locally.
I typcially develop with a phone and a tablet but using Manymo I can spin up a larger tablet or an odd-sized phone emulator to check how my Fragment code is laying out on a variety of device configurations. All of that without soaking up memory on my laptop. It helps testing against OS versions too. We also find it extrememly helpful when working with designers that do not have the SDK setup. The list goes on but suffice to say we are excited to see more people use this tool.
> 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...
This has not been my experience in the least...
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?
Have you tried running your code on any of the OEM releases like HTC sense, Samsung TouchWiz or Moto Blur?
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.
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.
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.
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
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
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?
We are adding servers right now. In the meantime here is a short screencast of an earlier version in use: http://vimeo.com/48571832
Same here, and it takes quite a long time to land on that page. I guess the website times out..
Yup- Fail Droid.
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.
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.
... and I forgot to c/p the link from my tab like an idiot: http://dev.opera.com/articles/view/opera-mobile-emulator/.
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.
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.
Is there any difference between this and having a real device with the same OS version and screen size?
I'm assuming 'this' is any emulated device and not specifically Manymo (which I haven't tried -- I keep getting the "Fail Droid"). But there are plenty: you can't test bluetooth, get network state, check battery status, and other things.
But emulators are ok to test your layouts, even though the latest ADT plugin makes it much simpler with layout previews.
But emulators are ok to test your layouts, even though the latest ADT plugin makes it much simpler with layout previews.
The answer is: it depends. This is an android emulator - the same that Google ships with the Android SDK. A real device will probably be more responsive.
You will also have the difference of a touch based interface on a device and the emulated touch interface when using mouse-based devices (Manymo in your laptop/desktop browser.) That said, You can also use Manymo on your iPad...
In any case, having a device with the all screen size and OS version combinations does not really scale. Trying to do that gets rather expensive.
You will also have the difference of a touch based interface on a device and the emulated touch interface when using mouse-based devices (Manymo in your laptop/desktop browser.) That said, You can also use Manymo on your iPad...
In any case, having a device with the all screen size and OS version combinations does not really scale. Trying to do that gets rather expensive.
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.
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.
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 :-)
"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 :-)
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.
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.
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.
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.
highest density of good advice i've seen in a long time
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
Yes, the original one. No, HTC Legends are still around, those are the real low ends, also in terms of display resolution.
I had the same fear as you, initially. It's true that there are a lot of possible devices, versions, screen sizes etc. But in all reality, you mostly need to care about 2-3 devices.
- OS: Android 2.2/2.3 and 4.x. (Rest doesn't matter, honestly)
- Device sizes: a big/new samsung galaxy-sized one (~ 1200x700), one 320x480 and maybe a smaller one.
Depends a bit on your target demography.
This isn't actually too much worse than what you have with iOS these days, where you have retina + non-retina + tall device. (possibly + iPad). And possibly 3 iOS versions to think about - 4.3, 5.1 and 6.0.
- OS: Android 2.2/2.3 and 4.x. (Rest doesn't matter, honestly)
- Device sizes: a big/new samsung galaxy-sized one (~ 1200x700), one 320x480 and maybe a smaller one.
Depends a bit on your target demography.
This isn't actually too much worse than what you have with iOS these days, where you have retina + non-retina + tall device. (possibly + iPad). And possibly 3 iOS versions to think about - 4.3, 5.1 and 6.0.
Some of the noise you hear is precisely that. The ways in which your application can fail will depend on the sort of things it does. Generally if you follow Android best practises you will be fine. On the other hand if you pretend it is a dumb iOS device you'll have trouble. For example if you do screen layout using pixels you'll be digging a big hole.
As for testing, things can be easier. Unlike iOS provisioning profiles you can give the application package (apk) to anyone and they can sideload it onto their device (even from following a web browser link). They just have to change one setting to allow this. This means you can distribute your app for testing to friends, family and others easily. When you put the app on the Play Store you can also restrict it. If you think there could be major compatibility issues then make it available only a small subset of countries/carriers/devices and increase as you get more comfortable.
See this talk https://www.youtube.com/watch?v=Erd2k6EKxCQ (22 minutes in if you want to skip the big picture) for how you can preview your UI across a multitude of languages and form factors.
There are places that let you test with devices remotely. This is especially useful if you need to check things out in other countries. One example is http://www.perfectomobile.com (not an endorsement). Samsung also has something http://developer.samsung.com/remoteTestLab.do
You can easily outsource testing too if it matters that much to you.
A good source of devices is http://swappa.com
I personally use 6 devices. G1 (Android 1.6), HTC something (Android 2.1), Droid (Android 2.2), different Droid (Android 2.3), Galaxy Tab (Android 4) and Galaxy Nexus (Android 4.1).
You can certainly start out supporting only a subset of Android versions (eg 2.3 onwards) and then based on user feedback figure out where to go next.
As for testing, things can be easier. Unlike iOS provisioning profiles you can give the application package (apk) to anyone and they can sideload it onto their device (even from following a web browser link). They just have to change one setting to allow this. This means you can distribute your app for testing to friends, family and others easily. When you put the app on the Play Store you can also restrict it. If you think there could be major compatibility issues then make it available only a small subset of countries/carriers/devices and increase as you get more comfortable.
See this talk https://www.youtube.com/watch?v=Erd2k6EKxCQ (22 minutes in if you want to skip the big picture) for how you can preview your UI across a multitude of languages and form factors.
There are places that let you test with devices remotely. This is especially useful if you need to check things out in other countries. One example is http://www.perfectomobile.com (not an endorsement). Samsung also has something http://developer.samsung.com/remoteTestLab.do
You can easily outsource testing too if it matters that much to you.
A good source of devices is http://swappa.com
I personally use 6 devices. G1 (Android 1.6), HTC something (Android 2.1), Droid (Android 2.2), different Droid (Android 2.3), Galaxy Tab (Android 4) and Galaxy Nexus (Android 4.1).
You can certainly start out supporting only a subset of Android versions (eg 2.3 onwards) and then based on user feedback figure out where to go next.
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.
This looks really great. Very clever!
Awesome!! Care to share any technical details on how this was done for newbies like me? Thanks!
Awesome! In my opinion a killer feature would be to add sharing/embedding support.
Such a bummer, getting number 1 on HN and can't show your product...
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.
We're scaled up to meet the current load now, if you want to check it out.
I wish I had this when I was doing Android development last year
Couldn't get it to work in Firefox 16.