Android: Faster emulator with better hardware support(android-developers.blogspot.com)
android-developers.blogspot.com
Android: Faster emulator with better hardware support
http://android-developers.blogspot.com/2012/04/faster-emulator-with-better-hardware.html
8 comments
I am wondering about the opposite case: how do they emulate graphics when there is no GPU support? Do they emulate the GPU device, or use a software library? Which library if it is done in software?
Essentially all of the commands on the device are translated into native OpenGL calls, so I suspect if you don't have a GPU you just get the default OpenGL software renderer.
To add an anecdote about this new functionality, I have been unsuccessful using the GPU acceleration (x64 Windows 7 with an nvidia GTX 560 w/latest drivers). With the emulation on the AVD GPFs with emulator-arm.exe has stopped working (invalid access). Anyone have success?
Me neither - Win 7 x64 Sandy Bridge GPU.
After updating my dev tools through the SDK, I wondered why I couldn't run an x86 system image. The update doesn't select it for installation by default. Selected "Intel Atom x86 System Image" for the Android 2.3.3 system and everything works. Seems a little bit faster. Though, I really wanted to test it out with Android 4.0.
I was testing this last night. It reduced the time for the emulator to cold boot from 120-130 seconds down to 45-55 seconds. Not as snappy as the iPhone simulator, but over cutting the time by over half is really substantial. Props to them.
I just tested it on my Lenovo Thinkpad T420. Takes about 65 seconds using a VM with the 2.3.3 ARM image, and 6 seconds using the 2.3.3 x86 image taking advantage of my CPUs VT instructions...
Literally 6 seconds after typing "emulator-x86 -avd TestImage -qemu -m 512 -enable-kvm" and hitting return, until I'm at the Android login screen.
This laptop has an i5-2520M CPU @ 2.50GHz, 8GB of RAM and an SSD.
Literally 6 seconds after typing "emulator-x86 -avd TestImage -qemu -m 512 -enable-kvm" and hitting return, until I'm at the Android login screen.
This laptop has an i5-2520M CPU @ 2.50GHz, 8GB of RAM and an SSD.
You can still get GPU emulation on Android 4.0 - this isn't tied at all to the x86 images for 2.3.3. When creating an image, just make sure to set the hardware property "GPU Emulation" to "yes" (you can do this by creating a new emulator, or editing a current one, going to "Hardware" at the bottom, clicking "New" on the far right, selecting "GPU Emulation", hitting okay, double clicking on GPU Emulation in the property list and setting it to "yes").
> Last week’s r17 developer tools release included x86 system images and host drivers
I am confused by this announcement. Does that ^ refer to the 2.3.3 version?
I don't see any x86 for 4.0+. What am I missing?
I am confused by this announcement. Does that ^ refer to the 2.3.3 version?
I don't see any x86 for 4.0+. What am I missing?
No, this blog post referring to GPU emulation and some improvements they've made to floating point emulation.
They should use the iOS Simulator approach: have the whole "emulator" build native on the host PC instead of running the ARM version in qemu.
There are different trade offs for each technique. Aside from ensure that native code functions properly (e.g. Android NDK), you can get platform specific perf metrics from an emulator that you just do not get from running x86 code.
With Android apps running in a VM this is not as much of an issue, but it is still nice to have.
The downside is that writing performance emulators for 1ghz+ multicore ARM chips is hard. :) GPU virtualization helps out a fair amount with this.
As an aside, they do have a virtualized mode that appears to be sort of a hybrid between an emulator an Apple's technique. I believe they are still running the entire Android OS, but it is a native x86 version of it so you get much better performance.
The other cool part about having an emulator is that once your emulator is complete enough, you can add in emulation support for all sorts of sensors, GPS, etc, and they are truly emulated and the programmer can interact with them the same way they would on the device (with the need for some sort of "feed arbitrary input" code paths of course).
When you just have a glorified UI toolkit that has been ported to the Desktop, everything else (GPS, sensors, etc) can end up special cased.
With Android apps running in a VM this is not as much of an issue, but it is still nice to have.
The downside is that writing performance emulators for 1ghz+ multicore ARM chips is hard. :) GPU virtualization helps out a fair amount with this.
As an aside, they do have a virtualized mode that appears to be sort of a hybrid between an emulator an Apple's technique. I believe they are still running the entire Android OS, but it is a native x86 version of it so you get much better performance.
The other cool part about having an emulator is that once your emulator is complete enough, you can add in emulation support for all sorts of sensors, GPS, etc, and they are truly emulated and the programmer can interact with them the same way they would on the device (with the need for some sort of "feed arbitrary input" code paths of course).
When you just have a glorified UI toolkit that has been ported to the Desktop, everything else (GPS, sensors, etc) can end up special cased.
As an iOS dev, I can tell you, I would much rather be doing my perf optimization on real hardware than on an emulator, even one that emulates clock-for-clock (and I highly doubt that the Android NDK does, although perhaps they ship a tool that lets you extract this information).
Just for starters, if I am profiling code, it's probably because the code is slow. (Infamously, for awhile we had a 13-hour unit test). If a quad-core 1ghz ARM device is slow, the last thing I want to do is throw an emulator into the mix.
Just for starters, if I am profiling code, it's probably because the code is slow. (Infamously, for awhile we had a 13-hour unit test). If a quad-core 1ghz ARM device is slow, the last thing I want to do is throw an emulator into the mix.
The binaries built by the Android NDK are emulated on the emulator properly. I've deployed NDK binaries on the emulator and traced it with IDA Pro, one line of ARM assembler at a time... So yes, it's a proper emulator.
Just a fact I thought you might find interesting.
Just a fact I thought you might find interesting.
But does an ADD instruction on ARM take the correct multiplier of time as the MUL instruction? No, because time-accurate emulation is shockingly hard. Further reading:
http://arstechnica.com/gaming/news/2011/08/accuracy-takes-po...
http://arstechnica.com/gaming/news/2011/08/accuracy-takes-po...
Performance testing in any case has to be done on the target device. Neither iOS Simulator nor the Android Emulator are appropriate.
True enough, but aspects like memory consumption can still be tested on an emulator. Due to differences in x86 and ARM code gen, it can be beneficial to get actual numbers.
There are also aspects like ease of automating. An emulator running on a desktop is easier to fiddle with than an actual device.
There are also aspects like ease of automating. An emulator running on a desktop is easier to fiddle with than an actual device.
There are different trade offs for each technique. Aside from ensure that native code functions properly (e.g. Android NDK)
How about running dalvik in x86 and just emulating NDK calls? Should give a nice speed boost while still supporting native ARM code.
How about running dalvik in x86 and just emulating NDK calls? Should give a nice speed boost while still supporting native ARM code.
[deleted]
The problem with the simulator approach is then you have to make sure all of the APIs behave exactly the same both on the desktop and the phone (which are running two different processors). This certainly causes some issues (the Simulator has had no end of trouble with the sound APIs in the last 6-12 months, and only recently has it even allowed me to play sounds, albeit while still throwing exceptions, for example).
On top of that, Apple only has to worry about being consistent on two platforms: OS X and the device (iPad, iPhone, etc.), whereas Google supports all three major platforms (Win, OSX, Linux) and doesn't control the underlying hardware.
On top of that, Apple only has to worry about being consistent on two platforms: OS X and the device (iPad, iPhone, etc.), whereas Google supports all three major platforms (Win, OSX, Linux) and doesn't control the underlying hardware.
it is not like they support it correctly in one single platform. Also it is not like the problem isn't relevant with using QEMU, it remains relevant.
> it is not like they support it correctly in one single platform.
I'm not sure what you mean by this. Example?
>Also it is not like the problem isn't relevant with using QEMU, it remains relevant.
Which problem? Being consistent across multiple platforms? QEMU is fairly good at this.
When I say there are problems with the simulator, I mean like the whole audio api wasn't working on the simulator for awhile. This isn't a small difference, this made it so that I couldn't even test the app. (Not to mention the other hardware support I needed, accelerometer/gyroscope data, wasn't supported either).
I'm not sure what you mean by this. Example?
>Also it is not like the problem isn't relevant with using QEMU, it remains relevant.
Which problem? Being consistent across multiple platforms? QEMU is fairly good at this.
When I say there are problems with the simulator, I mean like the whole audio api wasn't working on the simulator for awhile. This isn't a small difference, this made it so that I couldn't even test the app. (Not to mention the other hardware support I needed, accelerometer/gyroscope data, wasn't supported either).
Isn't that what the article says, too?
"Last week’s r17 developer tools release included x86 system images and host drivers (available through the SDK Manager), allowing the emulator to access the host CPU natively and offer significantly faster execution."
I just wonder, does this mean that the apps built on this version will only work on x86 devices and you need to modify the app later to work on ARM devices, too? Because if that's the case I probably won't bother with this, since 99.9% of Android units have an ARM chip.
"Last week’s r17 developer tools release included x86 system images and host drivers (available through the SDK Manager), allowing the emulator to access the host CPU natively and offer significantly faster execution."
I just wonder, does this mean that the apps built on this version will only work on x86 devices and you need to modify the app later to work on ARM devices, too? Because if that's the case I probably won't bother with this, since 99.9% of Android units have an ARM chip.
Almost certainly not --- Android apps are compiled to a platform independent bytecode anyway, so there's no reason the compilation process would be any different here.
See http://en.wikipedia.org/wiki/Dalvik_(software)
See http://en.wikipedia.org/wiki/Dalvik_(software)
That's only true of apps written for Dalvik. Applications using the NDK are arch-specific.
Nope. Android apps are, with one caveat, independent of any particular architecture, due to their Java/Dalvik base.
The only situation where anything developed on x86 would not also work on ARM is if you include native code via the NDK (which is not usually done except where you need to wring every last bit of performance out of the device), and that's just a matter of building the native code for all the platforms you intend the app to run on.
The platform used by the emulator image makes no difference to any of that, it just makes it a lot more practical to get usable speed out of it.
The only situation where anything developed on x86 would not also work on ARM is if you include native code via the NDK (which is not usually done except where you need to wring every last bit of performance out of the device), and that's just a matter of building the native code for all the platforms you intend the app to run on.
The platform used by the emulator image makes no difference to any of that, it just makes it a lot more practical to get usable speed out of it.
which is not usually done except where you need to wring every last bit of performance out of the device
I think that's overstating it a bit. The NDK is very heavily used by the overwhelming majority of premium games, not least because it allows for significant code reuse between Android and iOS. The release of the NDK was the beginning of a massive quality app explosion on the platform.
I think that's overstating it a bit. The NDK is very heavily used by the overwhelming majority of premium games, not least because it allows for significant code reuse between Android and iOS. The release of the NDK was the beginning of a massive quality app explosion on the platform.
It's still running the Android flavour of the Linux kernel along with all its various processes inside of a VM. iOS Simulator runs SpringBoard, the various iOS daemons, and any user apps as native processes on the host OS X system. The difference may be negligible though.
Aside from the managed bytecode, when you build with the NDK you can target multiple platforms in the same APK.
e.g. (in the Application.mk)
APP_ABI := x86 armeabi armeabi-v7a
This app will run with gust on any of those platforms.
e.g. (in the Application.mk)
APP_ABI := x86 armeabi armeabi-v7a
This app will run with gust on any of those platforms.
[deleted]
Maybe they tried that. but Apple had patent on that.
This is very good news to hear. It seams with each major release of android, the emulator got that much slower. Tablet work is damn near impossible (even on my i7 w/16gb all sitting on ssd). Very good news indeed.
Thank God for this. Android 4.0's UI in the emulator was not a pleasant experience.
Tried the new GPU emulation, and got a warning that snapshots and GPU emulation are mutually exclusive.
There's no way I'm going to deal with cold booting the emulator instead of using snapshots.
There's no way I'm going to deal with cold booting the emulator instead of using snapshots.
I remember waiting at least a minute or more for the Android emulator to boot up and I just gave up on it. This is going to be so make development so much easier!
The simple fix to this is to use the snapshot system that's built-in. Start it up once, and then just continually deploy your app to it.
That said, this will make app development much nicer.
That said, this will make app development much nicer.
I don't know why they haven't added Google API support.
Quick Start Guide to Getting GPU Emulation Working:
* Open up the settings for your AVD (either by creating a new one or editing a current one)
* Go to Hardware (near the bottom), and hit new on the far right
* Select GPU emulation from the drop down list and hit okay
* Find GPU emulation in the list of properties under hardware, click on the value column and set it to "yes"
See here[1] for more ways on how to speed up your emulator.
[1]: http://developer.android.com/guide/developing/devices/emulat...