LG G3 (D855): How to remove custom carrier boot and shutdown animations

Tired of your carrier from dropping a custom boot and shutdown animation? Like Movistar does? Do you have an LG G3 D855 phone? Is it rooted? Then it’s just a matter of removing the following files:

adb shell
su -
rm /data/shared/cust/bootanimation.zip
rm /data/shared/cust/shutdownanimation.zip

This will, hopefully, revert to using the stock boot and shutdown animations.

Enable more locales / languages on Android phones

Some phones only offer a very limited list of locales / languages for the user to choose from. Such an example is the HTC One phone that I once bought in Switzerland. This phone only allows, by default, English, German, French, Italian and Turkish. However, thanks to MoreLocale2 it is possible to unlock other languages like Spanish (Spain).

In order to unlock more locales / languages, install MoreLocale2 from the Google Play Store, run it and follow the steps described in the application itself. It requires granting the┬áCHANGE_CONFIGURATION privilege to itself by either using the “pm grant” command from an ADB shell, or for rooted phones, the application can grant the permission by itself.

More information about this wonderful application can be found here: http://udhyantimilsina.wordpress.com/2013/08/15/how-to-unlock-developer-mode-to-set-multiple-languages-on-android-os-4-2-2/

Turn Android’s status bar opaque

Some custom Android ROMs include MODs that change the translucency of the status bar. In case you want to remove this customization and return the status bar to be completely opaque (0% translucency), you can follow these instructions that I compiled from the following resources: [MOD][ICS – LP*/CM9] Translucent status bar

Extract

First, extract the SystemUI APK file from the Android device, including required dependencies, and decompile it:

mkdir ~/works
cd ~/works
git clone https://github.com/mateor/auto-patcher.git
export PATH=$PATH:~/works/auto-patcher/patch_tools:~/works/auto-patcher/patch_tools/linux
cd ~/works/auto-patcher/patch_tools/
mkdir ~/works/auto-patcher/patch_tools/signtools
mkdir ~/works/auto-patcher/patch_tools/signed
adb pull /system/app/SystemUI.apk SystemUI.apk
adb pull /system/framework/framework-res.apk framework-res.apk
adb pull /system/framework/twframework-res.apk twframework-res.apk
java -jar apktool.jar if framework-res.apk
java -jar apktool.jar if twframework-res.apk
java -jar apktool.jar d -f SystemUI.apk

Patch

These are the differences between the original SystemUI APK file that is using transparency for the status bar, and a patches SystemUI that has an opaque status bar:

diff -ur SystemUI/res/layout/super_status_bar.xml SystemUI.new/res/layout/super_status_bar.xml
--- SystemUI/res/layout/super_status_bar.xml    2013-06-04 18:02:35.280902774 +0200
+++ SystemUI.new/res/layout/super_status_bar.xml        2013-06-04 17:48:40.430939995 +0200
@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="utf-8"?>
-<com.android.systemui.statusbar.phone.StatusBarWindowView android:background="@*android:color/transparent" android:focusable="true" android:fitsSystemWindows="true" android:descendantFocusability="afterDescendants"
+<com.android.systemui.statusbar.phone.StatusBarWindowView android:background="#FF000000" android:focusable="true" android:fitsSystemWindows="true" android:descendantFocusability="afterDescendants"
   xmlns:android="http://schemas.android.com/apk/res/android"
   xmlns:systemui="http://schemas.android.com/apk/res/com.android.systemui">
     <include android:layout_width="fill_parent" android:layout_height="@*android:dimen/status_bar_height" layout="@layout/tw_status_bar" />
     <include android:layout_width="fill_parent" android:layout_height="0.0dip" layout="@layout/status_bar_expanded" />
-</com.android.systemui.statusbar.phone.StatusBarWindowView>
\ No newline at end of file
+</com.android.systemui.statusbar.phone.StatusBarWindowView>
diff -ur SystemUI/res/values/drawables.xml SystemUI.new/res/values/drawables.xml
--- SystemUI/res/values/drawables.xml   2013-06-04 18:02:37.173902690 +0200
+++ SystemUI.new/res/values/drawables.xml       2013-06-04 17:57:44.172915753 +0200
@@ -52,7 +52,7 @@
     <item type="drawable" name="APKTOOL_DUMMY_020d">false</item>
     <item type="drawable" name="notification_number_text_color">#ffffffff</item>
     <item type="drawable" name="ticker_background_color">#ff1d1d1d</item>
-    <item type="drawable" name="status_bar_background">#00000000</item>
+    <item type="drawable" name="status_bar_background">#ff000000</item>
     <item type="drawable" name="tw_status_bar_quicksetting_button_background">#ff000000</item>
     <item type="drawable" name="status_bar_recents_app_thumbnail_background">#88000000</item>
     <item type="drawable" name="status_bar_notification_row_background_color">#ff090909</item>

Rebuild

Build and sign the patched SystemUI application:

java -jar apktool.jar b -f SystemUI signtools/SystemUI.apk
java -Xmx64m -jar signapk.jar updatecert.pem updatekey.pk8 signtools/SystemUI.apk signed/SystemUI.apk

You can push this APK back to your /system/app directory and then reboot:

adb push signed/SystemUI.apk /system/app
adb reboot

Android USB Tethering and Mac OS X

I have tried several ways of tethering my Mac laptop to my Android phone, but I think that USB is the most effective one, at least from a subjective point of view: it doesn’t use as much battery as Bluetooth or WiFi tethering, it seems safer from a security point of view since it transmit the data over a cable, and it also seems safer from a health point of view as it does not rely on yet another wireless emitting point.

In order to get Mac OS X to tether with my Android phone over USB, I had to install Joshua Wise‘s HoRNDIS. It is a Mac OS X package that implements a kext RNDIS driver. The beauty of it all: it is open source and straightforward to set up and use: download the package, install it, connect your Android phone to your laptop using an USB cable, enable USB tethering and it should work automatically, without having to do anything. Magic!

PS: A copy of the HoRNDIS release 4 package can be found here.

OpenPDroid

One of the things that I really miss in Android is the ability to selectively disable certain permissions for applications. And this is the main reason why I refuse to install some applications, like WhatsApp: I don’t want to have a spy in my pocket which can record voice, read my mails, my SMS/MMS messages, access the network with no restrictions, etc. No, no and no. I do care about my privacy and the security of my data.

Today, while reading some forums, I read about OpenPDroid. OpenPDroid seems to be a collection of patches that can be applied to certain AOSP ROMs. These patches allow precisely what I’m looking for. From http://forum.xda-developers.com/showthread.php?t=2098156:

OpenPDroid is a set of modifications to the Android framework and libraries which allows fine-tuning of the data which applications are able to retrieve about your device, your account, your messages, and more. Specifically, it is a Privacy service provider (using the PDroid 1.51 interface) forked from CollegeDev’s PDroid 2.0, which is itself an extension of Syvat’s PDroid.

There’s an auto-patcher tool that takes a custom AOSP ROM in the form of a ZIP file, applies the patches to it and generates two new ZIP files (e.g. to be installed with ClockworkMod recovery): one to install OpenPDroid and another one to uninstall it.

I have built the auto-patcher from the git repository and tried to patch cm-10.1-20130131-NIGHTLY-n7100.zip:

$ git clone https://github.com/mateor/auto-patcher.git
$ cd auto-patcher
$ ./batch.sh
$ ./auto_patcher cm-10.1-20130131-NIGHTLY-n7100.zip openpdroid
...
### finished ###
flash update-cm-t03g-20130131-openpdroid.zip to install the patched files
flash restore-cm-t03g-20130131.zip to restore the original system

I haven’t flashed OpenPDroid yet. I’ll probably try on another phone first, as I saw that some patches that were applied by the auto-patcher failed entirely to get applied.

In-call sound problems with CyanogenMod CM10.1

After rooting my Samsung Galaxy Note 2 and switching to CyanogenMod CM10.1, I’m randomly having issues with in-call sound problems, specially when upgrading to a new nightly build. Sometimes after an upgrade, the speaker on the phone is mute when making calls. That means I can’t hear the ring tone or the person on the other end of the line.

Googling for the solution, I found this thread in XDA developers. Turns out a potential solution consists of turning on the screen lock sound and rebooting. I have used this trick once and it worked. Amazing!

OpenVPN Server and OpenVPN Client on Android

The OpenVPN server configuration:

# cat /etc/openvpn/server.conf
port 1194
proto udp
dev tun

ca /etc/openvpn/open-rsa/keys/ca.crt
cert /etc/openvpn/open-rsa/keys/server.crt
key /etc/openvpn/open-rsa/keys/server.key
dh /etc/openvpn/open-rsa/keys/dh1024.pem

server 10.8.0.0 255.255.255.0
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"

keepalive 10 60
comp-lzo
persist-key
persist-tun
status 1194.log
verb 3

client-config-dir ccd

The client-specific configuration, which specifies which subnets are accessible on the client:

# cat /etc/openvpn/ccd/android
iroute 10.42.242.0 255.255.255.0

Enable IP forwarding

# grep ip_forward /etc/sysctl.conf
net.ipv4.ip_forward=1
# sysctl -p

Enable NAT

# iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
# service iptables save

Export the client certificate and private key using PKCS12 in order to then import them into the OpenVPN Client for Android:

# openssl pkcs12 -export -in /etc/openvpn/open-rsa/keys/android.crt -inkey /etc/openvpn/open-rsa/keys/android.key -certfile /etc/openvpn/open-rsa/keys/ca.crt -name android -out /tmp/android.p12

The resulting android.p12 file can be sent to the Android device, and from there have it imported into the OpenVPN Client for Android.

Flashing a US/CDMA 3G+WiFi Xoom Honeycomb ROM onto a European/UMTS one

This post describes how to hack a US/CDMA 3G+WiFi Xoom Honeycomb OTA ROM image to be flashable onto a European/UMTS 3G+WiFi Xoom.

First, get a US/CDMA Honeycomb OTA image. I won’t tell you how to get it, but you’d better get it from an authorized source and make sure it hasn’t been compromised or tampered with. Flashing random ROMs downloaded from random Web sites is a recipe for disaster.

Let’s say the OTA image is named xoom-ota.zip. Proceed to unzip its contents:

$ mkdir ota && cd ota
$ unzip /tmp/xoom-ota.zip

Now, one has to edit the update-script to prevent the OTA process from trying to replace the UMTS radio with a CDMA radio:

--- orig/META-INF/com/google/android/updater-script 2008-02-28 18:33:46.000000000 +0100
+++ ota/META-INF/com/google/android/updater-script 2011-07-14 13:40:04.000000000 +0200
@@-53,10+53,6 @@
show_progress(0.200000, 10);
package_extract_file("boot.img", "/dev/block/platform/sdhci-tegra.3/by-name/boot");
show_progress(0.100000, 0);
-assert(package_extract_file("bp.img", "/tmp/bp.img"),
- package_extract_file("rdl.bin", "/tmp/rdl.bin"),
- moto.update_cdma_bp("/tmp/rdl.bin", "/tmp/bp.img"),
- delete("/tmp/bp.img", "/tmp/rdl.bin"));
assert(package_extract_file("bootloader.bin", "/tmp/bootloader.bin"),
moto.set_mbm_update("/tmp/bootloader.bin"),
delete("/tmp/bootloader.bin"));

Now that the patch has been applied, let’s re-zip the modified tree into a new OTA ZIP file:

$ zip -r ../update.zip *

In order to apply the OTA onto the Xoom you’ll likely need to install the ClockWorkMod recovery image, since at the time of this writing Xoom’s stock Android recovery can’t access the contents of the internal SD card partition. It seems, however, that Xoom’s stock Android recovery can access external USB storage devices.

In order to copy the hacked OTA image use:

$ adb push ../update.zip /mnt/sdcard

In order to install ClockWorkMod, you’ll need to download the recovery image. The easiest way is by installing “ROM Manager” into your Xoom from the Android Market. ROM Manager allows one to flash the recovery image on rooted Xooms automatically. If your Xoom isn’t rooted don’t worry as ROM Manager will still download the recovery image and place it somewhere under /mnt/sdcard/clockworkmod. From there, pull the image into your PC:

$ adb pull /mnt/sdcard/clockworkmod/.../recovery-clockwork-4.0.0.4-stingray.img

Then reboot the Xoom into the bootloader:

$ adb reboot bootloader

Once the fastboot protocol has been enabled (as shown on the screen):

$ fastboot flash recovery recovery-clockwork-4.0.0.4-stingray.img

Then reboot into recovery. It is important to reboot into recovery right away. Booting the system normally will likely reflash your recovery partition with the stock one, replacing ClockWorkMod. To boot into recovery, reboot the device:

$ fastboot reboot

Wait for the Motorola Dual-core logo, then tap the Volume Down key several times until the Android recovery option is shown on the top-left of the screen. Then press the Volume Up key to enter the recovery menu.

Once in the ClockWorkMod recovery, request to apply an update.zip image from the internal SD card partition. Navigate the menus using the Volume Up and Volume Down keys, and select an option by using the power button on the back. The update process will start and everything should apply smoothly. Next, wipe the cache and user data partitions, reboot and cross your fingers.

Suffice to say that you’ll lose 3G capabilities on your Xoom. It seems no one cares about Europe, not even Google, so Motorola still has Honeycomb 3.0.1 for us Europeans (instead of 3.1 or something newer like 3.2). And since 3.0.1 is so unstable and slow, I decided to upgrade to the latest Honeycomb build.

Perhaps one day people will take Europe seriously and release synchronized versions for the US and Europe (and also the rest of the world).