Slashdot Mirror

← Back to Stories (view on slashdot.org)

Android Needs a Simulator, Not an Emulator

Posted by Soulskill on from the simulated-grass-is-greener dept.

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

104 of 167 comments (clear)

  1. simulator? by StripedCow · · Score: 1

    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.
    1. Re:simulator? by Anonymous Coward · · Score: 2, Informative

      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.

    2. Re:simulator? by dmbasso · · Score: 2

      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
    3. Re:simulator? by drinkypoo · · Score: 1

      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.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    4. Re:simulator? by dmbasso · · Score: 1

      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.

      Ah, I see, when I control a virtual airplane the program is behind the scenes calculating all the mechanical, electrical, and {aero,hydro}dynamical forces, from the engine, from the control cables, from the landing gear, from everything, all the time, so we can call it a flight simulator. Oh wait, it doesn't! It just makes a rough estimate of the aerodynamical forces, to what you would expect it to behave. Then according to your (wrong) definition, we should call it a flight emulator.

      --
      `echo $[0x853204FA81]|tr 0-9 ionbsdeaml`@gmail.com
    5. Re:simulator? by ultranova · · Score: 1

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

      That would be called documentation, actually :^).

      An emulator is a simulator that simulates another computer (an algorithm that's Turing complete - that is, can be made to compute any computable algorithm with the right input). A simulator is an emulator that emulates some non-computer process. And the only thing a Turing machine can do is run one of these.

      The article is talking about a faster but less accurate emulator and calling it a simulator for whatever reason.

      --

      Forget magic. Any technology distinguishable from divine power is insufficiently advanced.

    6. Re:simulator? by dmbasso · · Score: 1

      According to Wikipedia and vocabulary.com:

      Simulation
      Simulation is the imitation of the operation of a real-world process or system over time.

      Emulation
      In computing, emulation is the technique used so one machine gets the same results as another.

      So I stand by everything I've said, including that you're wrong.

      --
      `echo $[0x853204FA81]|tr 0-9 ionbsdeaml`@gmail.com
    7. Re:simulator? by Darinbob · · Score: 1

      This is more of an platform simulator, something that an application can run on in mostly the same way it would on the real device.

      From my perspective, I find the opposite problem. Too often all I see are simulators, and the application people are happy, but emulators are what is rare and far more practical for uncovering actual problems in the lower level code. Ie, a simulator often runs a task to completion, whereas an emulator may have preemptive context switches that causes things to break if the application doesn't use proper mutexes and critical sections.

      It also really depends upon what you're simulating, is it just a very high level applet and you want to see that the UI looks nice, or are you simulating the interaction between low level devices. An emulator really is a simulator, but it's simulating an actual machine. Whereas when most people refer to simulators they often mean simulating an API layer.

    8. Re:simulator? by StripedCow · · Score: 1

      In any case, the terminology is confusing. An emulator is a simulator, whereas the reverse is not true.

      This is like saying "monkeys versus animals" or "apples versus fruit", putting them on equal footing.
      It just doesn't make any sense this way.

      --
      If Pandora's box is destined to be opened, *I* want to be the one to open it.
  2. Android in virtual machine by Anonymous Coward · · Score: 1

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

  3. x86 Android Virtualisation: native performance! by thatkid_2002 · · Score: 5, Informative

    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?

    1. Re:x86 Android Virtualisation: native performance! by Lordpidey · · Score: 2

      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?

      One that works on most CPUs.

      --
      Some people encrypt by using rot-13 twice. I prefer the more secure method of using rot-1 a total of twenty six times.
    2. Re:x86 Android Virtualisation: native performance! by thegarbz · · Score: 3, Interesting

      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.

    3. Re:x86 Android Virtualisation: native performance! by cerberusss · · Score: 4, Informative

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

      --
      8 of 13 people found this answer helpful. Did you?
    4. Re:x86 Android Virtualisation: native performance! by The1stImmortal · · Score: 4, Informative

      How about Genymotion? http://www.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)

    5. Re:x86 Android Virtualisation: native performance! by sheltond · · Score: 3, Informative

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

    6. Re:x86 Android Virtualisation: native performance! by robmv · · Score: 1

      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

    7. Re:x86 Android Virtualisation: native performance! by master_kaos · · Score: 1

      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.

    8. Re:x86 Android Virtualisation: native performance! by Lawrence_Bird · · Score: 2

      Wow.. dude you are lame ok? HAXM is an option in the SDK. Is it that difficult to check the box? And creating an AVD is not exactly rocket science. I use IntelliJ (as opposed to Android Studio which came out later) and have had no issues with emulation. In fact I often have a physical device and one or more emulators attached to ADB. And one click to build and send to the 'device' isn't too hard either. On any modern PC the x86 emulator runs without a hitch.

      As to your "issue" with an emulator not appearing - this can sometimes happen in IntelliJ (and probably A.Studio too) when the machine has come out of sleep. It is not an issue with the emulator, rather the ADB and IntelliJ not communicating.

    9. Re:x86 Android Virtualisation: native performance! by TheSunborn · · Score: 1

      Yeps. I can confirm that. On linux it just works with Eclipse, and my emulator is running my software faster then the Android device I am testing on. (But I am testing on an old Android 2.3 device. I am sure a new Android device would beat my emulator).

    10. Re:x86 Android Virtualisation: native performance! by cerberusss · · Score: 1

      No, it's not rocket science. And if it worked now, it would be okay. But it doesn't. I ran through all the steps, and the simulator starts but it's not the x86 emulator for some reason.

      --
      8 of 13 people found this answer helpful. Did you?
    11. Re:x86 Android Virtualisation: native performance! by Bogtha · · Score: 1

      Stop making excuses for a shitty UX. Android development is an utter pain in the arse in a lot of ways and as long as people like you make excuses instead of complaining about it, it's going to continue to be an utter pain the arse for years to come.

      --
      Bogtha Bogtha Bogtha
    12. Re:x86 Android Virtualisation: native performance! by Lawrence_Bird · · Score: 1

      AVD
      pick a device
      an API
      select Intel Atom(x86)
      fill in the other blanks as appropriate

      SDK
      make sure you have installed an Intel x86 Atom System Image for the API you are interested in
      make sure you install the HAXM extra (Intel x86 Emulator Accelerator)

  4. It always did seem odd to me. by Lordpidey · · Score: 1

    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.
    1. Re:It always did seem odd to me. by Anonymous Coward · · Score: 2, Informative

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

    2. Re:It always did seem odd to me. by MoonlessNights · · Score: 1

      It shouldn't be too surprising that it runs well with Java. Embedded is where the first Java inroads were made. Recent VMs make the performance pretty sweet, once you get going.

      Running the JVM on an emulator, however, is less than optimal: "it's turtles all the way down".

      I understand why they did it but, if there are still serious performance problems with it (which wouldn't be surprising - phones are growing in performance faster than PCs) then they probably need to go the simulator route (even though that isn't quite as generally useful or rigidly correct).

    3. Re:It always did seem odd to me. by Anonymous Coward · · Score: 1

      Android doesn't run a JVM. Only the source is Java, the compiled form is not java bytecode.

    4. Re:It always did seem odd to me. by TemporalBeing · · Score: 1

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

      1. As another said, Android does not provide a JVM. They provide the DalvikVM which is different in many ways from the JVM including the bytecode instructions used, as well as many classes that are present the JVM but not in the DalvikVM and vice versa. Using the JVM with an additional set of classes works out well for development more by-chance and the nature of the Java Language than anything else.

      2. Many Android Apps uses native libraries to speed up the application - e.g there is a lot of code in Android that is C/C++ and not Java code because Java is too slow for the tasks being achieved. Hence, the code is built for the ARM platform and not the x86 platform.

      --
      Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
    5. Re:It always did seem odd to me. by Wdomburg · · Score: 1

      Dalvik is its own VM and bytecode specification.

  5. So much wrong by Anonymous Coward · · Score: 3, Interesting

    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.

    1. Re:So much wrong by Anonymous Coward · · Score: 1

      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.

    2. Re:So much wrong by JaredOfEuropa · · Score: 4, Insightful

      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.

      --
      If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
    3. Re:So much wrong by Anonymous Coward · · Score: 1

      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.

    4. Re:So much wrong by Anonymous Coward · · Score: 1

      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.

    5. Re:So much wrong by coinreturn · · Score: 4, Informative

      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.

    6. Re:So much wrong by JaredOfEuropa · · Score: 2

      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.

      --
      If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
    7. Re:So much wrong by Immerman · · Score: 1

      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.

      --
      --- Most topics have many sides worth arguing, allow me to take one opposite you.
    8. Re:So much wrong by rjstanford · · Score: 1

      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.

      --
      You're special forces then? That's great! I just love your olympics!
    9. Re:So much wrong by master_kaos · · Score: 1

      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.

    10. Re:So much wrong by _xeno_ · · Score: 1

      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?

      --
      You are in a maze of twisty little relative jumps, all alike.
    11. Re:So much wrong by drinkypoo · · Score: 1

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

      That still doesn't make the (so-called) simulator useless. It means that it is not a complete replacement for another solution, but that's not the same thing.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    12. Re:So much wrong by coinreturn · · Score: 3, Insightful

      Bullshit. [snip] The simulator is entirely useless for developing an actual app.

      No, what I said is not bullshit. In my experience, it works great. Yours differs. That does not make my experience bullshit. Perhaps you suck at programming.

    13. Re:So much wrong by jittles · · Score: 1

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

      I hate to break it to you, but an emulator isn't going to fix that either. The emulator will perform more slowly than the simulator, but it is still ultimately running on a completely different system than your final product. Perhaps your app is IO bound and you're running on a faster IO device than the target? The point of a simulator or emulator in this case is to verify your proof of concept. Not to say "I did my job." And if you already knew there was a performance issue on the actual hardware with your web based application, why would you think you could just code something up in Objective-C and have it perform better? Sure Obj-C should run faster than javascript, but you can't take that on faith. Until you see it running as it should natively on that platform, you have to assume the job is not done.

    14. Re:So much wrong by osu-neko · · Score: 1

      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.

      They would if they want to make the ludicrous assertion that that's "entirely useless". Over 95% of the testing you do during development of a non-trivial application is stuff that could be tested perfectly fine under WINE or an even less complete API mimic, indeed could be tested by compiling natively to whatever platform you're developing on. The vast majority of code in a non-trivial application is completely platform/OS agnostic.

      --
      "Convictions are more dangerous enemies of truth than lies."
    15. Re:So much wrong by rjstanford · · Score: 1

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

      The same thing would happen if you'd tested on an iPhone 5S and then your users tried to run it on an iPhone 4. Is that their fault also?

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

      Odd to hear this from you, since we deploy many apps written extensively in JavaScript, but do go on.

      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?

      Aha! Sounds like you had slow code in one language and replaced it with slow code in another language. FWIW, there are plenty of free JS charting libraries that run really well generating complex charts blindingly fast even on very old iOS devices.

      What's that saying about a craftsman blaming his tools again?

      --
      You're special forces then? That's great! I just love your olympics!
  6. Emulator? Simulator? Pfffttt... by Anonymous Coward · · Score: 1

    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.

    1. Re:Emulator? Simulator? Pfffttt... by kav2k · · Score: 3, Insightful

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

    2. Re:Emulator? Simulator? Pfffttt... by Anonymous Coward · · Score: 2, Informative

      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.

    3. Re:Emulator? Simulator? Pfffttt... by master_kaos · · Score: 2

      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.

    4. Re:Emulator? Simulator? Pfffttt... by drinkypoo · · Score: 1

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

      You don't need that. You just need one device that is easily reflashed to multiple versions, maybe two devices. A Nexus 7 (1st or 2nd, either way) will cover all the new versions, for example. Given the ease of swapping factory images, it's a fairly minor annoyance.

      Since there are already adequate emulators provided for basic compatibility testing, that will get all but the most diehard developers through. Those people can buy more hardware with profits from some lesser successes if they are truly beginning from zero.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    5. Re:Emulator? Simulator? Pfffttt... by Lawrence_Bird · · Score: 1

      You can make any number of virtual devices which will get you stock android on the most widely used device configurations. Its not hard at all because AVD manager comes with predefined examples you can copy and then modify if you so chose.

  7. Even Firefox OS has a simulator by Anonymous Coward · · Score: 1

    Android is playing catch up

    1. Re:Even Firefox OS has a simulator by ubersoldat2k7 · · Score: 1

      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.

    2. Re:Even Firefox OS has a simulator by rjstanford · · Score: 2

      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!
  8. Surrprised it is so hard by MichaelSmith · · Score: 2

    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
    1. Re:Surrprised it is so hard by StripedCow · · Score: 2

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

      I'm not sure Ubuntu has an ARM iso.

      --
      If Pandora's box is destined to be opened, *I* want to be the one to open it.
    2. Re:Surrprised it is so hard by MichaelSmith · · Score: 1

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

      --
      http://michaelsmith.id.au
    3. Re:Surrprised it is so hard by c · · Score: 2

      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.

      --
      Log in or piss off.
    4. Re:Surrprised it is so hard by viperidaenz · · Score: 1

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

      I run Debian on my ARM board.

    5. Re:Surrprised it is so hard by serviscope_minor · · Score: 1

      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.

      --
      SJW n. One who posts facts.
    6. Re:Surrprised it is so hard by hairyfeet · · Score: 1

      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.

      --
      ACs don't waste your time replying, your posts are never seen by me.
  9. Desktop integration by Anonymous Coward · · Score: 5, Insightful

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

    1. Re:Desktop integration by Mister+Liberty · · Score: 2

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

    2. Re:Desktop integration by Parker+Lewis · · Score: 1

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

    3. Re:Desktop integration by psionski · · Score: 1

      What does Canonical have to do with anything?

    4. Re:Desktop integration by Parker+Lewis · · Score: 1

      Most popular desktop Linux distro.

    5. Re:Desktop integration by psionski · · Score: 1

      Integrate the Android support in Debian (which is free from corporate interests) and it will flow downstream. Easy-peasy :)

    6. Re:Desktop integration by Parker+Lewis · · Score: 1

      You're right!

    7. Re:Desktop integration by tlhIngan · · Score: 2

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

      Well, the problem is Android.

      You see, the current Andorid OHA agreement makes it impossible for an OEM that ships Android phones to ship any other phone that can run Android apps that does not run Android. So if you make an Android phone, you're blocked by Google et. al. from releasing a Firefox OS or Ubuntu phone if they can run Android.

      So Mozilla and Canonical know they physically cannot support Android at all, because if they do, the number of people who can sell and release the phone dwindles dramatically. There just aren't that many companies that make pure AOSP phones or non-Android phones.

    8. Re:Desktop integration by grouchomarxist · · Score: 2

      Actually that was the goal of the AndroVM project. Unfortunately, that project became the commercial Genymotion project and the goal doesn't appear to be desktop integration, but instead a developer tool. You can use it to run apps, but I don't see any specific integration features.

      Otherwise, there is BlueStacks, but it runs on Windows and Mac, but not Linux.

  10. I just use a real Android device by rklrkl · · Score: 4, Insightful

    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.

    1. Re:I just use a real Android device by batkiwi · · Score: 1

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

    2. Re:I just use a real Android device by GNious · · Score: 2

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

    3. Re:I just use a real Android device by Threni · · Score: 5, Informative

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

    4. Re:I just use a real Android device by bluescrn · · Score: 1

      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.

    5. Re:I just use a real Android device by kaiser423 · · Score: 1

      I find the Nexus 10 to be great for this. The resolution on it is so high, that I can quickly change it's configuration to match the screen dimensions of any other Android phone or tablet, and the tablet is a couple of years old so it's a processing power is a good stand-in for devices that you might typically deploy to. Just have that connected, and I can quickly test my app out in tablet mode, various phone configurations and display sizes, check fluidity and call it good for the vast majority of systems out there.

      I really don't know why Google doesn't just make something like the Nexus 10, but with a ridiculously fast interface so that you can push >GB apps to it in seconds for development purposes. eSATA or something would be great, you could even just make a partition on your computer look like a mount to the device and run it without having to push apps out to the device. Then in developer options allow to to turn on/off cores, set max processor and GPU speeds (like most people already do with custom ROMs), and provide a bit better of a way to make the screen look different sizes, and you could set up automated tests that cover the vast majority of all devices out there....

    6. Re:I just use a real Android device by DerPflanz · · Score: 1

      You can also setup a large phone to render smaller screen resolution, using adb, for example

      adb shell am display-size 640x480

      I have never ever used the Android emulator for testing, because it is annoyingly slow and a real device works just fine.

      --
      -- The Internet is a too slow way of doing things, you'd never do without it.
  11. Windroy by HagbardMytrCeline · · Score: 1

    http://www.socketeq.com/

  12. Re:Actually, Android needs a sTimulator by Mister+Liberty · · Score: 1

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

  13. Re:Also needs a language not Java... by abies · · Score: 1

    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.

  14. Eclipse + VirtualBox + x86 Android image by jpswensen · · Score: 1

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

    1. Re:Eclipse + VirtualBox + x86 Android image by jpswensen · · Score: 1

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

    2. Re:Eclipse + VirtualBox + x86 Android image by jpswensen · · Score: 1

      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.

  15. Toooooo Slooooow by EmperorOfCanada · · Score: 3, Interesting

    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.

  16. Emulator with HAX by bayankaran · · Score: 1

    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
  17. Re:Fuck off beta by Anonymous Coward · · Score: 1

    Someone needs a snickers

  18. HAXM by Graydyn+Young · · Score: 1

    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.

  19. The resistance to this idea is surprising by iPaul · · Score: 4, Interesting

    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
  20. The resistance to this idea is surprising by iPaul · · Score: 1

    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
  21. Just use a phone...... by Murdoch5 · · Score: 1

    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

  22. Where is the vmware app? Need simple testing by dczyz · · Score: 1

    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.

  23. Just use Qt, or PhoneGap by scorp1us · · Score: 1

    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.
  24. Re:Where is the vmware app? Need simple testing by drinkypoo · · Score: 1

    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.'"
  25. An already solved problem by GweeDo · · Score: 1

    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
  26. Adam Sandler by NotFamous · · Score: 1

    Or as Adam Sandler calls it, a "shimulator".

    --
    Some settling may occur during posting.
  27. Genymotion by emblemparade · · Score: 1

    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.

  28. Re:No, what devs need is specifc device emulation by Lawrence_Bird · · Score: 1

    I think the issue is more one with the skinning and mods which the vendors do than the hardware itself as that is easily emulator for just about any device.

    I note you mention the Nook. Did you ever have wierdness with the screen dimensions sometimes counting and sometimes not the area where the nook button is? Given it is end of life I decided to not bother putting in a nook adjustment to things which needed to be centered.. its a tiny bit off but I don't expect too many nook users (other than me using it as a big screen for testing)

  29. Simple Rebuttal by idontgno · · Score: 1

    Only a poor craftsman blames his tools.

    --
    Welcome to the Panopticon. Used to be a prison, now it's your home.
    1. Re:Simple Rebuttal by frank_adrian314159 · · Score: 1

      Only a idiot hands someone a screwdriver when they've asked for a hammer.

      --
      That is all.
  30. only a problem with virtualbox by Chirs · · Score: 1

    KVM and VMWare Player can run VMs simultaneously without any problem.

  31. It says sprocket, not socket. by Zecheus · · Score: 1

    http://mikewhitmore.wordpress....

  32. Simulator? Emulator? by TechAdvisor · · Score: 1

    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

  33. WINE , or AINE by cheekyboy · · Score: 1

    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.
  34. Android isn't the only one by SirTopas · · Score: 1

    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.