First party support for Robolectric would be wonderful. It is a nightmare any time you need something Robolectric doesn't implement, particularly in Context classes because there are so many different types of Context: Application, Context, ContextWrapper, ContextImpl, Activity, etc. and I've never gotten Robolectric's @Config and @Implementation annotations to successfully add to them without blowing up about weird super class not matching errors.
Android Needs A Simulator, Not An Emulator
31–40 of 46 posts
Re: Android Needs A Simulator, Not An Emulator
#32Re: Android Needs A Simulator, Not An Emulator
#33I wonder if an Android device as a service would work. No, I don't mean loaning devices. I mean by the hour remote control of an Android device you can take over. Your end looks like the simulator, my end is a farm of Android devices which get a factory reset between every client connecting. You reserve it for as long as you want, or just do one-off testing. Edit: I suppose I should ask a more concrete question: woul…
The Samsung Remote Test Lab[1] provides this for free (with limits)— they have a range of real devices (S5—S2, Notes, Tabs, even Gears) that you remote into and can install APKs, screenshot, and otherwise have full control over.
Somewhat unfortunately, I've found the connection fairly unstable, and they don't factory reset between uses (so unless you remove your APK, it'll stay on the device and configurations persist).
[1]: http://developer.samsung.com/remotetestlab/rtlDeviceList.act...
Re: Android Needs A Simulator, Not An Emulator
#34What platform(s) would the simulator support? Just GNU/Linux? Even that is quite different from actual Android in some ways, e.g. glibc instead of bionic. It's easy by comparison for Apple to provide a simulator, because the simulator only has to run on Mac OS X, which basically shares everything below the UI toolkit with iOS.
You're not forced to use glibc on GNU/Linux. You could link against bionic if you want, assuming it runs in a stock kernel.
Re: Android Needs A Simulator, Not An Emulator
#35When I started a new job doing iOS development, I was a bit surprised that Apple provided a simulator and not an emulator for iPhone/iPad development. An emulator seemed like a better choice, because it would be more realistic. Realism turned out not to be a big issue, at least for the kind of app we were developing, and I guess iOS and Android devices are just too fast to emulate on a desktop with reasonable perform…
I'm not sure how necessary true emulation really is. The fact that you can easily plug a phone in and run there means that the emulator isn't as valuable so would be if it took 20 minutes of hoops to get your code on a device.
Re: Android Needs A Simulator, Not An Emulator
#36> "The most well known simulator to any Android developer is probably (and ironically) the one that iOS developers use from Apple."
I get it. Ironically Google didn't copy Apple for once, and their solution turned out bad. So now they need to ironically copy it, please, Google, pretty please. But the real irony is that Android developers both get to boast about Android being open source, yet when they need something, they go beg Google implement it for them.
And Google really can't implement an efficient iOS simulator for them, because there's no Android desktop operating system.
You see, while it's getting a bit old to hear Tim Cook brag at every keynote about how "only Apple can make everything work seamlessly together", truth is, they indeed share a kernel and over half their APIs between their desktop and mobile operating systems. This is why the iOS simulator is that good. Tim Cook knows it.
While a supposed "thin layer" Android simulator has to interface all its APIs with Windows and then do it all over again for OSX, and then again for Linux (common POSIX APIs notwithstanding), every version with its unique quirks and bugs, not matching the platform it's simulating.
So instead of that ball of pain, Google chose the easier task of virtualizing the actual hardware and then running the whole Android stack on top of that.
In their particular circumstances, this was, and remains the only feasible way of doing it, and no amount of blog whining will change that.
Turns out you really can't copy some things so easily.
Re: Android Needs A Simulator, Not An Emulator
#37> "The most well known simulator to any Android developer is probably (and ironically) the one that iOS developers use from Apple." I get it. Ironically Google didn't copy Apple for once, and their solution turned out bad. So now they need to ironically copy it, please, Google, pretty please. But the real irony is that Android developers both get to boast about Android being open source, yet when they need something,…
> Google really can't implement an efficient iOS simulator for them, because there's no Android desktop operating system.
The x86 Android build provided by GenyMotion (cited in the article) performs at the same speed as the x86 iPhone simulator.
It has two major issues:
- The UI is quirky (but usable)
- It's expensive
- GenyMotion devices have no Google Play by default. Want to test how your website runs in Chrome? Spend ages hacking Google Play onto the Android device.
Google could fix all of these things easily.
Re: Android Needs A Simulator, Not An Emulator
#38Have you guys heard of GennyMotion? It's way faster than the actual Android Emulator. My Professor for my Android Class in college recommended it to use for debugging for our assignments if we didn't have an Android Device. http://www.genymotion.com/
Genymotion is mentioned in the article, along with the reasons why it's not ideal (aside from the fact that it's not a first-party solution, and that you can't get a version with the Google SDKs running).
> You can't get a version with the Google SDKs running
Technically you can, it's just hard to do and should be there by default (I very much agree in spirit).
Re: Android Needs A Simulator, Not An Emulator
#39When I started a new job doing iOS development, I was a bit surprised that Apple provided a simulator and not an emulator for iPhone/iPad development. An emulator seemed like a better choice, because it would be more realistic. Realism turned out not to be a big issue, at least for the kind of app we were developing, and I guess iOS and Android devices are just too fast to emulate on a desktop with reasonable perform…
I'm not sure how necessary true emulation really is. The fact that you can easily plug a phone in and run there means that the emulator isn't as valuable so would be if it took 20 minutes of hoops to get your code on a device.
True, and I think Apple's simulator turned out to be the right move.
Re: Android Needs A Simulator, Not An Emulator
#40> "The most well known simulator to any Android developer is probably (and ironically) the one that iOS developers use from Apple." I get it. Ironically Google didn't copy Apple for once, and their solution turned out bad. So now they need to ironically copy it, please, Google, pretty please. But the real irony is that Android developers both get to boast about Android being open source, yet when they need something,…
> Google really can't implement an efficient iOS simulator for them, because there's no Android desktop operating system. The x86 Android build provided by GenyMotion (cited in the article) performs at the same speed as the x86 iPhone simulator. It has two major issues: - The UI is quirky (but usable) - It's expensive - GenyMotion devices have no Google Play by default. Want to test how your website runs in Chrome? S…
The x86 images provided by Google run just as fast as the Genymotion images, and have Google Play. Just FYI.