This is for me the main reason google finally needs to release the Honeycomb Source, so we can have Honeycomb running on x86.
I think Android 4.0 will be optimized for Intel Atom at least.
How to speed up the Android Emulator by up to 400%
21–30 of 56 posts
Re: How to speed up the Android Emulator by up to 400%
#22This is another symptom of why Android development is such a pain. You have to jump through hoop after hoop after hoop just to get to the point where you can get actual work done. If a tool ends up wasting more time than it saves, it isn't a tool, it is an obstacle.
That is an overstatement. This was true in the beginning for the honeycomb sdk, but as you can easily develop against hardware this isn't an issue anymore.
The Android 2.2 and 2.3 Emulators are atleast on my machine fast enough for development, but i still prefer to develop against hardware just because it feels faster and more real. Multi-Touch is easier...
Even on iOS it's better to develop against actual hardware than the simulator, therefor it's not really that much of an issue.
Re: How to speed up the Android Emulator by up to 400%
#23based on the data in the article QEmu + Android ARM runs at approximately same speed as Nexus One phone which is a good thing, right? I dont want my development emulator to run twice as fast as actual hardware, do I. The question is whether you can make the emulator run as fast as modern dual core android phones.
> I dont want my development emulator to run twice as fast as actual hardware Why not? A lot of programmers develop native apps on high-performance workstations because it makes development faster. Once in a while, you might hit a bug in which the execution time on a phone or in a slow emulator will cause problems. These are the exception to the rule. Use good programming practices especially with respect to multithr…
I think his point is that it's easy to ignore serious usability problems when you're using better hardware than your customers. For example, developers with big screens are more prone to create GUIs that do not work well on small screens. Similarly, some Xbox games are unplayable in 480i or 480p mode because nobody ever bothered to check whether the interface elements were readable at low resolutions.
Re: How to speed up the Android Emulator by up to 400%
#24Earlier quoted context omitted.
An core i5 with 8 GB of ram and a 7200 RPM 500 GB hard drive. Actually, it is closer to 70 seconds. Then the lag while attempting to use it is unbearable, it stutters, input is completely ignored, or it crashes randomly when we try to replicate that bug on an actual device we can't.
What kind of Android? 3.1? the 2.3 emulators are much better than the honeycomb ones.
Honeycomb emulator is slower because of the 1280x800 resolution. Google mentioned at I/O that it seems the emulator lags from the lack of hardware acceleration, and they said it would come by end of the year I think. I wonder if it's ready for 4.0. It should be.
Re: How to speed up the Android Emulator by up to 400%
#25Makes me wonder why the SDK doesn't use an x86 vm by default in the first place.
At Google I/O, the sdk team said it was coming in the next months (along with GPU support), but the downside was that KVM is not readily available outside linux
Re: How to speed up the Android Emulator by up to 400%
#26I think any experienced Android dev will tell you, the best solution is to buy a bunch of used Android devices, plug them in, and publish to the device directly for testing. Wasting any time with the emulator or this "virtual machine" isn't going to cut it in the end anyway.
The only time I fire up the emulators is to make sure my assets are scaling properly for the various screen sizes of devices I don't own yet.
Re: How to speed up the Android Emulator by up to 400%
#27Someone 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.
Re: How to speed up the Android Emulator by up to 400%
#28I think any experienced Android dev will tell you, the best solution is to buy a bunch of used Android devices, plug them in, and publish to the device directly for testing. Wasting any time with the emulator or this "virtual machine" isn't going to cut it in the end anyway. The only time I fire up the emulators is to make sure my assets are scaling properly for the various screen sizes of devices I don't own yet.
[deleted]
Re: How to speed up the Android Emulator by up to 400%
#29I think any experienced Android dev will tell you, the best solution is to buy a bunch of used Android devices, plug them in, and publish to the device directly for testing. Wasting any time with the emulator or this "virtual machine" isn't going to cut it in the end anyway. The only time I fire up the emulators is to make sure my assets are scaling properly for the various screen sizes of devices I don't own yet.
As an Android dev, I have to say this is very true. Emulators either don't simulate or don't simulate well enough a lot of stuff that you really want to test, like picking up audio from a microphone, or getting your location from GPS. There are also a lot of device specific quirks that make code run differently on different devices, meaning if you really want to make sure your code runs everywhere you can't just get one phone, you need to get a few.
Re: How to speed up the Android Emulator by up to 400%
#30Earlier quoted context omitted.
> I dont want my development emulator to run twice as fast as actual hardware Why not? A lot of programmers develop native apps on high-performance workstations because it makes development faster. Once in a while, you might hit a bug in which the execution time on a phone or in a slow emulator will cause problems. These are the exception to the rule. Use good programming practices especially with respect to multithr…
I think his point is that it's easy to ignore serious usability problems when you're using better hardware than your customers. For example, developers with big screens are more prone to create GUIs that do not work well on small screens. Similarly, some Xbox games are unplayable in 480i or 480p mode because nobody ever bothered to check whether the interface elements were readable at low resolutions.
> I think his point is that it's easy to ignore serious usability problems when you're using better hardware than your customers.
Only if you don't test on real devices.