Slashdot Mirror
Android Needs a Simulator, Not an Emulator
An anonymous reader writes Jake Wharton, Android Engineer at Square, has written an article about one of the big problems with building apps for Android: developers need a simulator for testing their software, rather than an emulator. He provides an interesting, technical explanation of the difference between them, and why the status quo is not working. Here are the basics of his article: "A simulator is a shim that sits between the Android operating system runtime and the computer's running operating system. It bridges the two into a single unit which behaves closely to how a real device or full emulator would at a fraction of the overhead. The most well known simulator to any Android developer is probably (and ironically) the one that iOS developers use from Apple. The iPhone and iPad simulators allow quick, easy, and lightweight execution of in-development apps. ... There always will be a need for a proper emulator for acceptance testing your application in an environment that behaves exactly like a device. For day-to-day development this is simply not needed. Developer productivity will rise dramatically and the simplicity through which testing can now be done will encourage their use and with any luck improve overall app quality. Android actually already has two simulators which are each powerful in different ways, but nowhere near powerful enough."
Android is available for x86 these days and you can use hardware acceleration (CPU and GPU). Just set it up and get near-native performance. Or if you have an Android phone just `adb install -r blah.apk` what more can you want?
Apple's simulator is unusable because it's a simulator. If it works on the simulator it tells you virtually nothing. If it doesn't work on the simulator it tells you virtually nothing. You need to run on the actual device. Oh what I wouldn't give for an emulator where if it ran on the emulator it would be some guarantee to run on the real device too, and if your code doesn't run on the emulator it would be some guarantee your code was broken (not that the simulator just doesn't support some feature).
So yes, let's applaud Apple's cheap-ass simulator approach which is unusable, and emulate it [heh] on Android.
You clearly need to get your terminology straight.
What you describe as a "bridge" is more like a house for homeless people.
But simulator is the correct terminology... the way you might want to implement it doesn't make any difference.
Android apps already run on Linux. Why can't I just fire them up on Ubuntu? The VM should br portable.
http://michaelsmith.id.au
Given the open source nature of Android, what I don't understand is how no project so far has integrated the Android runtime with the Linux desktop. Licencing issues maybe? Leave it in a separate PPA.
It would be amazing to be able to run Android applications in Linux seamlessly, ideally integrated with the indicators and notifications provided by the OS.
That would be a killer feature (and would expand the library of games available for Linux by 1,000,000%), in addition to other applications.
I know it is possible to emulate Android, there are some options for this, but it is not about emulating a phone in my computer; I already have a phone. What I would love is to run Android apps in it (of course, as long as that software includes x86 libraries, or there is an emulation layer available).
Great. Now, do you have a spare tablet around for every target android version?
Whilst playing around a little with Eclipse and the Android SDK, I found it much easier to just plug in my Android tablet (or it could be an Android phone or both) and download/run the app on that. You get to check rotation, multi-touch, camera etc. a lot more easily this way and it's just as easy (if not more so) than running the emulator. Of course, there could be Android devs without any Android devices at all, but I suspect that's a tiny minority.
The main use of the emulator is probably just to test different screen dimensions render OK - I personally wouldn't use it during the bulk of development though.
Very much in Android, including application code, is not Java.
Great. Now, do you have a spare tablet around for every target android version?
This is the general problem with Android in any case, since versions are not kept up to date on all devices, not all devices have the same resolution, CPU capabilities, graphics performance, input devices, cameras, accelerometer, GPS hardware, touch screen capability, keyboards, and so on and so on.
You will always need to test on the actual hardware to be sure your monster Intel box and nVidia video cards aren't giving you a false idea of how fast your app is, or that your app doesn't suck, or that it'll work with a particular device.
If you need hit over the head with a clue bat, ask Roxio how they do it for Angry Birds testing.
Did you read the article? He defines simulator as a layer between the application and the OS.
I didn't RTFA, but let me point out that his definition is one way to implement a simulator. Let me summarize it for you:
Simulator: functionality, what it does.
Emulator: function, how it does.
A simulator mimics the real thing but isn't.
Both do it, only the objectives are different.
`echo $[0x853204FA81]|tr 0-9 ionbsdeaml`@gmail.com
I have a bonkers fast machine with SSD, gobs of memory, CPUs on fire, etc. Yet running the android emulator is go off and make a sandwich time.
I do 100% of my testing on actual devices which is not at all how I work with iOS. With iOS I only occasionally test my code on an actual device as there are occasional differences between the simulator and the actual devices.
Also the android is all about settings, settings settings, instead of asking me if I have a keyboard, GPS, etc. What I would like is a list of the most popular phones. Then I could try out my code on those very phones. Also it would be great if someone had a problem with my app on a specific phone and I was able to quickly select that phone and try out my code.
I get a feeling that the emulator was not so much aimed at developers of apps but aimed at hardware and OS developers who need this magically perfect emulation. Whereas the iOS Simulator is quite clearly aimed at people who are developing apps. Which oddly enough would be 99.999% of the potential audience.
As I read the comments I find it surprising that people somehow object to this idea because 1) they don't like the terminology, 2) the say the existing emulator is just fine, 3) Apple sucks, 4) If you just do these 37 steps, it works awesome on my machine and 5) did I mention Apple sucks?
I don't program professionally but I am a tinkerer and I did try my hand at both iOS and Android development. As a noob in both, I found the Apple environment much easier in terms of usability. This is not a plug for Apple, but an observation about how fast the tool chain is able to launch the simulator and step into live, running code. There are obviously things that won't work, but I was able to get going quickly and play with the examples. It was also relatively painless (although there was a lot of hoop jumping) to get the code onto my phone and running.
I like the Jet Brains based Android development environment. It's really nice to work it but when it comes to actually running the code you wrote, you basically need a real device. The emulator start up time is horrible and the performance while running is terrible. I've tried to get the x86 ABI running on my machine but I didn't notice much of an improvement. Yes, yes, I know, but Apple sucks. I would call the emulator borderline unusable for development and almost not usable for testing because of its bad performance.
I'd like to try some of the resources he mentioned in the article, but I only found out about them two minutes ago when I read the article. As a noob, I didn't even know they existed. Tools do matter. As Microsoft and Apple have found out, creating really nice development environments is important in capturing mind share. At some point every developer is a noob at something and making easier for the noobs to get going is part of making a platform sticky.
So let the grammar corrections, the Microsoft sucks, the Apple sucks comments come. It doesn't change the fact that being productive isn't just about which APIs you can memorize, but also about the toolchains and environments you use to write code.
Leave the gun, take the cannoli -- Clemenza, The Godfather
Actually, you don't really need much of the FirefoxOS when doing the design job since the HTML/CSS will render with Firefox quite exactly as it would in any FirefoxOS phone.
What, both of them?
You're special forces then? That's great! I just love your olympics!
And what really sucks is that sales on android are 15% of what is on iOS anyways, yet testing is 10x more on android vs apple. We have about 10 apps in apples app store, and we only have are 2 flagship apps on android. We don't bother testing on every device, I'll test on 3 separate devices and a bunch of emulator configs. Once in a while we get a negative review of "crashes on device x running y" but nothing we can do except refund because we arent blowing out our brains buying every device, nor do we have the funds to.