When size matters

So you have a 10-incher and she still complains about it being tiny.

Don't worry, she isn't talking about your Android tablet, she's talking about the Analog Clock widget and now the solution is just a click away.

It's time to stop being ashamed and enlarge that Clock of yours because guess what? Size matters...

Get it here: https://play.google.com/store/apps/details?id=com.apedroid.clockwidget

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.

External Keyboard Helper Pro 5.9 released

What's new in version 5.9

• Fixed an error in the Hungarian layout
• Fixed ALT+KEY problem with Emacs for Dvorak users. ALT+KEY was using original layout if not remapped.
• Fixed problem with remapped Ctrl key for Emacs users.
• Updated translations.

Get it now from Google Play

Last day of External Keyboard Helper Pro at half the normal price

Today at midnight (GMT+1) the offer at AndroidPIT.com ends. Last chance to buy the app at less than half the normal price.

External Keyboard Helper Pro reviews in 8 languages

With External Keyboard Helper Pro being the App of the week over at AndroidPIT.com they've also published a review of the app that is available in 8 different languages.

Here's direct links to the reviews:

• French
• Turkish
• Russian
• German
• Italian
• Spanish
• Portuguese
• English

Manually updating your Nexus 7 (wifi only) to Android 4.2.2

I've also manually updated a Nexus 7 (wifi only) using the same method as I used on my Nexus 10.

This is totally done at your own risk but it worked fine for me.

Since this is an update that patches the already installed system I strongly advice against trying this on anything but an non-rooted JOD40D device. 

Just follow the same steps as in the Nexus 10 guide but use this OTA file instead.

Manually updating your Nexus 10 to Android 4.2.2

I just manually updated my non-rooted, stock Nexus 10 from Android 4.2.1 (JOD40D) to Android 4.2.2 (JDQ39).

This is totally done at your own risk but here is what worked for me.

Since this is an update that patches the already installed system I strongly advice against trying this on anything but an non-rooted JOD40D device.

• Download the JOD40D to JDQ39 update.
• Make sure you have ADB up and running. I used this guide.
• Turn off the Nexus 10.
• Start the Nexus 10 while holding down both volume up and down.
• You should get an Android lying on it's back and some device information.

• Press volume down until the left vertical text says "RECOVERY MODE"

• Press power to reboot into recovery mode. 
• You'll now get a smaller Android robot, still on it's back, with a red triangle.

• Hold power and press once on volume up to enter the recovery menu.

• Press volume down to select "apply update from ADB"
• Press power once.
• It will now tell you to type "adb sideload <filename>" so connect the Nexus 10 to your computer with the USB cable if you have not already done so.

• On the computer type "adb sideload eaef14432ff5.signed-mantaray-JDQ39-from-JOP40D.eaef1443.zip" and watch the magic happen.

App of the week on AndroidPIT.com

Starting today and ending on the 17th of Februari 23:59 (GMT+1), External Keyboard Helper Pro is App of the week on AndroidPIT.com.

That means you get buy it for only $1.48 (1.06€) during the campaign.

It's the end of the WoT as we know it...

The end is near, only about 900 pages away now... The last and final book of Wheel of Time, a fantastic story started by the late Robert Jordan and now finished by Brandon Sanderson.

I got it few days ago but haven't started reading yet. While waiting I've read through most of Brandon Sandersons books and I was halfway through Warbreaker when the book arrived and I wanted to finish it first. Before that I read through the Mistborn Trilogy, The Alloy of Law, The Way of Kings, Legion and The Emperor's soul.

12 years after I started reading the first Wheel of Time book I will now read the final volume. To bad Robert Jordan isn't here with us to see the completion of his masterpiece.

EKH Tutorial 6 - Workaround for Samsung devices

The is the sixth tutorial for External Keyboard Helper. You'll find a all the tutorials here.

This tutorials is only interesting for Samsung users. I'm going to use my Galaxy S3 as an example but the problem is present with most (if not all) Samsung firmwares.

The problem looks like this:

Just a little information popup, how could that be a problem? Well, once you press OK on the dialog it will change your Input Method to "Samsung Keyboard" so it's just not informing you what it thinks you should use, it also makes you use it whether you want it or not.

On my Galaxy S3 this pops up whenever I connect a Bluetooth keyboard but only if "Samsung Keyboard" is not the currently selected Input Method. So let's say I use SlideIT as my preferred Input Method:

 
Now let's say I connect my Bluetooth keyboard and since I'm using External Keyboard Helper it will show the Input Method selector. However first Samsung will show their dialog and then the Input Method selector puts itself on top of it.

So I first select External Keyboard Helper and then I get back to the Samsung dialog and press OK. What happens now is that the Input Method will be switched to "Samsung Keyboard" which is not what I wanted. Not good!

I do not think there is a way to prevent the Samsung dialog from starting unless you are rooted and willing to mess around on your system partition. Still there is a workaround, it's not perfect but it's better than nothing.

What we need to do is to increase the Detection delay in the Advanced settings for External Keyboard Helper. In this example I set it to 4 seconds but most people will probably settle for 2 seconds after getting used to the procedure.

Now we bought us 4 seconds where we can press OK in the Samsung dialog before External Keyboard Helper brings up the Input Method selector. What we do is that we let Samsung first set the Input Method to their own one and then we switch it back to External Keyboard Helper.

So by setting up a delay we can make sure that Samsungs switch takes place before our switch and not the other way around.