Watch out for flying pigs

I wouldn't be surprised if pigs started to fly soon, because guess what, Spotify no longer looks like this on my tablets...

...and Google Play can no longer be unsecured by clearing it's data:

The Samsung Galaxy S4 that I first pre-ordered and then canceled after trying a Nexus 4 because I realized how much I missed using Android the way it was supposed to look without any Touchwiz, Sense or other manufacturer added crap^H^H^H^Hmodifications will soon also be sold with an non-modifed Android.

And HTC follows with their flag ship model HTC One making me actually consider a HTC as my next phone (No offense Samsung but having had an S3 recently before switching to a Nexus 4 makes it feel a bit boring to get a new Samsung that looks almost the same as the last one I had).

Now let's hope more manufacturers follow Samsungs and HTCs example...

... and if it isn't to much to ask for, a flying pig? Or at least an Android 4.3 release soon?

How to check if an app uses binary translation

Binary translation is used by Intel based Android devices in order to run apps that are uses native ARM code. This is good for compatibility but bad for performance as native x86 code in the app would be a better solution.

So how can one tell if an app uses binary translation instead of native x86 code? Well, first you must have an Intel based Android device like the Asus Fonepad or this would be rather pointless. Second you need to have a way to read the android logs. I use the command logcat but there are also apps that can be used for this.

Luckily the Asus Fonepad includes a busybox binary that has the "grep" command built in. That saves a lot of time and I'm using an adb shell connection and this command "logcat | busybox grep houdini".

shell@android:/ $ logcat | busybox grep houdini
logcat | busybox grep houdini
D/houdini (11555): [11555] Loading library(version: 3.1.3.43168 RELEASE)... successfully.

Here we can see that an app with PID 11555 has activated libhoudini.so which is the lib that does the ARM to x86 binary translation.

So let's find out what app is using PID 11555 (once again I use grep to save some time).

shell@android:/ $ ps | busybox grep 11555
ps | busybox grep 11555
u0_a117   11555 128   1034944 45356 ffffffff 00000000 S com.spotify.mobile.android.service

It turns out Spotify uses native code but only includes ARM code.

Binary translation vs native x86 code

I recently bought an Asus Fonepad partly because I wanted to test an Intel based Android device. It turned out it's a really nice device and surprisingly almost everything I tried on it worked well. I didn't expect this since many apps contains native code and a lot of them only comes with native code compiled for ARM based devices.

After some research I found out that Intel based Android devices comes with a library (libhoudini.so) that uses binary translation to translate native ARM code into native x86 code. This explains the very good app compatibility but it also made me wonder how much performance we give up for compatibility.

As I noticed that the Epic Citadel app performed almost identical on my Nexus 4 and the Fonepad I had a look into the apk and noticed it comes with native code for both ARM and x86 devices. That gave me an idea and I created two versions of the apk. On version only contains the native ARM code and the other only the native x86 code. That allowed me to do a comparison and here's the results.

The tests was made on an Asus Fonepad with firmware version 3.1.17 and version 1.0.5 of the Epic Citadel app.

First out is the version with only native ARM code:

Then another run with the version with only native x86 code:

As you can see the version with native x86 code scored over 40% better compared to the version that relied on binary translation.

So while the binary translation is a good thing for compatibility there is also a risk that developers takes the easy route and decides not to include native x86 code for their apps.