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

  • kyuu - Wednesday, April 25, 2012 - link

    I dunno what review you all were reading, but I didn't see average performance. I saw it pretty much beating everything else save the HTC One S/X with only a single-core and running an old version of Android. Wth ICS, it'd probably be at the top easily.

    Sure, ARM isn't sitting still, but is Intel. I have no desire to see Intel overtake the market, but I can easily see Intel being the performance king by a good margin in the mobile SoC market when they release their next SoC.

    Also, for people saying cost is a factor... do you have any source to back up the claim that Intel's SoC is significantly more costly? All I see are assumptions.
    Reply
  • kyuu - Wednesday, April 25, 2012 - link

    That's "neither is Intel" in the second paragraph, first sentence. Reply
  • UpSpin - Thursday, April 26, 2012 - link

    SunSpider and Browsermark results are that good because of software tweaks done by Intel. Intel tweaked a lot in software, thus I doubt that ICS will improve anything further.

    Linpack single threaded, that's the most important benchmark to compare raw processing power without software tweaks. It shows that Medifield is faster than ARM A9, a good sign, but slower than Krait and thus all soon to get released A15 cores, a bad sign.
    Linpack multi threaded shows that Medfield has not the slightest chance vs. Krait and ARM A15, most of them will be dual core SoCs, but even if they get produced in single core varients they will be faster (Linpack single threaded). Medifield also gets beaten by Quad Core A9 chips (all new high end smartphones pack either a Quad Core A9, or dual Core krait/A15). Medfield is at best, as fast as a dual core A9 (raw processing power).

    Then take a look at the GPU: Poor performance for todays standards. Slower than the SGSII, slightly faster than the Galaxy Nexus, which has a slow GPU, too.

    Power consumption: poor to average. (sadly we don't have numbers for Krait or Tegra 3 (HTC One X/S)

    The SoC is not bad at all, but its release date is one year too late. This year is the year of Krait and A15, which beat Medfield in single threaded applications and are at least dual cores, so more than twice as fast. The integrated GPU is pretty weak, too, especially if you consider that this years ARM SoCs have a much better GPU.

    Additionally x86, the advantage is huge software tweaks thanks to Intel, the disadvantage, custom skins/apps/features made by third party manufacturers won't run that easily.
    Reply
  • Exophase - Friday, April 27, 2012 - link

    Intel doesn't tweak Sunspider or Browsermark. But Javascript JIT performance is probably much better on x86 than ARM right now because it got a ton of attention on PCs from all major browser vendors, starting with the release of Chrome. And there's at least one major ARM improvement (EABI hardfloat) that's in V8 but didn't make it into official Android yet.

    Browsermark is only partially Javascript, but the other part (HTML5 rendering) is really lame too. Run it and you'll see what I mean, I hope.

    Linpack is also a lousy benchmark. Any serious vector FP code on a phone (like matrix stuff for a game) would use SIMD with compiler intrinsics or ASM, and probably single precision over double precision. But even as a Dalvik double precision floating point test it sucks because it's not tiled and therefore heavily bandwidth limited.

    Basically, most of the benchmarks used are awful.
    Reply
  • clockerspiel - Wednesday, April 25, 2012 - link

    The cell phone industry desparately needs a "flagship" representative for the Android ecosystem - and this ain't it! Reply
  • jjj - Wednesday, April 25, 2012 - link

    You can't normalize battery life unless you factor in the screen size since the screen uses a lot of power and the handset's volume is directly related to the screen size and battery size.
    By normalizing you are making things worse than better.If you can't measure the power consumption for just the SoC you might as well just provide the system's battery life since,in the end, that's what matters anyway.
    It is what it is,you can't take out the screen or the RAM or the NAND but that's no reason to make things worse with tests that distort the reality instead of helping.
    Reply
  • menting - Wednesday, April 25, 2012 - link

    uhh, it's not measuring the power consumption for the SoC, it's measuring the whole phone's power usage. So in this case, normalizing IS a valid way to go about this. Reply
  • plamengv - Wednesday, April 25, 2012 - link

    It is beyond me why Intel will market x86 CPU with OS that has nothing to do with x86. The people who want Android will always go with the better looking and cheaper device. Something that this device is not. The other with knowledge will go for iPhone because there is no other alternative. Windows Phone is from professional point of view worse than Windows Mobile 6.5 and lacks lot of features. Intel had to bet on Windows 7 turning the smartphones into UMPC. Imagine Viliv S5 shrinked to Galaxy Note but running Windows 7! Well maybe Haswell and 22nm will finally make it. Reply
  • menting - Wednesday, April 25, 2012 - link

    android was built from Linux..tell me where Linux has nothing to do with x86. And with future android versions including x86 compiles by default., x86 or not isn't an issue.

    The X900 is a reference design, who says other companies can't put a different external case on it? And where's proof that it will be more expensive?
    Reply
  • superPC - Thursday, April 26, 2012 - link

    why windows 7? windows 8 would be a lot better suited for something similar with this phone (with compatible GPU). Reply

Log in

Don't have an account? Sign up now