Live data from Hacker News

A better Android emulator

manymo.com

21–30 of 58 posts

Re: A better Android emulator

#21

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

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.

Re: A better Android emulator

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

Re: A better Android emulator

#23

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.

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.

Re: A better Android emulator

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

Re: A better Android emulator

#26

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

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.

Re: A better Android emulator

#27

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.

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.

Re: A better Android emulator

#28

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.

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.

Re: A better Android emulator

#29
post #23

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.

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…

highest density of good advice i've seen in a long time

Re: A better Android emulator

#30

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/

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

I didn't know this, I'll try it out, thanks!
Post reply on HN