Android on x86 and Binary Translation

So the other major and obvious piece of the puzzle is what changes were required to make Android and all of its applications run on x86. Android itself has already been built for x86 before, and again we’ve seen and played with it running all the way back at IDF 2010. That part of the puzzle is relatively understood, but the devil again is in the edge cases. Among the things that need massaging for x86 are the Dalvik VM, x86 JIT, NDK, and JavaScript engine.

Android itself is actually an ideal platform for Intel to target, as the vast majority of Android applications in the Play Store run atop the Dalvik VM and use the Android Framework (75–80% are commonly cited numbers, depending on how you’re counting). The rest either are Dalvik VM applications that run and use JNI (Java Native Interface) libraries that are built for ARM only, or NDK (Native Development Kit) applications. So where does Intel’s binary translation secret sauce fit into all this? Simply put, Intel’s binary translation is the mitigation for both libraries and NDK applications that haven’t yet been ported to x86, and allows the device to expose itself as supporting two application binary interfaces (ABIs), both x86 and ARMv5, in fact this is easy enough to see upon superficial inspection of build.prop:

ro.product.cpu.abi=x86
...
ro.product.cpu.abi2=armeabi

In the case of Dalvik applications, developers don’t need to do anything. Thankfully again this is the vast majority of Android applications you encounter on a daily basis - they just work, given that Intel has made Dalvik work with x86 and spit out the right machine code.

NDK applications are also easy enough to mitigate - the developer simply needs to recompile the NDK project, which supports ARMv5 (‘armeabi’), ARMv7 (‘armeabi-v7a’), and x86 (‘x86’). Building for x86 will deliver code that’s tailored (unsurprisingly) exactly to the Saltwell CPU feature set, or more explicitly what you’d get by running GCC with the compiler flags “-march=i686 -msse3 -mstackrealign -mfpmath=sse” - this is all outlined in the CPU-ARCH-ABIS.html document as part of the NDK documentation. The resulting APK can be packaged as a “fat binary” with machine code for all three platforms, and upon install only the proper one is unpacked and installed.

The remaining two cases are where binary translation come in. In the case of applications that haven’t been rebuilt with the NDK to target x86, the binary translator magic kicks in and translates the armeabi version into x86. The same applies for applications that request some JNI libraries that are currently ARM only.

Intel outlines this in a number of slides which have made their way online, and the process is virtually completely transparent to end users and Dalvik applications. The x86 compatible Dalvik VM is a part of the OS, as are the ARM to Atom BT phase for JNI libraries. ARM native NDK apps on the other hand are translated by Intel in the cloud, validated against Intel's Android x86 emulator and pushed to the Play Store. The point is the bulk of binary translation happens away from the device itself and running on much faster Xeons in the cloud. As binary translation requires more cycles than natively running the code, which in turn consumes additional power, this was the only route for Intel to ensure that Atom would remain power efficient (and high performance) even on non-native NDK apps. Update: Intel has clarified and informed us there is no cloud aspect to binary translation, it is 100% done on the device for ARM NDK applications.

It's still unclear just how long this process takes after a developer has uploaded a non-x86 NDK app to the Play Store, or what happens if the process fails to validate for whatever reason (Does Intel get in touch with the developer? Is the app forever excluded?). Intel is being unusually vague about how all of this works unfortunately.

The combination of all of these efforts should result in over 90% of the apps in the Play Store working right away. What about in our experience? We discuss that next.

Software: Nearly Flawless

The X900 that I was sent came running Android 2.3.7, which is the latest version on the 2.3 branch. Xolo intends to deliver an Android 4.0.3 update later, and Intel internally has its own 4.0.x image stable and ready to go, which we’ve seen running on the FFRD a bunch before. It’s a bit odd to see things going this way when 4.0.x is clearly already ready, but no doubt some logistical issues with carrier support are the final hurdle. I’m eager to check out Intel’s 4.0.x port and intend to update when that happens.

 

Xolo and Intel have basically left things entirely stock with the X900. The notifications shade has one minor positive change - inclusion of the power controls, and Swype is bundled in addition to the stock Android 2.3 keyboard. There’s one Xolo Care support application preloaded, and basically nothing else. I can honestly say this is the least preloaded junk I’ve ever seen on a non-Nexus device.

 

So the next logical step is talking about how well Android and its apps work on x86 in practice, and the answer is unsurprisingly that almost everything is perfect. I installed about 80% of all the Android applications I’ve ever installed on any Android phone (thanks to the new Google Play ‘All’ tab) and nearly all of them worked perfectly. In fact, all of my daily driver applications work flawlessly: Twitter for Android, Baconreader, Speedtest.net, Barcode Scanner, Astro, Dropbox, Facebook, GPS Test Plus, GPS Status, Instagram, IP Cam Viewer, GTA III, Remote Desktop, Swiftkey X, and WiFi Analyzer all work perfectly.

 

That said there are indeed a few edge cases where things don’t seem to be perfect. For one, Flash 11 isn’t available for the X900, and throws an error in the market. The device does come preloaded running Flash 10.3 however, which gets the job done although is a bit dated. In addition, although Netflix would download, the installer would throw a ‘package file invalid’ error upon install. This is what leads me to think there’s some APK interception in the cloud and perhaps translation up there, and Netflix DRM not translating, but that’s speculation. Other than this, everything else I encountered works flawlessly, I wager your average Android user wouldn't be able to tell that this is running on a completely different architecture.

Medfield: Intel in a Smartphone Performance
POST A COMMENT

106 Comments

View All Comments

  • jed22281 - Thursday, April 26, 2012 - link

    Vanilla MeeGo is nothing like MeeGo-Harmattan (aka Maemo6x) on the N9...
    The only relation Tizen has with Vanilla MeeGo, is that it's structured/administered in a similar fashion.
    Plus many of the same partners involved in MeeGo, have moved to Tizen...
    The developmental libraries/environment is totally different, although there's still some tacit support for Qt.
    MeR+Nemo (& other UX's e.g. Cordia/Plasma etc) is what has supplanted the original MeeGo.
    And yes you could in theory run MeR+Nemo or Tizen on this or other Medfied devices.
    But I'm not so sure they'd necessarily be any less locked down than ARM-based ones.
    Locked boot loader etc... But once that's out of the way, they'd have their advantages.
    Reply
  • ironargonaut - Wednesday, April 25, 2012 - link

    From what I see the only phones that best Intel in performance are not on the battery chart.

    If a phone computes something faster, will that not mean it can do more in less time? Thus, while the artificial surfing battery time is "average", wouldn't I be able to surf more pages and run more apps also in that same time period?

    What is the power/performance metric?
    Reply
  • fm123 - Thursday, April 26, 2012 - link

    There is no clear way to tell from this, given that the CPU is likely ramping up and down. The other phones are not listed, I suspect, as they are new. They actually include newer battery saving features, so you can't see that yet on this comparison. Reply
  • ironargonaut - Thursday, April 26, 2012 - link

    So,then could I safely say, that since battery life is not listed here, of the phones in both tests Intel has the highest cpu performance with midrange battery life.

    If they are not going to test the batteries of the same phones then you shouldn't have them listed on the same graph for CPU power. IMHO

    It's like a Ford commercial saying Ford fullsize has better gas mileage then Chevy, more towing power than Dodge, more cargo space then Toyota etc..

    Which if written the way of this article is more like Ford worse gas mileage than Dodge, less towing power than Toyota, less cargo space then Chevy etc...

    All are misleading. IMHO
    Reply
  • mcquade181 - Wednesday, April 25, 2012 - link

    For the benefit of all us older technophiles with slightly less than perfect hearing, could you please, please test the earpiece volume when testing cellular phones?

    I had to ditch my otherwise great Nokia N8 because of its ridiculously low earpiece volume, which made it unusable in anything but perfectly quiet environments.

    The other very useful test would be how well the phone operates in both voice and data modes in areas at the fringe of network coverage, i.e. the phone’s range. The Samsung Galaxy S2 does not fare that well in this test and is no where near as good as my old Nokia N8. Surprisingly, very, very few reviews of the Galaxy S2 mention how average its fringe reception is.
    Reply
  • cmdrdredd - Wednesday, April 25, 2012 - link

    To not include any iphone results to the GLbenchmark except offscreen since offscreen looks so great on the iphone and the results I've obtained from around the web when running on the phone's screen show it not to be that much better than the fastest Android devices. How many people ac tually do GPU functions that aren't running on the phone's screen? Not many... Reply
  • suman - Wednesday, April 25, 2012 - link

    While BT is very cool technology, why is there so much hoopla around it. We released the Bluestacks App Player (beta) a month ago and have a binary translator embedded in it. We can run ARM NDK, X86 NDK, Dalvik applications side by side on our player. Reply
  • iamastranger - Thursday, April 26, 2012 - link

    Basically all are missing a point here. It is a FFRD with miimal changes done by LAVA. Wait for a OEM like Moto deliver x86 based phone. Reply
  • danielt - Thursday, April 26, 2012 - link

    Hoe come this site never review the amazing Galaxy Note? Reply
  • RajeevRaj - Thursday, April 26, 2012 - link

    One aspect not touched upon here is the price of the XOLO as compared to the other smartphones in the compare list. The XOLO costs INR 22000 ($420). Most other phones in the list (which are available in India) cost upwards of INR 27-28000 (>$520). As example the Samsung Galaxy S2 costs INR 28-30,000 ($550) and iPhones cost upward of INR 35000. (>$700)

    So if you factor in a price to features ratio also in the comparisons, the XOLO looks very attractive for a smartphone buyer in India.
    Reply

Log in

Don't have an account? Sign up now