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.
In order to backup your Android device, you don’t need to have your device rooted. Using ADB, one can backup applications and their data:
$ adb backup -apk -all -f backup.ab
To restore:
$ adb restore backup.ab
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/
For those of you that have ROM Toolbox Pro, to get access to Ad Blocker, just open slide to the left, long press on DNS Changer and there you go.
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
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
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>
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
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.
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.
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!
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.
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).
felipe-alfaro.com 