how-to manual mod
how-to mod any firmware or mod on your phone step-by-step

I have learnt a lot from this forum and a few others. I think I should document where I am and how I have modified my firmware, if it helps others. I suppose this is the ethos of open source - learn from others, build on it, and pass it back.

This how-to is for a manual mod on my t-mobile uk 2.1 pulse firmware. In hindsight, I should have started out with the Swedish 2.1, as that is more vanilla. You could do the same with any firmware, any mod or possibly any android device. Rebuild your existing setup, or choose your favourite stable mod, put in on your phone, and start modding yourself. Only caution, I would advise, is to understand what you are about to do (or have a backup), before you make any change. I will list any detailed steps or commands required, where possible or asked for. As such, there are no downloads within this how-to. All downloads are from the android market and/or the android sdk. Ask if you can't find something...

I have done a lot of trial-and-error and subsequently found that many others have been there and done that, ending mostly at a stage better than me. I am still an android newbie comparatively, and by no means an expert or a programmer, though I have been using linux for a few years, and understand c and shell-scripting a little bit. What I list below is running fine on my pulse, and I have had no current issues whatsoever. What you do with your system is entirely your risk. At the very least, make backups at every stage. Don't be afraid of trying out anything. I haven't heard of any instances where a phone has gone totally ka-put!

My main vision was to clear out whatever I could from /system, and fill it up with what I needed, to reclaim /data and keep it as free as possible. The less there was to worry about, the easier it is to work with what is left.

The next goal was to bring it as close as possible to the vanilla firmware. My personal recommendation is to keep as close to upstream as possible, and any required changes to be pushed upstream! Focus for upstream is on generics, and for downstream is on specifics. And this goes for everything - os, kernel, apps, configs, etc. The farther we diverge from upstream with our changes, the more complicated and error-prone will be any further updates. And this increases exponentially with time and down the roadmap. If anyone from t-mobile/huawei (or any others for that matter) is reading this, please take note!!!

It seems t-mobile/huawei have gone all-out to customise their firmware so much that, I suspect, it is going to take them a lot of effort in bringing out new updates, which possibly means that any android updates would be very late in coming, at best. We can see this, with the adventure t-mobile are still having in releasing a 2.1 uk update, while the rest of the world are getting 2.2. Perhaps, t-mobile should consider stripping out all customisation and keeping as close to the vanilla firmware, as possible. This should certainly save them a lot of customer-aggro, time and money in releasing new updates. I suspect some t-mobile developers are making sure they keep their jobs...

Final goal was to tweak and make the firmware more efficient in terms of power, speed, basic phone call performance, etc.

What I have not considered is themes/eye-candy, etc. I am inherently a minimalist, and I prefer no distractions. I have removed all wallpapers, boot-animations, spurious/large ringtones, etc. This reclaims much space, some speed and power.

The quickest and easiest method that I preferred was to boot into recovery mode and use adb via usb. If you don't have (or want to use) the usb cable, adb can connect to your mobile via wi-fi too. I use linux and my laptop runs debian lenny.

Create a text file named "/etc/udev/rules.d/51-udev.rules" with contents
SUBSYSTEMS=="usb", SYSFS{idVendor}=="12d1", MODE="0666"

adb (android debug bridge) is the only tool we need on our computer. You can find more info at I will list what is required below.

I have copied adb into ~/bin, and it is in my path. You need to do something similar, or prefix the whole path to adb each time.

Starting the adb deamon as root, is the first step.
$ sudo adb start-server
* daemon not running. starting it now *
* daemon started successfully *

It seems, the adb deamon does not work if started as an unprivileged user. If it is already running you need to kill it first, before starting as root.
$ sudo adb kill-server

Now you can run all adb commands as a normal user, i.e.
$ adb devices
List of devices attached
???????????? recovery

Ignore those question marks. For a long time, I assumed that they meant I had no connectivity, and it threw me off. If you don't see any lines, then you need to worry and start troubleshooting.

Now, we need to mount the devices.
$ adb shell mount -a

Finally, we are ready to start playing (or hacking)...
$ adb shell ls -l /system/app
$ adb shell ls -l /data/app

Other commands that I've used are: cp, rm, push, pull, reboot and reboot recovery. Nothing too complicated. :-)

One command I particularly find useful is "sort". I periodically list all app sizes and prune the bigger ones out, replacing them with smaller ones from the market. App size does matter, as it means the developer is particular about efficient coding, and it eliminates waste on your phone. Any time an app starts going bloatware, I stop using it and uninstall. I continously look for more efficient apps.
$ adb shell ls -l /system/app | sort -n -k5
$ adb shell ls -l /system/app | sort -n -k5

Apologies in advance, if people find these initial posts changing often. I will update all information here, rather than in a separate post each time, so we might not need to scour all the posts in this thread to find the last update. Also, all tips gratefully received. Please bear in mind that all the information here is credited to others, and I'm happy to mention names where required.

No comments:

Post a Comment

most viewed