Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Android Needs a Simulator, Not an Emulator

Soulskill posted about a month and a half ago | from the simulated-grass-is-greener dept.

Android 167

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."

cancel ×

167 comments

simulator? (1)

StripedCow (776465) | about a month and a half ago | (#47261021)

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".

Re:simulator? (2, Informative)

Anonymous Coward | about a month and a half ago | (#47261073)

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.

Re:simulator? (0)

Anonymous Coward | about a month and a half ago | (#47261293)

Did you read the article? He defines simulator as a layer between the application and the OS.
A simulator mimics the real thing but isn't. What he describes is closer to in-system debugging.
The micro-controller equivalent is called In-circuit_emulation [wikipedia.org]
The benefit of it is that you run it on a non-simulated system so it is unlikely that it will behave differently from the real thing. These days when many controllers have built-in debugging support simulators are only used in early development stages (if at all) before the real hardware exists.

Re:simulator? (2)

dmbasso (1052166) | about a month and a half ago | (#47261341)

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.

Re:simulator? (0)

Anonymous Coward | about a month and a half ago | (#47261433)

if simulator is to fake an appearance of an OS then emulator is a simulator of a HW so that OS can think there is one?

Re:simulator? (0)

Anonymous Coward | about a month and a half ago | (#47261483)

You have it exactly back asswards.
A simulator simulates how and emulator emulates what.
If I develop an exact description of the hardware down to the individual registers and control paths, that is called a simulator.
If I write some library that interprets the code and translates it somehow to run on a different machine, that is an emulator.
Modelsim: a simulator.
Qemu: an emulator.

Re:simulator? (0)

Anonymous Coward | about a month and a half ago | (#47261879)

If I develop an exact description of the hardware down to the individual registers and control paths, that is called a simulator.

By that definition all good emulators out there are simulators.

Re:simulator? (1)

drinkypoo (153816) | about a month and a half ago | (#47262069)

If I develop an exact description of the hardware down to the individual registers and control paths, that is called a simulator.

By that definition all good emulators out there are simulators.

If you simulate the logic, it's a simulator. If you don't, it ain't. If it emulates the functionality, it's an emulator. If it don't, it ain't. Arguably, a simulator is an emulator, but an emulator isn't necessarily a simulator. Some things could be referred to either way, and the choice of term would depend on the situation.

Re:simulator? (0)

Anonymous Coward | about a month and a half ago | (#47262065)

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.

I agree with the people here that are calling you an asshole.

The OP used horrible terminology. You sir, have no clue what you are talking about.

Actually, Android needs a sTimulator (0)

Anonymous Coward | about a month and a half ago | (#47261173)

No, Android does not need a simulator, nor an emulator ...
 
It needs a s T imulator !

Re:Actually, Android needs a sTimulator (1)

Mister Liberty (769145) | about a month and a half ago | (#47261207)

My takeaway from this is: handhelds need a desktop PC.
Who could've thought!!? Are you listening, Ubuntu, Gnome?!!

Android in virtual machine (1)

Anonymous Coward | about a month and a half ago | (#47261033)

Can't http://www.android-x86.org/ be used in one of avaialable VM frameworks?

x86 Android Virtualisation: native performance! (5, Informative)

thatkid_2002 (1529917) | about a month and a half ago | (#47261035)

Android is available for x86 these days and you can use hardware acceleration [android.com] (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?

Re:x86 Android Virtualisation: native performance! (2)

Lordpidey (942444) | about a month and a half ago | (#47261045)

Android is available for x86 these days and you can use hardware acceleration [android.com] (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?

One that works on most CPUs.

Re:x86 Android Virtualisation: native performance! (3, Interesting)

thegarbz (1787294) | about a month and a half ago | (#47261137)

I think what the author is referring to is an Android system which integrates into the tool chain and can be directly controlled by the tool chain / IDE.

Yes the android debug bridge exists, but it's quite a beast to use and I don't believe the authors comments refer to a problem of simply running an app on a phone.

Re:x86 Android Virtualisation: native performance! (4, Informative)

cerberusss (660701) | about a month and a half ago | (#47261203)

"Just set it up" isn't as easy as you make it out to be. I just tried it in Android Studio.

First, you have to install a 3rd party kernel extension (from Intel). Then you have to configure an AVD with the new x86 value for the CPU/ABI field. It didn't appear for some reason for my target "Android 4.4.2". After looking around, I found another download in the Android SDK Manager called "Intel x86 Atom System Image", let's download that. The documentation mentions this, but I glossed over it. OK, back to the AVD manager and create a virtual device.

Now I finish it, and run the app. Running the app takes 39 seconds, as Grails reports (about 5 seconds, if that, on Xcode for the iOS port of our project). It asks where I want to run it, pick the new AVD and click Run. It starts Android but not the app.

Weird. OK, so I run it again with the simulator running. The option "choose a running device" cannot be selected. That's strange. I pick the new AVD again and unfortunately, it starts another copy. Shit. I let it boot but notice it's really slow as usual -- ten minutes later it's still booting. I check the already running copy and click around. Slow as hell as well. Apparently it's not accelerated at all!

At this point, I'm ready to give up and go back to testing on a device again.

The above is tested on a 2013 MacBook Air with 8 gigs of memory.

Re:x86 Android Virtualisation: native performance! (4, Informative)

The1stImmortal (1990110) | about a month and a half ago | (#47261249)

How about Genymotion? http://www.genymotion.com/ [genymotion.com] - uses VirtualBox as the underlying x86 VM layer, instead of AVD + HAXM. Supports a few additional sensors too (either emulated or passed through from real hardware if it has them)

Re:x86 Android Virtualisation: native performance! (3, Informative)

sheltond (252356) | about a month and a half ago | (#47261715)

Yes. Genymotion is great.

Really fast, lots of different system images for different Android versions and device configurations (screen sizes and densities, input devices, etc), integrates nicely with adb and Eclipse (I haven't tried it in Android Studio, but I imagine it works equally well).

Re:x86 Android Virtualisation: native performance! (1)

robmv (855035) | about a month and a half ago | (#47262039)

It is a problem of the Android tools for OS X and Windows, on a Linux distribution with a compiled kernel with KVM virtualization enabled (any modern distro), you only install the x86 image and start it without any other install or configuration needed, who would have said that using Linux would be easier than Windows hehe. The only downside is that if you start using KVM VMs, other virtualization solutions like VirtualBox can not be used at the same time, so if you need a Windows VM for your daily work you must run it inside KVM or not use it at all when running Android x86 images

Re:x86 Android Virtualisation: native performance! (1)

master_kaos (1027308) | about a month and a half ago | (#47262047)

I have pretty much exact same experience. It is so unbelievable slow, I don't know how anyone does serious development with it. I keep trying to use the emulator but every single time I end up going back to just testing on an actual device. I could understand it being like this for the first year or two after android was launched, but this late in the game I seriously expect something much better.

It always did seem odd to me. (1)

Lordpidey (942444) | about a month and a half ago | (#47261049)

Android runs on java code. It seemed incredibly strange to run an emulator to run a JVM to run code.

Re:It always did seem odd to me. (2, Informative)

Anonymous Coward | about a month and a half ago | (#47261175)

Very much in Android, including application code, is not Java.

So much wrong (3, Interesting)

Anonymous Coward | about a month and a half ago | (#47261059)

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.

Re:So much wrong (1)

Anonymous Coward | about a month and a half ago | (#47261131)

Apple's simulator works very well for 90% of the apps, and if you need to use sensors, have particular graphic demands, or you're going to push the hardware to its limts, you're likely to use a real device for testing anyway.

Re:So much wrong (1)

Anonymous Coward | about a month and a half ago | (#47261313)

have particular graphic demands

My "particular graphic demands" are that I do all my drawing using OpenGL. As a result I gave up even trying to use the simulator years ago; you have no clue how it will perform on the device until you run it on the device (lowest common denominator being iPhone 3GS w/ OpenGL ES 2.0). Same goes for anything performance-oriented. And if you get a drawing bug on the simulator maybe it'll work fine on the device, and if it works fine on the simulator you might get a black screen on the device. It's hopeless as a model for the device unless you're doing all your graphics and audio through ObjC APIs.

Re:So much wrong (2)

JaredOfEuropa (526365) | about a month and a half ago | (#47261411)

That's a fair point. However, to what extent do these issues exist because the iOS simulator is a simulator rather than an emulator? An emulator might have broken OpenGL support, same as the simulator. And for performance-related stuff I'd prefer a real device over either.

By the way, the author of that article does not IMHO make a strong point for simulators. He seems to have a lot of problems with the Android development environment, some related to performance and reliability but many related to usability, and the reason the emulator has these problems is not the fact that it's an emulator. An equally crappy simulator isn't going to solve those problems.

Re:So much wrong (1)

Immerman (2627577) | about a month and a half ago | (#47261551)

Would not an emulator be far more likely to run the actual device OS and APIs? If the software libraries are the same then the emulator is simply a standard device running on virtual hardware, and can be expected to be as compatible with real hardware as various hardware devices are with each other.

Re:So much wrong (0)

Anonymous Coward | about a month and a half ago | (#47261331)

Apple's simulator works very well for 90% of the apps

BTW, 90% of apps are games so your comment is backwards. Apple's simulator works very well for 10% of apps. No-one doing game development on anything approaching a pro level is using the simulator, and I suspect the same is true of app development generally, especially since most of the interesting apps do use sensors, or have graphics demands, or push the hardware to its limits - often all three at once.

But sure you can write a me-too diary app in the simulator.

Re:So much wrong (0)

Anonymous Coward | about a month and a half ago | (#47261521)

Androids emulator works very well for 99% of the apps, and if you need to use sensors, have particular graphic demands, or you're going to push the hardware to its limts, you're likely to use a real device for testing anyway.

Re:So much wrong (4, Insightful)

JaredOfEuropa (526365) | about a month and a half ago | (#47261195)

Virtually nothing? I'd say that the simulator covers about 95% of my testing and diagnosis needs. I only have to resort to running on a physical device when I have to test stuff related to the on-board sensors, camera, or push notifications. So far I've found 1 case where the simulator did not behave as expected. If it works on the simulator, chances are it'll work on the device. If it doesn't work on the simulator, in almost all cases you will be able to use the simulator to diagnose and fix the issue. I should note that I do not do game development; I've no experience in writing apps with high performance 2d/3d graphics.

With that said, I always test release candidates on various types of real devices.

Re:So much wrong (1)

Anonymous Coward | about a month and a half ago | (#47261261)

I should note that I do not do game development; I've no experience in writing apps with high performance 2d/3d graphics.

Well, then, when you try doing those things you'll understand why my comment is true.

Re:So much wrong (4, Informative)

coinreturn (617535) | about a month and a half ago | (#47261385)

I should note that I do not do game development; I've no experience in writing apps with high performance 2d/3d graphics.

Well, then, when you try doing those things you'll understand why my comment is true.

Well, I won't. I have five games in the App Store and I have always used the simulator for development. It works very well. For me, it is VERY rare that something works on one while not working on the other.

Re:So much wrong (0)

_xeno_ (155264) | about a month and a half ago | (#47261757)

Bullshit. You don't even need to be doing game development for the simulator to be useless.

Every experience I've had with the simulator has been that it's entirely useless for determining how the code will run on a real device. I mean, hell, you don't even have actual iOS running on the simulator, you're running a Mac OS X binary!

The simulator is effectively WINE for iOS: it reimplements the iOS APIs under Mac OS X, and the toolchain compiles an x86 binary instead of an ARM binary. No one should have to explain why that's entirely useless for trying to build an ARM app on iOS.

It isn't just game development. I had a bog-standard iOS app that was a very simple UI in front of a website. Try it in the simulator and it seems nice and snappy. Try in on a real device, and it's slow as molasses and nearly unusable.

Why? Because it turns out some code being run in the UI thread was excessively slow. So it had to be moved out to a new thread. (Which, arguably, it should have been anyway, but I'm not the guy who wrote the original code.) But on x86, it was fast enough that no one even noticed.

I remember optimizing said chunk of code so that it ran in around 0.2 seconds on the simulator - and took nearly a minute on an actual device.

The simulator is entirely useless for developing an actual app.

Re:So much wrong (1)

rjstanford (69735) | about a month and a half ago | (#47261805)

The simulator is very useful for developing all sorts of apps. The fact that it didn't work well for yours because it was hiding some poorly optimized code doesn't mean that a huge majority of apps don't benefit from it.

Most apps in the app store are not the latest and greatest video epic.

If you had a "bog-standard iOS app that was a very simple UI in front of a website" that has complex long-running code in the UI thread, or for that matter complex code that takes "nearly a minute" to run in the first place, well ... that's not the simulator's fault.

Re:So much wrong (0)

Anonymous Coward | about a month and a half ago | (#47262067)

If you had a "bog-standard iOS app that was a very simple UI in front of a website" that has complex long-running code in the UI thread, or for that matter complex code that takes "nearly a minute" to run in the first place, well ... that's not the simulator's fault.

"It's not the simulator's fault that your code ran fine in the simulator and poorly on the device"... I think you might want to consider what possible use a "simulator" could be if not to act like a device. Do airline pilots find it useful to train in flight "simulators" that run Snoopy Flying Ace for Xbox? Because you are suggesting that it would be their fault when they crashed their 747 into a hangar after thinking that the trip would always start out with them flying straight and level at 1000'.

Anyway, LOL +1 Apologist.

Re:So much wrong (1)

_xeno_ (155264) | about a month and a half ago | (#47262077)

If you had a "bog-standard iOS app that was a very simple UI in front of a website" that has complex long-running code in the UI thread, or for that matter complex code that takes "nearly a minute" to run in the first place, well ... that's not the simulator's fault.

But the fact that it hid it until someone finally tried it on a device is the simulator's fault.

And you've never had websites that did anything even somewhat complicated in JavaScript, huh? Since you aren't allowed to run interpreted code on iOS, it had to be redone in Objective-C, and the initial version turned out to be very slow. (Think "charting.")

I mean, sure, we could have just embedded a webpage and done it that way, but the existing JavaScript was already unacceptably slow or we wouldn't be looking at making an iOS app, now, would we?

Re:So much wrong (0)

Anonymous Coward | about a month and a half ago | (#47261813)

Not really... if you notice that game dev is one small corner of dev in general, you'll understand why his 95% comment is true.

Note, an emulator doesn't even fix the perf issue with games, so in fact shipping an emulator wouldn't help at all here.

Re:So much wrong (1)

master_kaos (1027308) | about a month and a half ago | (#47262071)

I make more business apps and I rarely see any differences between actual device and simulator. Sure, once in a while something behaves slightly differently but not enough for me to want something that will run much slower.
I know I can code up 99.5% of it with the simulator, the last .5% I may need the device.

Now this is just somewhat basic apps, not using any sensors or graphics.

Robolectric (0)

Anonymous Coward | about a month and a half ago | (#47261065)

http://robolectric.org/

Emulator? Simulator? Pfffttt... (1)

Anonymous Coward | about a month and a half ago | (#47261067)

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.

Re:Emulator? Simulator? Pfffttt... (3, Insightful)

kav2k (1545689) | about a month and a half ago | (#47261143)

Great. Now, do you have a spare tablet around for every target android version?

Re:Emulator? Simulator? Pfffttt... (2, Informative)

Anonymous Coward | about a month and a half ago | (#47261181)

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.

Re:Emulator? Simulator? Pfffttt... (0)

Anonymous Coward | about a month and a half ago | (#47261877)

That's the problem that we found with developing games for the PC. We had to employ a whole team to have them order and setup a model of every desktop model ever sold. The rise of the cheap clone made this even harder.

The upside was we ended up with a database of every computer shop in the country so we could call them each monthly to find out if they had sold a new model or a new configuration.

In the end, the cost of both equipment and the space to house it (not to mention the antivirus software licenses) became prohibitive and we had to close up shop.

Even Firefox OS has a simulator (1)

Anonymous Coward | about a month and a half ago | (#47261071)

Re:Even Firefox OS has a simulator (1)

ubersoldat2k7 (1557119) | about a month and a half ago | (#47261135)

This was one of the best features I found when developing apps for FirefoxOS. 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.

Re:Even Firefox OS has a simulator (2)

rjstanford (69735) | about a month and a half ago | (#47261815)

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?

Surrprised it is so hard (2)

MichaelSmith (789609) | about a month and a half ago | (#47261083)

Android apps already run on Linux. Why can't I just fire them up on Ubuntu? The VM should br portable.

Re:Surrprised it is so hard (2)

StripedCow (776465) | about a month and a half ago | (#47261101)

Perhaps if your PC runs on an ARM processor, it would be simple.

I'm not sure Ubuntu has an ARM iso.

Re:Surrprised it is so hard (1)

MichaelSmith (789609) | about a month and a half ago | (#47261111)

It would be pretty poor if the VM couldn't be compiled for i686 or AMD64.

Re:Surrprised it is so hard (0)

Anonymous Coward | about a month and a half ago | (#47261119)

a raspberry pi uses a arm CPU and it runs various flavours of linux would that not be a possibility to run your code on?

Re:Surrprised it is so hard (2)

c (8461) | about a month and a half ago | (#47261159)

Perhaps if your PC runs on an ARM processor, it would be simple.

ARM emulation under x86 is feasible. Google "libhoudini". Whether it's simple is another question, but the pieces are there.

Re:Surrprised it is so hard (1)

viperidaenz (2515578) | about a month and a half ago | (#47261167)

Of course Ubuntu supports ARM
http://www.ubuntu.com/download... [ubuntu.com]

I run Debian on my ARM board.

Re:Surrprised it is so hard (1)

hairyfeet (841228) | about a month and a half ago | (#47261471)

Go to any Chinamart site and you can pick up an ARM dual core desktop box for less than $50 USD and while they come with Android from what I understand most can run Debian as well so if you need an ARM box to do your coding on they really aren't hard to come by.

Re:Surrprised it is so hard (0)

Anonymous Coward | about a month and a half ago | (#47261287)

This guy got the dalvick vm working in Xubuntu ..
https://plus.google.com/+KrzysztofKlinikowski/posts/cMfGkqLVUwX

Re:Surrprised it is so hard (1)

serviscope_minor (664417) | about a month and a half ago | (#47261453)

Android apps already run on Linux. Why can't I just fire them up on Ubuntu? The VM should br portable.

I've wondered this too.

I guess one would have to provide an X11 based inpout and output driver for the graphics stack, at the minimum and run it in a chroot.

To make it good, you'd probably have to bridge notifications between the two systems.

Given it sounds easy and hasn't been done, I strongly suspect it is much harder than it ought to be. Given that most bits of android end up seeming wierd and badly designed when you look closely, I imagine there's something really nasty under the hood stopping it working well and easiy.

Also needs a language not Java... (-1)

Anonymous Coward | about a month and a half ago | (#47261087)

For me, the lack of a decent language is a far greater barrier. Go would be nice. Anything would be better than Java.

Re:Also needs a language not Java... (1)

abies (607076) | about a month and a half ago | (#47261371)

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.

Does this guy know what he's saying? (0)

Anonymous Coward | about a month and a half ago | (#47261089)

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.

Re:Does this guy know what he's saying? (0)

Anonymous Coward | about a month and a half ago | (#47261837)

No, it's not an emulator. An emulator simulates the CPU state of the ARM chip in the device. What this is is simply a reimplementation of the iOS/android APIs for Mac/Win/Lin, so that you can compile, and run on those platforms. It is no more an emulator than WINE is.

Desktop integration (5, Insightful)

Anonymous Coward | about a month and a half ago | (#47261093)

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).

Re:Desktop integration (2)

Mister Liberty (769145) | about a month and a half ago | (#47261215)

Guess the project of your dreams needs a Summer of Code at Google.
Propose, propose, propose...

Re:Desktop integration (1)

Parker Lewis (999165) | about a month and a half ago | (#47261827)

I always wonder the same. But probably the answer is Canonical wants its own Linux phone than powerful integration with Android. Should be, in current days, a killer flag: "hey, my Linux distro runs Android apps, and integrates smoothly with Android phones".

Re:Desktop integration (1)

psionski (1272720) | about a month and a half ago | (#47261929)

What does Canonical have to do with anything?

Re:Desktop integration (1)

Parker Lewis (999165) | about a month and a half ago | (#47261971)

Most popular desktop Linux distro.

Fuck off beta (-1)

Anonymous Coward | about a month and a half ago | (#47261107)

That's my comment. Fuck Beta. Stop forcing it down my fucking throat with auto-redirects.

Re:Fuck off beta (0, Offtopic)

Anonymous Coward | about a month and a half ago | (#47261303)

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.

Re: Fuck off beta (0)

Anonymous Coward | about a month and a half ago | (#47261361)

wah

Re:Fuck off beta (1)

Anonymous Coward | about a month and a half ago | (#47261651)

Someone needs a snickers

Simulation can be prone to errors and inconsitenci (1)

Spaghetti Stallion (2732147) | about a month and a half ago | (#47261109)

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?

I just use a real Android device (4, Insightful)

rklrkl (554527) | about a month and a half ago | (#47261145)

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.

Re:I just use a real Android device (1)

batkiwi (137781) | about a month and a half ago | (#47261171)

Honest question, I haven't tried, but do breakpoints work when you're running on the device itself?

(Eg does it have a remote deploy/debug over USB mode?)

Re:I just use a real Android device (5, Informative)

Threni (635302) | about a month and a half ago | (#47261209)

Yes. You can step through the code on your device from your pc. (Even if connected over wifi. Which is nice, when it works, but it's a little flakey. It's solid over USB though).

Re:I just use a real Android device (2)

GNious (953874) | about a month and a half ago | (#47261187)

I have my jolla development set up to simply send any program I working on straight to a phone, and run there as part of the compile+run procedure.

With SSH access, QTCreator is basically SSH'ing in, deploying+running the app, and giving feedback straight back to my screen, while I have a separate shell running with SSH into the phone and while I'm reviewing the behaviour of the app directly on the phone.

No need for simulators, emulators or other -mulators :)

Re:I just use a real Android device (0)

Anonymous Coward | about a month and a half ago | (#47261247)

If your device is rooted you can even run adb over wifi and connect with the following command: "adb connect :".

I have written an indicator for Ubuntu some time ago that I use for my development work on Android:
http://forum.xda-developers.com/showthread.php?p=41446261#post41446261

Re:I just use a real Android device (1)

bluescrn (2120492) | about a month and a half ago | (#47261265)

Deployment to devices gets rather slow when dealing with large apps (e.g. games with lots of assets), though. Slow iteration time kills productivity. I want the absolute minimum time between editing a line of code and being able to test/debug that line of code.

This is partly BS (0)

Anonymous Coward | about a month and a half ago | (#47261147)

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.

Jack Wharton is a Whiner (-1)

Anonymous Coward | about a month and a half ago | (#47261157)

Jake Wharton needs to buy an actual android phone and use that as a test platform through usb. Untill he does he's just a whiner.

So he wants this (0)

Anonymous Coward | about a month and a half ago | (#47261169)

Better emulate x86 from x86 (0)

Anonymous Coward | about a month and a half ago | (#47261183)

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).

Productivity (0)

Anonymous Coward | about a month and a half ago | (#47261275)

Seems like we should start measuring developer productivity in some meaningful way before we start claiming that it will rise dramatically.

No, what devs need is specifc device emulation (0)

Anonymous Coward | about a month and a half ago | (#47261321)

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.

No, what devs need is specifc device emulation (0)

Anonymous Coward | about a month and a half ago | (#47261375)

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.

Eclipse + VirtualBox + x86 Android image (1)

jpswensen (986851) | about a month and a half ago | (#47261403)

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... [blogspot.com]

Re:Eclipse + VirtualBox + x86 Android image (-1)

Anonymous Coward | about a month and a half ago | (#47261491)

You're all stupid and ill-informed.

The Android SDK has come with an x86 'emulator' alongside the ARM one since at least ICS. It runs fast, and is only a problem if you want to test real sensors and such.

Infact, the x86 emulator is a good way to check native code (if you use if).

Re:Eclipse + VirtualBox + x86 Android image (1)

jpswensen (986851) | about a month and a half ago | (#47261595)

How exactly do you launch the x86 android emulator? When I go to the Android Virtual Device Manager and try every single one of the options in the "Device:" pulldown menu and subsequently try to change the "CPU/ABI:" pulldown menu, the only option is "ARM (armeabi-v71)". So, if such an option exists, they sure make it hard to find (or I am just stupid and ill-informed, so please inform me).

Re:Eclipse + VirtualBox + x86 Android image (1)

jpswensen (986851) | about a month and a half ago | (#47261639)

Actually, maybe I am stupid and ill-informed. There were a couple that had CPU/ABI option as "Atom(x86)". However, it has now been about 4 minutes on my 8 core i7 machine with 6GB of RAM, running nothing but ADT, the emulator, and this web browser and Android is yet to finish booting inside the emulator even running the "Atom(x86)". With VirtualBox + x86 Android images, even from cold boot it takes maybe 40 seconds and if I resume from a paused VM it takes seconds. Now at minute 6 and the ADT emulator still hasn't finished loading. Conclusion, VitrualBox+x86 Android images is infinitely better.

Toooooo Slooooow (3, Interesting)

EmperorOfCanada (1332175) | about a month and a half ago | (#47261415)

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.

So write it, John (0)

gatkinso (15975) | about a month and a half ago | (#47261449)

Nothing is stopping you.

Apache 2.0 please.

libgdx does this right (0)

Anonymous Coward | about a month and a half ago | (#47261527)

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.

Hey, Blackberry does somethign right! (0)

Anonymous Coward | about a month and a half ago | (#47261539)

Blackberry uses full VMware to run a simulator of the BB10 operating system when you use the BB10 IDE.

Blackberry gets it.

NEEDS AN ENEMA (0)

Anonymous Coward | about a month and a half ago | (#47261543)

To get all the shit out. If anything is full of shit it is Android. /. we already know is WAY BEHIND on its enemas.

Emulator with HAX (1)

bayankaran (446245) | about a month and a half ago | (#47261615)

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.

emulator vs simulator (0)

Anonymous Coward | about a month and a half ago | (#47261633)

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

HAXM (1)

Graydyn Young (2835695) | about a month and a half ago | (#47261685)

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.

The resistance to this idea is surprising (4, Interesting)

iPaul (559200) | about a month and a half ago | (#47261721)

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.

The resistance to this idea is surprising (1)

iPaul (559200) | about a month and a half ago | (#47261729)

Actually I do program professionally. What I mean to say is I don't write iPhone/Android or other Mobile apps professionally.

Just use a phone...... (1)

Murdoch5 (1563847) | about a month and a half ago | (#47261741)

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

Where is the vmware app? Need simple testing (1)

dczyz (239366) | about a month and a half ago | (#47261763)

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.

Just use Qt, or PhoneGap (1)

scorp1us (235526) | about a month and a half ago | (#47262021)

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).

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...