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."
The author clearly needs to get his terminology straight.
What he describes is more like a "bridge" between the computer and the android device, than a "simulator".
If Pandora's box is destined to be opened, *I* want to be the one to open it.
Can't http://www.android-x86.org/ be used in one of avaialable VM frameworks?
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?
Android runs on java code. It seemed incredibly strange to run an emulator to run a JVM to run code.
Some people encrypt by using rot-13 twice. I prefer the more secure method of using rot-1 a total of twenty six times.
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.
http://robolectric.org/
I use Jetbrains' IntelliJ IDE for Android development. Using it I can debug using an actual tablet plugged in via USB. Shift-F9 brings the project up to date, packages it up, ships it over USB to the tablet, and relaunches it. You can set breakpoints, step through your app, look at variables, in short, everything you could do if it were a native local app. AND at the full speed of your tablet. The ONLY way to debug Android apps.
Android is playing catch up
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
What he calls a simulator is actually an emulator.
Simulators simulate (coincidence?) the internal state of the target.
Emulators are just a layer that has the same external interface as the target.
A simulator can be an emulator, but an emulator doesn't need to be as detailed as a simulator, and therefore be much faster.
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).
I have had issues in development before where the ios simulator produces different results to that of a real device. Simulation surely must be more prone to programmer error than faciltiating emulation. Is it really that great of an idea having to update and maintain your simulation with each new release rather than just offering the emulation (with perfomance tradeoff) to your developer community?
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.
When working on IOS the fact that it only have a simulator instead of an emulator forces you to test on physical devices as a non-trivial app build for and tested on the simulator sometimes do not work on the real thing.
So if the author has written: OSX needs and IOS Emulator I would have agreed. But the points the author mentions is completely unrelated to my somewhat extended experience with mobile development.
http://www.socketeq.com/
Intel's x86 emulator.
No, Android does not need a simulator, nor an emulator ...
It needs a s T imulator !
I think that, in theory, a Android x86 version (http://www.android-x86.org/) running on a coLinux version (http://www.colinux.org/), or, perhaps, if coLinux is not viable because running directly on Windows, then use a low overhead virtualization (perhaps paravirtualization like Xen).
Seems like we should start measuring developer productivity in some meaningful way before we start claiming that it will rise dramatically.
Let me personally thank the cunt who modded my post down.
Since you are a fucking moron, please mod this post down too. When a shithead like you wastes all their mod points, the overall moderation on slashdot gets marginally better as a result.
I didn't even bother reading the article, because what I need as a developer is an emulation of an actual, specific Android device, not a generic stock emulator with a skin. I know my app works on generic stock Android. I need to test on a Samsung, Nexus, Nook, etc tablet. I have a desk full of tablets for that reason. The emulator does not emulate fragmented devices. Sure, there's a "Nook" emulator, but it's just a skin over the generic stock Android emulator (or was the last time I used it). The generic stock emulator does not emulate the quirks and gotchas of specific devices with their software.
What I need as a developer is when someone sends a tech support issue to me, I can use the emulator to dial up that specific hardware and version, and then load my app on it and test. I also need emulated access to old versions of devices to mirror real-world debugging.
Google could require an emulator image for each device that buys into their Google Play walled garden. Anything to help me with fragmentation.
wah
There is plenty of alternatives for Android development outside of java. Scala, Clojure, Xtend, Kotlin. They are all decent languages, probably even nicer than Go.
Google could require an emulator image for each device that buys into their Google Play walled garden. Anything to help me with fragmentation.
Sounds nice, until you get cases of "works on their emulator but not on the actual device."
To test performance you need actual devices anyway. On the other hand, most apps don't seem to do very fancy stuff. Those developers should simply write assuming large variation in screen size - and perhaps test on a single phone and a single pad. And it will then work for most devices. Occationally you'll get a bug report for some device and decide if it is worth it to buy one of those and fix it.
Pretty simple and super fast. Now, I suppose that the Android Development environment could include a stripped down virtual machine, but no one has done it yet (I think the current emulator uses QEMU to actually emulate ARM). http://kamyanskiy.blogspot.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.
Nothing is stopping you.
Apache 2.0 please.
I am very small, utmostly microscopic.
Libgdx nails the development cycle -- native libraries for Mac/PC/Linux/Android/iOS means that you can easily debug things on a development platform and have it work as expected on the target platform. On the downside, it does not include support for any of the Google APIs so you are SOL if you rely heavily on them.
Blackberry uses full VMware to run a simulator of the BB10 operating system when you use the BB10 IDE.
Blackberry gets it.
To get all the shit out. If anything is full of shit it is Android. /. we already know is WAY BEHIND on its enemas.
I am a web developer, now working on Android.
I use Android Studio (far better than Eclipse). With HAX - hw accelerated execution - enabled and emulator running in fast virtual mode I don't notice much difference between any run/debug on any virtual device and debug/run on a Weblogic/Websphere/Tomcat server on top of some CMS/Commerce Engines.
Both are slow, but not unreasonably slow.
May be when the apps get complex there might be a difference.
I don't see how a simulator will make a huge difference, but I can see how upgrading from my current i3 processor to an i7 and running the whole shebang on some type of RAM DISK might make a difference.
Tat Tvam Asi
Wed 6/18/2014 8:25 am. OK *I* will define the terms: "emulator" is a device using *actual hardware* that allows a developer to see how a program looks in the device and debug it. "simulator" means a "software" mechanism for doing the same thing *without* hardware. Wharton's supposed-emulator he complains about is a "hardware simulator": it *simulates* the hardware by running the Android code in some kind of virtual thingey, but it's still software executing instructions. His preferred faster supposed-simulator is something that runs the Android java code on the developer's PC, which is obviously faster/better but, as he notes, isn't good-enough for final testing. As far as I know his "emulator" hardware-simulator isn't good-enough either, and I presume there are gadgets that somehow load your program into an actual android phone, which for some reason he doesn't mention. I'm pretty-sure there were for the iphone also. jgo * owenlabs.org
Someone needs a snickers
I hate to disagree with Wharton (look up his work, the man is a champion) but the Android emulator has already been fixed with HAXM. It's been released into the SDK Manager and only requires copying a file to turn on. Once it's on, the emulator runs at totally acceptable speeds, and provides a much richer environment than a simulator would.
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 I do program professionally. What I mean to say is I don't write iPhone/Android or other Mobile apps professionally.
Leave the gun, take the cannoli -- Clemenza, The Godfather
Simulators and emulators still aren't as good as the real device. You an argue all you want about why you need one over the other but at the end of the day you really just need to load the app on a device and test it in a working environment
Android needs to make it much simpler. I don't want to spend a ton of time configuring a OS. Provide some premade vm's for the Google devices and I can use real devices for the other testing. Make it easier for me to get QA and Business users to do testing, and not a major headache that eclipse setup is.
The Android SDK/platform sucks big donkey dongles. I won't get into why here. But I'm an android developer and out of everything I've learned it is the worst.
At least with Qt you can write apps for every major platform, desktop or mobile. What I've done with it (successfully) is develop apps using my desktop, then add the tool chain for mobile compiler, and compile for that platform. That way, the toolkit becomes the simulator and you don't need to run your app though an emulator or simulator, which saves a surprising amount of time!
For example, using Qt, I've successfully used the camera API transparently on Linux and Android and Windows. What I mean by that is I developed a camera-using app on Linux, ran it on the phone, then ran it on windows 7, without changing the source code at all.
As far as I am concerned, no one should actually be using the Android SDK except those trivially simple apps. At best they are inferior (Activity and fragment lifecycle management is horrible), the SDKs themselves are not written using best Java practices, they lock you in to that platform (Can't run the same app on iOS and Android... or desktop).
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
How does this shit make it to the front page of /. ?
I swear you guys are losing viewers every month to this stupid shit.
Android needs to make it much simpler. I don't want to spend a ton of time configuring a OS. Provide some premade vm's for the Google devices and I can use real devices for the other testing.
Uh, that's what they do. And they give you an ARM VM to run them in.
Assuming what you really meant is that you literally want to run android in vmware, you can get android-x86, and install it to a virtual machine. Last time I did this, it even worked, more or less. Sadly, they never really finish a release, so android-x86 is never actually very good. I have however installed it on an Atom netbook before, and had everything work AFAIC(ould)T. But now you're going to have to not just build for x86, but also worry about any native libraries you're using. You're best off just using an actual device.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I am also and Android developer and this problem is already solved. Android Studio + ADB (included with Android Studio) + Genymotion. You get native speed, lots of sensors to emulate and can even install the gapps packages if you need to test against those libraries (I use them for Chromecast support).
Unstable Apps: Our Android Apps Don't Suck
Or as Adam Sandler calls it, a "shimulator".
Some settling may occur during posting.
I agree: indeed Genymotion fills in this gap perfectly, and I recommend it strongly for any Android dev. I also found Genymotion devs to be amazingly prompt in responding to bug reports. (I have no connection the company, am just a fan of their work.)
But it's still surprising the that official Google toolkit doesn't have anything like it. Google, get on board! Just buy up Genymotion or license their tech.
By the way, emulation still has its uses in some cases... it's of course best to have both.
Unless you have at the very least a HDPI handset, XHDPI handset, MDPI tablet, HDPI tablet and an XHDPI tablet this is incredibly risky in any kind of enterprise environment. This is just the very basics of what you would need for any kind of agreeable 'on-device' test set-up and in reality it's significantly more. The test rack where I work currently has 20 actual devices and a large number of cases are still not covered. Also for test automation setting it up with physical devices is a nightmare whereas if there was a reliable, speedy simulator you could easily build test environments for most configurations (with the exception of manufacturer flavours of Android) covered and leave it overnight for automated test runs.
There are 3rd party companies you who have test racks like this that you can hook your automation server up to but 9/10 are dodgy and require you to bake in a library OR want a full copy of your code which is completely unacceptable in an enterprise environment and even then the devices are usually time-share so overnight would not even close to cover it when you're pinging automation commands to the arse end of Israel to join an oversubscribed queue and having to write in 15 second waits for even the most basic functions to confirm they've returned correctly.
A simulator would be a GODSEND (as Genymotion once was before Google fucked them over) for anyone developing apps at an enterprise level who can't simply ignore fringe cases.
Only a poor craftsman blames his tools.
Welcome to the Panopticon. Used to be a prison, now it's your home.
KVM and VMWare Player can run VMs simultaneously without any problem.
http://mikewhitmore.wordpress....
For my own development I've created an OpenGL ES 2 pipeline and run android examples directly that are JNI code. I use windows so I built a version of ANGLE with MinGW. All my work is compiled with GCC at the moment. I've also built Mesa and played around with that too. To test this system I took the Android shader example that is freely available and it runs line by line with the calls to the java logging disabled. Yes, it is much faster than an emulator but not the hardware itself (hence the "Almost Native" part in ANGLE). You can have the code too, it would take more expertise to set up the dev environment than generate the code. https://github.com/wolfspider/gles2sdl2/blob/master/main.cpp
But emulation is 10x (or more) slower than emulation...
I played with Eclipse's Emulator a little bit, but it is just too slow. I think any improvements are welcome.
--
Tech Advisor
Providing Free Software Downloads
Those are not alternatives, and are not guaranteed to be interoperable in the future. Last I looked, Scala was planning to drop support for the JVM version which Android depends on, calling into question the future of any JVM based languages on the Android platform.
I'd love it if google embraced one of those languages, and provided a first-class API, but that has yet to happen. Moreover, I don't see how it can while such languages target the latest JVM exclusively. Dalvik was created for a reason, and until such languages target it directly, this looks like a dead end.
I've looked into using Scala, and aside from the uncertain future, there are definitely issues complicating its use. While the language looks decent enough, it also appears to have a steep learning curve. Given the situation and limited application, not sure it is worth the effort.
C++, Qt + Android NDK nuff said.
So if Apple can sim run iOS apps in OSX, why cant they officially, run all iOS apps (w/arm emu) inside OSX, so that I can run full screen iPad apps in OSX, or small iOS apps as desktop widgets.
Dont give me the crap of ohh the iPhone app will look crap full screen, duhhhh , run it in a window thats scalable.
Liberty freedom are no1, not dicks in suits.
I'd like to see the same for iOS, or any mobile operating system. The amount of times I've tried online simulators and the like which take nothing into account other than the size of the window is beyond frustrating. Unless you have the device to hand (every iteration of them, at that!) then I can't see a viable way of testing for all mobile platforms.