What's new
DroidForums.net | Android Forum & News

This is a sample guest message. Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members through your own private inbox!

[Root] File System Tweaks and Tips

jntdroid

Super Moderator
Premium Member
So you finally rooted your Thunderbolt, now what? There are some great apps out there that take advantage of being rooted. There are some great custom ROMs, and those will greatly increase on the Thunderbolt in the near future, I'm sure. But what can you do yourself now that you have access to all of these files?

Personally, I'm a fan of rooted stock - always have been. There are some great ROMs out there, but I like my phone the way it came, but with full access. I know exactly what I want to do with my phone once it's rooted, and thought I would share some of the tweaks you can also do, simply by knowing where to look and how to do it.

Disclaimer 1: I use Root Explorer. Always have and probably always will, and I think it's one of the more popular rooted/file system apps out there - all my instructions will be based on how it's done in Root Explorer.

Disclaimer 2: I'm no developer. I know a little adb and have some coding background, but I'm no developer. So here's your grain of salt ahead of time...

Disclaimer 3: A lot of these will apply to other Android phones besides the Thunderbolt. I've owned a Droid 1, HTC Inc, and Droid X before the TB. I'll make note of the items that apply to all of them vs. just the TB. Some of these will likely apply to any Android phone, but I don't want too assume to much about other manufacturers and what they do to the OS structure.

I will continue to add to this as I think of things or as people add them in the thread. Also if you have other apps you use besides R.E., that work pretty similar, please mention them as well.
 
Last edited:
I'll indicate in each subject which phone it applies to (TB, DX, DInc, D1, other Android phones).

Rule #1 - backup... nandroid, Titanium, etc. - backup first. Some of these tweaks are simple, and some of them are not. I'm not responsible if you take any of this on and don't backup first. I highly recommend a nandroid backup before doing anything so you can, worst case scenario, restore back to normal through recovery.
Rule #2
- I rarely delete any files. More often than not, I simply rename it from filename.apk to filename.apk.bak.
Rule #3 - For those unfamiliar with Root Explorer, longpressing on a file or folder is the key to bringing up options like renaming, copying, changing permissions, etc.
Rule #4 - Speaking of permissions... almost all tweaks require the file to have the permissions set to "644", and that is how I'll refer to it from this point forward. If it's any different, I'll specify. 644 permissions look like THIS
, and under the filename, it should read "rw-r--r--". To edit permissions, you simply longpress on the file and select Permissions.

So let's get started...


Boot Sound Removal/Customization (TB only)
:

The first thing I wanted to do when I got my Thunderbolt was get rid of that boot sound. It scared the heck out of my wife more than once late at night as I was tinkering, and it wasn't real inconspicuous if I did any tinkering/rebooting at work. The name of the file is FinalThunder.mp3, and the location is /system/customize/resource/. Simply longpress and rename to FinalThunder.mp3.bak.

This would also be a simple way to customize your boot sound - copy an mp3 from your SD Card into the same path and name it FinalThunder.mp3 - though I recommend staying close to the same filesize as the original. If you do copy a new file into that location, you'll want to make sure it has the permissions set to 644 (see rule #4 above).


Battery Calibration (TB/DX/DInc/D1, and likely others)
:


So you can't actually calibrate your battery in the file system. You can, however, "reset" the file that's used as the "brain" for how Android uses and reports the battery life, for lack of a better word. The file is batterystats.bin and the location is /data/system/ - it's been that location on every Android phone I've owned. If you delete or rename this file, the OS regenerates it upon reboot. Therefore, to get the cleanest start possible, or the cleanest calibration possible, on the final reboot in your calibration, go in and rename the file to batterystats.bin.bak (or delete it) right before you reboot. Do this once you know you'll be using your phone in a "normal" fashion on a day to day basis. That way, your battery will be fully calibrated, and this file will be reading/reporting based on normal usage and a fully calibrated battery. I can't attest to this, but I've read before that it's a good idea to clear this file out on a regular basis anyway (every few months or so).


Ringtones/Notifications/Alarms (TB/DX/DInc/D1, and likely others):


So yes, you can already set custom alarms, ringtones, and notifications off of files that are on your sd card. But what if your sd card is busy? Or is just slow to read for whatever reason? Then your phone will pick some other sound it can get to efficiently to replace what you've set - might not happen often, but is annoying when it does. What I always like to do is move my custom sounds into their appropriate directories in the system - so they're a part of the OS without having the "restrictions" of the sd card. Most of the system sounds are .ogg files, but some are .mp3. The location is /system/media/audio/ and then there are three main directories: /alarms, /notifications, and /ringtones - self explanatory. Copy the files you want for each into the correct directory, and verify that each file has the permissions set to 644 (same as above). You'll likely need to reboot before you can go into settings/sound and see them listed.


Wifi scan interval (TB/DX/DInc/D1, and likely others)
:


By default, your wifi settings (if turned on) scan for a wifi signal every 15 seconds. This can suck up battery life. Most TB owners are simply turning off wifi until they need it. But if you want to improve this area without completely turning it off, there is a way to change how often it scans for wifi. The file is "build.prop" and it's under the /system directory. This file is important, so I don't recommend messing with anything else in this file, and I highly recommend backing it up and never deleting. To change the scan interval, long press the file, scroll down, and select "open in text editor". Now, this part will vary a bit per phone, but you have to find the section where it has the line "wifi.supplicant_scan_interval=**" (** likely being 15). 15 is the number of seconds. Simply change the 15 to your preferred time (in seconds), hit the menu key, then hit "save & exit". Root Explorer should also automatically make a backup of this file for you.


Apps, where are they, can they be "reset proof"? (TB/DX/DInc/D1, and likely others)


First and foremost, if you use this part of the instructions to pull .apk files that are paid apps and send them to others for free or post them online for free, then you are stealing from the developer and appropriate action will be taken if discovered (i.e. we'll never see you again on our forums). If not discovered, then just know that you are stealing from someone who worked hard to create the app, and it's likely not their day job, and they likely have a family to feed. It's piracy, plain and simple.

So, with that aside, there are some benefits to knowing where the apps are installed. For one, you can back them up yourself. I have a handful of apps that I never want to lose, so I keep a copy of the .apk in my file sharing/storage system. And yes, I'm anal. You can also get rid of "bloat" or apps pre-installed on your phone that you don't want. You can also move apps into a location where they will be "factory reset" proof - so if your phone is stolen and that's all they do to it, the app will remain.

Where are they? Most apps you download and install off the market go into the /data/app/ directory - a few go into /data/app-private, and I honestly don't know the difference (anybody?). System apps and "bloat" typically are found in the /system/app directory. To remove bloat, simply go into the /system/app directory, find the .apk files that refer to whichever bloat app you're looking to get rid of and... wait, this is where I'm cautious. Some people simply delete, but I rename to bloat.apk.bak - just in case. Or, to keep it even cleaner, create a "bloat" directory on your sd card and move the .apk's into that directory. That way, it truly gets rid of them, out of your OS completely, but you still have them easily accessible if something goes wrong. Some bloat apps are obvious, but sometimes they're not, and I don't want to mess anything up. So I recommend renaming or moving to the sd card, not deleting.

[Follow up: It would appear that Titanium Backup's "freeze" functionality will have the same result as renaming the bloat.apk to bloat.apk.bak (or whatever you name it). Please see this post for more detail.]

Reset proof? Just know that anything in the /system/app directory will still be there after a factory reset - a factory reset doesn't touch the /system partition. There are a lot of great apps out there for remotely tracking/wiping/securing your phone. If you install these off the market, you can move (not copy) the .apk file from the /data/app directory into the /system/app directory, and it will remain there upon a factory reset. There aren't too many cases where this is helpful, but with the security related apps, it could come in handy. You'll need to reboot after moving any app into the /system/app directory, and it will reinstall upon reboot.


OTA Updates (DX, D1, likely TB and DInc and others)
:


This one came in handy with the D1 when we were trying to grab "master" OTA files for reverting back to stock. Given that the next OTA is likely (not guaranteed) to be 2.3/Gingerbread, this could come in extremely handy when that starts rolling out. So you're rooted, you have access to your entire file system. You get notification that a system update is available. You download it to your phone... where in the world does it go? Well, on the D1 and DX (and likely, but no guarantee, on the DInc, TB, and others), it's a zip file that's placed in the /cache directory. When you go to the /cache directory, it's typically obvious which .zip file it is. The settings/about phone page will typically tell you the filesize, so you can match those up to verify. But the filename will also tend to be some sort of longer, complicated name, as a .zip file. Before you "restart and install", grab that file out of that directory and copy it to your sd card. It'll come in handy in more ways than you know, and the community will want you to share! Oh, and also, if history is any indication, installing just about any OTA update causes you to lose root access.


.
 
Last edited:
just corrected an error/typo under the battery section... had /data/local, it's /data/system
 
Very nice....I use most of these...but can I recommend adding more about Titanium Backup?

Yes...very useful for backup. most know that. But even more useful on my TB was the ability to freeze apps. Stops them from booting at startup and hides them from your app drawer...but leaves them for the phone to recognize on boot up as some will cause bootloops if uninstalled/removed. Just a couple clicks to freeze and just a couple more to undo.
 
I've never used that feature in TB, but I guess that would accomplish the same thing as renaming with .bak. What exactly does it do to the files to freeze them?

sent from a supercell
 
Awesome gonna do this tonight been thinking of what to tweak and have been through the build.prop but haven't messed with much quite a bit more than d1 in there.

Sent from my ADR6400L using Tapatalk
 
i'm with jbg25. i like using titanium backup for removing bloat. if the bloat in question looks like complete crap than i'll do a backup of it than an uninstall (in TB). If I'm not sure about a particular bloat than I freeze it.
 
i'm with jbg25. i like using titanium backup for removing bloat. if the bloat in question looks like complete crap than i'll do a backup of it than an uninstall (in TB). If I'm not sure about a particular bloat than I freeze it.

Yeah I agree as well, just haven't had a chance to update it yet (kids go down soon!).

I still (and this isn't holding me up, I'm just curious) want to know what TB does when it "freezes" an app. I tested and couldn't figure out what it was doing - permissions looked the same, files were in the same place in /system/app or /data/app, as well as /data/data (tested a few different ones).
 
Im fairly certain that TB simply uninstalls the apk.

Everything else is speculation, but looking at system/app i see no files renamed which I have frozen.
 
It has been brought to my attention, more than a couple of times, and rightly so, that Titanium Backup's (TB from this point forward) "freeze" functionality is the easiest way to take care of "bloatware". While I don't disagree with this, I had to do some digging before I decided whether or not to include it in the main guide. So here's what I've learned...

This is from TB Wiki Technical FAQ page (#8):

Question: Does "freezing" apps free space from phone memory?
Answer: No, it doesn't. The "frozen" app remains on the phone with its data, it's just that the app gets completely disabled until you "defrost" it.

It was also explained to me that one of the biggest purposes of "freezing" an app is to be able to "mod" it without worrying that updates will wipe out any customizations. Therefore, in my feeble mind anyway, it appears that freezing will have the exact same result as renaming the .apk to something like bloat.apk.bak or bloat.apk.old. So, if you plan on only renaming and not deleting or moving anything, TB is an easier option with which to accomplish that goal. However, one of the purposes of the original post was education, and I still believe doing it manually is a good way to learn - at least the first time around... especially since we don't know what "freezing" is actually doing.

However, this is still not as efficient and clean as actually deleting or moving (to your sd card or some backup area) the bloat app. As long as it's an app you know can safely be removed, that will be the best way as it will free up not only the space taken up by the .apk, but also by the associated data.

Big thanks to hedney3 for helping clarify and explain some of this to me!

And for goodness sakes, if anybody can tell us exactly what TB is doing to "freeze" an app, that would be awesome. I've tested numerous apps and looked in /system/app and /data/data (not sure where else to check?) and can't tell what it's doing. :confused:
 
Last edited:
Well I cant upload the logcat from my phone, but i suggest you run alogcat and then freeze/unfreeze an app. I found some interesting actions.
 
Well I cant upload the logcat from my phone, but i suggest you run alogcat and then freeze/unfreeze an app. I found some interesting actions.

good idea... i'll give that a go tomorrow when i'm back on my adb computer... isn't there a way to save a logcat or copy/paste it? we'll see... i'm resisting the temptation to tinker tonight so i can get some sleep for a change...
 
This is the log report when freezing the stock android live wallpapers package.

D/AndroidRuntime( 5018):
D/AndroidRuntime( 5018): >>>>>>>>>>>>>> AndroidRuntime START <<<<<<<<<<<<<<
D/AndroidRuntime( 5018): CheckJNI is OFF
D/dalvikvm( 5018): creating instr width table
D/AndroidRuntime( 5018): ---registering native functions ---
D/HomeLoaders( 3218): application intent received: android.intent.action.PACKAGE_CHANGED, replacing=false
D/HomeLoaders( 3218): --> package:com.android.wallpaper
D/HomeLoaders( 3218): --> sync package com.android.wallpaper D/VoiceDialerReceiver( 4902): onReceive Intent { act=android.intent.action.PACKAGE_CHANGED dat=package:com.android.wallpaper flg=0x10000000 cmp=com.android.voicedialer/.VoiceDialerReceiver (has extras) }
V/RecognizerEngine( 4902): deleteCachedGrammarFiles /data/data/com.android.voicedialer/files/ openentries.txt
D/AndroidRuntime( 5018): Shutting down VM
D/jdwp ( 5018): adbd disconnected
I/AndroidRuntime( 5018): NOTE: attach of thread 'Binder Thread #3' failed
I/class com.keramidas.TitaniumBackup.c.k( 4917):

Seems like titanium backup modifies the apk to be unusable in some way by the system.
 
Last edited:
Back
Top