Live data from Hacker News

How to speed up the Android Emulator by up to 400%

blogs.nuxeo.com

51–56 of 56 posts

Re: How to speed up the Android Emulator by up to 400%

#51
post #27

Someone should sell a usb dongle with an ARM chip on it that can run android using the emulator on your dev machine for display and input. Debugging on a phone is not so bad, but it's not quite as nice as the iOS simulator experience.

For me, that "dongle" is a ~$70 prepaid android phone (a Huawei L8180). I strongly doubt any low volume developer aimed hardware could be built and sold for much less than that...

I figured it was important to test on a low end phone, right? ( see how I nicely justified my cheapness there?) The downside to that plan was the jQuery Mobile bug that only showed up on top end devices (now the Huawei has a Galaxy S2 siting next to it...)

Re: How to speed up the Android Emulator by up to 400%

#52
post #41

Earlier quoted context omitted.

Testing is not a boolean. You won't notice if some item on a checklist took a couple of seconds during your daily device test, but a user will notice when that action is all he's doing, over and over.

You say "testing is not a boolean", then imply that testing "over and over" is? Developing on the emulator doesn't stop you from doing nice, lengthy real usage testing on the devices once you've got everything in decent shape.

That's true, and there's no reason most people can't use their gym memberships, but statistically they won't. Nobody's saying that you must do all your testing on average hardware — just that they prefer it because it forces them to put proper time into it.

Re: How to speed up the Android Emulator by up to 400%

#53

Earlier quoted context omitted.

"Such a pain" as compared to what exactly? This will depend entirely on what it is that youre trying to do. In all my experience, Android is notoriously easy to develope on, being fully open-source the way it is. Try developing for iOS beyond a the basics and I think you'll come to agree. I dont think its fair to call the emulator an obstacle, it just comes with limitations. After all, emulators are only designed to…

Please don't put words into my mouth or make assumptions about me. I am primarily an iOS dev. An app I worked on won an Apple Design Award and multiple other apps are in the Top 5 paid apps for their category in the iTunes store. To say that I develop for iOS at a basic level is laughable at best. XCode isn't perfect, but I don't need google for blog posts or spend hours writing scripts or messing with configuration…

Why does being an iOS developer give your insight into the Android platform credibility?

Re: How to speed up the Android Emulator by up to 400%

#54
post #46

I've tried this. It's faster even than developing with a device -- once you get a good test/debug flow going it's awesome. Some big caveats though: * No Google APIs. So no MapView. * The various builds are quirky. I couldn't get networking to function in the "Stable" Froyo build. Meanwhile, the Gingerbread build used in the linked post reports the wrong SDK version (it claims Honeycomb but is actually Gingerbread). T…

Ugh, no Google API support!? That is a pretty big deal.Wish I would have seen that earlier.

Re: How to speed up the Android Emulator by up to 400%

#55

Earlier quoted context omitted.

"Such a pain" as compared to what exactly? This will depend entirely on what it is that youre trying to do. In all my experience, Android is notoriously easy to develope on, being fully open-source the way it is. Try developing for iOS beyond a the basics and I think you'll come to agree. I dont think its fair to call the emulator an obstacle, it just comes with limitations. After all, emulators are only designed to…

Please don't put words into my mouth or make assumptions about me. I am primarily an iOS dev. An app I worked on won an Apple Design Award and multiple other apps are in the Top 5 paid apps for their category in the iTunes store. To say that I develop for iOS at a basic level is laughable at best. XCode isn't perfect, but I don't need google for blog posts or spend hours writing scripts or messing with configuration…

My appologies, I didn't realize I was putting words in your mouth. I believe it was your post that called Android dev. a pain though, and unless I'm mistaken it was also you who referred to the emulator as an obstacle. Finally, I said all these things in relation to MY experience. As for my assumptions, i simply assumed you were an amatuer Android developer because, despite the fact that Android is known to be used on a wide selection of devices--all of which couldnt possibly be accomodated on one emulator in any effective way--you are still fixating on the fact that the emulator doesnt cater to your expert needs. I suppose I simply assumed that someone like yourself would have moved on from such a basic method of developement, since "to say that [you] develop for iOS at a basic level is laughable at best."

Just watch that your horse desn't fall off that precariously-high ledge and crush us lowly startup operators.

Re: How to speed up the Android Emulator by up to 400%

#56
post #50
post #31

Earlier quoted context omitted.

That's exactly the purpose for which I bought the Nexus S, the Nexus One, and the HTC G1. They are the Google Reference devices. Admittedly, it's perhaps not as lean as what you're referring to, but as a testing sandbox, I've tried a lot of different phones, but nothing has worked as well, in a general sense, as the reference models.

I ended up buying the popular phones (HTC Desire HD, Samsung Galaxy S2, etc.) just for testing, I'm on iOS myself. But just working from (non reference) phones is dangerous too, it's so annoying to implement the volume controls with a BroadcastReceiver for the ACTION_MEDIA_BUTTON Intent (works great on Motorola's), but fails on HTC, and you should just override onKeyUp()... all (Android) phones behave differently, an…

Thanks for the insight. I personally have yet to have any issues running on any devices, but most of what I'm doing is internal to our company and doesn't have a very large user base. Also, our code is pretty standalone from the OS itself.

Regardless, there's always going to be the issue of supporting multiple devices, but I have found that if I develop in the 'perfect' environment first, it speeds development time considerably. It's akin to web development against standards. I feel very sorry for the developers (if there are any left, this used to be accepted practice) who developed for Internet Explorer, and then had to cobble in "support" for other browsers. In much the same vain, it's easier to work against the best possible outcome, and then revisit your code for the edge cases.

I don't know, or have any numbers to know whether or not the Galaxy S2 is 'edge' or not, as I'm guessing it's quite popular. :-\ Sorry.

Post reply on HN