Pages

Thursday 11 September 2014

Rooting + CyanogenMod 11 (Android KitKat 4.4.4) on LG G2 L01F DoCoMo

I have an Android LG G2 L01F contracted with DoCoMo in Japan. Can you add any more bloatware DoCoMo?? Geez there is a lot of unnecessary crap that you can't uninstall. And don't get me started on their Phone app, it's like a prepubescent kid who spent 3 hours at Android kiddy school developed it. It's buggy and the UI/UX is horrible as. If I click the call button I expect it to call, not react a minute later!

Anyway, for the reasons above and more I decided to take the brick risk and ROM my phone. And it worked. And it was rather simple. I did a temporary root, then upgraded from the ugly DoCoMo 4.2.2 to KitKat 4.4.4 with the CyanogenMod 11 ROM.


  1. Download the USB serial driver for LG from here. Install it. I did it on Windows 7 64bit.
  2. Make sure your phone is in Developer Mode (Google if not sure: Hint: Press Build Version 7 times) and USB Debugging is enabled.
  3. Download the latest nightly build of CM11 from here.
  4. Download the latest gapps-kk-* from goo.im/gapps if you want Google Play, G-mail ... i.e. all the Google apps (I used this)
  5. Unzip CM11 and change all "l01f" to "L01F" in the following files (I did this because of some silly case-sensitive model-number checking during the CM11 installation):
    META-INF/com/android/metadata
    META-INF/com/google/android/update-script
  6. Re-zip the file with the above modifications.
  7. adb push <CM11 zip file> /sdcard/   (if you don't know what adb is, look up setting up an Android Development environment, or find another way to copy a file to your phone's sdcard)
  8. Also copy gapps to the same place.
  9. Download the rootkit here, unzip it, plug in your phone and run Rootkit.bat. This rootkit seems to use some exploit to gain temporary root access. When prompted, press a key/enter to finish the batch script's installation. Your phone will reboot into CMW. If you reboot your phone normally you'll lose your root access and need to run Rootkit.bat again.
  10. If all went well you'll be booted into something called CMW, ClockworkMod W??? (forgot). You can use this to back up your current system and install a new one. DO A BACKUP NOW!
  11. Then wipe.
  12. Then choose install from zip and choose the CM11 zip file your copied to the sdcard. If all goes well it should install.
  13. Repeat the same for gapps.
  14. Reboot and wah-lah you should have CM11 4.4.4 on your Japanese LG G2 L01F!

Sunday 16 March 2014

Running ARM apps on Android x86

Well a year's passed since my last post. It's been a busy one at that! Feel free to skip to the bottom if you just want the instructions on how to get libhoudini running on Android x86...

These past few months I've being playing with a customized flavour of Android x86 and virtualization (I'm loving OpenStack!). For those of you who don't know it's a project to get Android running on various Intel x86 architecture based platforms based of the vanilla Android Open Source Project from Google.. Yes, that's right - you can run native Android on your PC or Mac! No more horrendously slow Android Emulator.

Well, almost.

Android x86 runs super fast on most bits of Intel hardware. The majority of apps will function fine as well, at least if they're 100% written in Java. But the fact is a lot of apps also have native libraries built into them (compiled using the NDK and written usually in C or C++). When developers prepare an app for release they can choose what architecture(s) to compile their native library binaries for. Most will at least compile for ARM but in the interest of cutting down on the size of the APK a lot skip x86 and others (MIPS etc). Google Play does apparently allow you to have a separate APK for each architecture so you won't need to worry about having a few useless-to-the-many MBs of x86 code in the APK that your ARM users install. Many developers maybe unaware of this feature, and I'm sure some developers are just not aware that x86 versions of Android devices are emerging more and more.

So where does that leave us? You emulate ARM architecture on your x86 hardware. From what little research I've done into the Android Emulator itself, I believe the entire OS is ARM based so there's a tonne of constant emulation that needs to be done, hence the major performance cost. With Android x86, most of the code is executed natively (i.e. critical/normal programs run fast) and the code that is only available in ARM compiled binaries is translated real-time into instructions your x86 CPU can understand.

This is done with a little library called Houdini. libhoudini is a Binary Translator (translates ARM ABI to x86 ABI) developed by Intel and is close sourced. The information on the internet is really sparse and there's a lot of broken links so I'm hoping this blog article will stay around for a while and be helpful to some. From what I gather the original libhoudini libraries were ripped from a Lenono K900 device that runs x86 hardware. Intel must've provided their binaries to Lenovo for release. That work was done by the BuilDroid project which seems to have changed names to AndroVM and now Genymotion (a great online Android Emulator that allows you to choose a range of device types, resolution types, Android versions etc).

So on to the fun stuff, the instructions on how to get libhoudini installed and configured on Android x86. I just test against a branch based on the 4.2.2 tree so I can't say how well it'll work on other versions.

1. Have the AOSP project source code download and the build environment all setup. We'll call this $AOSP.
2. Download and unarchive libhoudini-patch-and-binaries.tgz.
3. Copy the contents of <...>/libhoudini-patch-and-binaries/system/lib to $AOSP/out/target/product/<product name>/system/lib
4. cd $AOSP/dalvik
5. git apply -v <...>/libhoudini-patch-and-binaries/jb-houdini.patch
6. Add the following line to $AOSP/device/<your hardware manufacturer>/<device name>/system.prop (e.g. device/ibm/thinkpad/system.prop):
ro.product.cpu.abi2=armeabi
7. Build and deploy your Android x86 OS.
8. Try running an app with ARM-only libraries and if it doesn't crash you're lucky!

I had success running my own apps, Facebook and Angry Birds.
I didn't have much luck with Unity based games.