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

  • diulaylomochohai - Thursday, April 26, 2012 - link

    Where are the numbers for HTC 1X and 1S??? Let see how much INTC is off from latest and greatest from NVDA and QCOM??? Reply
  • dwade123 - Friday, April 27, 2012 - link

    Intel proves x86 can compete. With Intel's engineering and manufacturing advantages, Intel may soon surpass ARM in just about everything in the future. I still remember those who thinks ARM's transition to desktop is a threat to the entirety of Intel. Nope. It's the other way around. Intel is invading the low wattage CPU arena. Hate them or love them. The future is Intel. Reply
  • jwcalla - Friday, April 27, 2012 - link

    I lol'd. Reply
  • jwcalla - Friday, April 27, 2012 - link

    Apple just crapped out $12 billion in pure profit in just the last quarter. That's over 4x the profit that Intel saw, and Apple had almost 4x as much total revenue as Intel.

    The iCraze is in full song and Android is right up there with them. The masses don't care about x86 on a smartphone. And they're not going to. They want the iShiny. Only the dinosaurs that are hooked into these mythical "necessary" legacy x86 mobile apps are going to care about an Intel phone or tablet. And they're going to want them sporting a turbo button and USB-powered 5.25" floppy drive.
    Reply
  • pheadland - Friday, April 27, 2012 - link

    Small correction: I know Samsung says the GS2 only takes 32GB SD cards, but numerous people, including me, have 64GB SDXC cards working just fine in their GS2s (and many other Android phones).

    This trend to omit SD expansion and provide only 16GB built-in is puzzling and annoying. I have around 40GB of music. TV shows and movies can run multiple GB each. Streaming just doesn't cut it in rural areas or on planes.
    Reply
  • phoenix_rizzen - Wednesday, May 02, 2012 - link

    Have you put more than 32 GB of data on that 64 GB card, to make sure it's actually able to use all of it? Just curious, more than anything. Reply
  • Exophase - Friday, April 27, 2012 - link

    In the article you say that the translations are taken from Intel's servers in order to avoid the overhead of doing it on the phone. I doubt this is true, because based on Intel's publications the translation in its current state isn't that sophisticated and unless it is very poorly coded there's no way it'd be slower to do it on the device than pull it off the network.

    I think the real reason they did this is so they can improve the translation quality w/o updating the phones. Part of this could include hand optimizing hot spots or fixing incompatibilities in some of the more problematic games. Maintaining a database of program specific modifications on every phone would not be a good move.

    The article had some good information but I'm disappointed in the total lack of attention given to games. In the big list of apps that work fine I could only spot one game. For comparison, S|A tried two games - both worked, but one of them had awful performance. The phone game market is huge right now and it'd be nice to see someone try several - dozens, perhaps? - of games on the unit. But if they don't, the review should at least indicate that it's not focusing on it. With reviews like this it feels like phone gaming is almost completely devalued, which is bizarre given that several GPU benchmarks are performed, and GPU performance benefits little more than gaming.

    Of course, the battery life tests also don't address gaming. The iPhone 4S review had at least one gaming test (for something really resource intensive) so it's not like there's zero precedent for it.

    The big open questions for Intel putting x86 phones have never been if they can implement competitive GPUs or media blocks or even if they can have very low power consumption when there's low CPU activity. These things are obvious and Intel has already proven themselves on all of these fronts. What people want to know, or at least what I want to know, is what the power consumption is like when the CPU is being heavily accessed. In other words, I want an idea of perf/W. Talk time tests use a negligible amount of CPU. Browser tests use an unknown amount of CPU - it could be literally anything depending on what sites you use and how the idle parameters are tuned. I'd love to see some CPU utilization + frequency graphics during this test. But suffice it to say, if you're trying to simulate the user browser experience it'll consists of small periods of heavy activity while pages are loaded and vast periods of low activity while the user reads what's on the page.

    This is totally different from at least a lot of games, where the CPU constantly has to do something. This both increases the average frequency it has to operate in and gives it less time to go from full idle to full activity.

    At the very least it'd be nice to see some video playback battery tests. This (ideally) doesn't use much CPU either, and I'm sure Medfield does just fine here, but it's at least an important use case that should be validated. When you're on an airplane I'm sure you won't be using your phone for talking or web browsing.
    Reply
  • kuroxp - Monday, May 21, 2012 - link

    say sorry! see updates. :D Reply
  • sjprg2 - Sunday, April 29, 2012 - link

    Are all the cell phone makers STUPID? Where is the hands free bluetooth support with caller ID such as the Motorola V750 has? These are supposed to be phone! You can't drive in Califorina with the existing smartphones. They are not legal! Reply
  • derodg - Monday, May 07, 2012 - link

    You people are forgetting one very important thing here. This is x86 device! I should in theory be able to run any x86 compatible OS. Which includes Windows 8 that has a touch interface. This means I could dock my phone to a larger display use a keyboard and mouse. Then pick it up an walk out the door and use the same device.

    And once they get dual-cores in the Atom. Not only can I just buy one app. I can use it on my desktop and mobile device because they both would be the same.
    Reply

Log in

Don't have an account? Sign up now