[Script] Hollyname CM7 Build.prop Tweaks - Kindle Fire Android Development

Basically what this does is add a bunch of properties commonly added or adjusted in the build.prop that just makes everything better. I put this together to serve two purposes. The first is that although there are a few custom CM7 build.prop files floating around I never liked the idea of continuously using an old build.prop over what is now a multitude up updates and variants. A, because it shows incorrect or outdated information and B, maybe something new has been added or has been found to work better that will be missed by just swapping the file out. Before putting this together I found myself spending more time then I would have liked in notepad++ adding and adjusting lines in the build.prop after an upgrade or anytime after a system wipe. Second is that I think my Kindle runs pretty dam smooth in comparison to friends and family members who often ask if I can make their Kindle perform more like mine so not only does a script at boot save the time of editing all their build.prop files I would like to think these values and additions work well. Had originally planned on adding these to an init.d script I’m working on but can’t figure out a way that by including a line already present in the build.prop does not result in me needing to boot into recovery and swap out the script by mounting system. I’m sure ill figure it out but until then this method works just fine. Also trying to figure a way of making this script trick the market into thinking the device is a Galaxy Tab. Not there yet but pretty sure it can be done. Anyhow enough with my justification for the need of yet another set of build.prop tweaks for CM7.
Almost forgot, This is of curse at your own risk and I am not responsible for any damage done to anything you own.
Instructions
Download Hollyname Script and place on SD-Card
http://www.mediafire.com/?z964ni67vuy2nea
Install Script Manager from the Market
Open Script Manager and Select Hollyname Script
Select SU, Boot & Save
Reboot
One of the other nice things about using this method to apply these tweaks is that they are not permanently added to the build.prop and can be removed by either deleting the script from the SD Card or UN-selecting Boot in script manager.
If not sure everything was done correctly run “getprop” in either ADB or a Terminal and all current properties will be displayed. The list should include the properties below.
List of Tweaks Include,
debug.sf.hw 1
wifi.supplicant_scan_interval 180
dalvik.vm.heapsize 64m
persist.sys.ui.hw 1
ro.max.fling_velocity 12000
ro.min.fling_velocity 8000
ro.ril.disable.power.collapse 1
pm.sleep_mode 2
windowsmgr.max_events_per_sec 150
ro.media.enc.jpeg.quality 90
media.stagefright.enable-player true
media.stagefright.enable-meta true
media.stagefright.enable-scan true
media.stagefright.enable-http true
net.tcp.buffersize.default=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.wifi=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.umts=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.gprs=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.edge=4096,87380,256960,4096,16384,256960
ro.kernel.android.checkjni 0
ro.kernel.checkjni 0
debug.performance.tuning 1
video.accelerate.hw 1
dalvik.vm.dexopt-flags m=v,o=y
persist.adb.notify 0

Some irrelevant entries
Thank you. Unless your Kindle Fire has a camera and GSM radio you might rethink the following four items, as their inclusion does not inspire confidence:
ro.media.enc.jpeg.quality 90
net.tcp.buffersize.umts=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.gprs=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.edge=4096,87380,256960,4096,16384,256960
If you have such a device, can I have it?
Sent

chairshot215 said:
Had originally planned on adding these to an init.d script I’m working on but can’t figure out a way that by including a line already present in the build.prop does not result in me needing to boot into recovery and swap out the script by mounting system. I’m sure ill figure it out but until then this method works just fine.
Click to expand...
Click to collapse
Here's one way to do it in an init.d script:
busybox sed -i 's|windowsmgr.max_events_per_sec=.*|windowsmgr.max_events_per_sec=150|' /system/build.prop
busybox sed -i 's|wifi.supplicant_scan_interval = .*|wifi.supplicant_scan_interval = 300|' /system/build.prop
You might also find ease in making a .txt file with your edits ready to copy and paste into your build.prop file after a new flash. You might save yourself some hassle this way. Don't worry about doubling up on entries; the last instance of a value will override the previous instance. So, while your build.prop might have:
wifi.supplicant_scan_interval=60
something.use.situation.fun=7
wifi.supplicant_scan_interval=300
300 will win. Doesn't it always?
Sent from my mind using magic

manchucka said:
Thank you. Unless your Kindle Fire has a camera and GSM radio you might rethink the following four items, as their inclusion does not inspire confidence:
ro.media.enc.jpeg.quality 90
net.tcp.buffersize.umts=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.gprs=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.edge=4096,87380,256960,4096,16384,256960
If you have such a device, can I have it?
Sent
Click to expand...
Click to collapse
Sorry, thought "ro.media.enc.jpeg.quality 90" was the value for displaying a Jpeg and not actually taking the image. Never mind, checked a few sites and this line does pertain to displaying images and not taking them. The other 3 I usually use with my phone and always see them together when looking at other scripts so figured the worst including them all could do is that they would just not do anything. Should probably just remove them anyhow if for no other reason than to avoid sarcastic alpha smart person in the room comments like "If you have such a device, can I have it?” It's a good one though as far as those kind of comments go, gave me a laugh anyway. Still don't understand why their inclusion would be any cause for concern?
Thanks for this though, I think I see what I may have been doing wrong.
manchucka said:
Here's one way to do it in an init.d script:
busybox sed -i 's|windowsmgr.max_events_per_sec=.*|windowsmgr.max_events_per_sec=150|' /system/build.prop
Click to expand...
Click to collapse
You might also find ease in making a .txt file with your edits ready to copy and paste into your build.prop file after a new flash.[/QUOTE said:
This is what I had been doing previously but then also had a few other Tweaks I have been using in an init.d script and had originally just planned on adding these to that script. Either way I just figured I could learn something new and at the same time avoid the need of having to paste in the lines as after each new flash the script would still be on the sd-card and script manager would apply the values with out needing to do anything extra after flashing. At least I had thought it was a good idea.
Click to expand...
Click to collapse

Related

[Q] SU not working

I am just about to release my new barebones build with a lot of new features but one thing is killing me. I cannot get superuser to work anymore with the latest build and the latest kernel. Rogue tools won't overclock without SU working and that just totall kills the speed of my build =(. The build is based off scoot's release 5 and I am using the latest kernel with and without the module update SU is unaffected. Everything else works though.
What have you changed from the build i sent you that might effect it? Does it work for you with the original build? Things to check are the sysinit.rc, make sure it calls userinit.sh on startup, and also check your userinit.sh in the /bin directory and make sure the su fix is still present in the file Otherwise, try opening the super user app and downloading the latest su binary file, if it fails to install then you most likely have partition permission issues.
I did edit userinit to enable the odex script. I am gonna check that now.
Ok I am pretty sure that was it. how do I add this line to userinit to have it be proper then? /system/bin/odex.sh
aceoyame said:
Ok I am pretty sure that was it. how do I add this line to userinit to have it be proper then? /system/bin/odex.sh
Click to expand...
Click to collapse
You'd need to put it in sysinit.rc like this :
service odex /system/bin/odex.sh
So put that line right at the end then? Or is there a special format it has to go in. Sorry, I have just never had to edit this particular file before lol.
aceoyame said:
So put that line right at the end then? Or is there a special format it has to go in. Sorry, I have just never had to edit this particular file before lol.
Click to expand...
Click to collapse
At the end is fine, you will see some similar lines in there, you may want to add some options such as :
console
user root
oneshot
I don't know what the structure of the odex script is so i don't know which options you will need to get it to run properly but these are the most likely, just experiment and see
I've always put it at the end, after the su fix just as "/system/bin/odex.sh" and nothing else. What does service do? will it run it continuously or just with different permissions?
I would say its more likely that something's gone wrong while you edited userinit.sh, and now it can't be executed.
did you edit it in windows? you may have /n/r line endings now instead of /n
if you did it in linux it may be a permissions problem
fixed! I used the userinit from my old barebones. Something changed in the update. The two looked totally different.

[[Speed Improvements]] Brainstorming & Testing Thread!!

Hey guys,
Seems there's a lot of ways you can improve the speed of Android in general. Some seem to be snakeoil... others, work quite well and there's proof to back it up.
I'm only interested in discussing the latter .
A lot of people have helped me gather a better understanding of Android (hyc, stinebd to name a few) in addition to a lot of Google searching. I am going to compile a list of what I have done, I would like to hear what you guys have done! Most app killer apps / app control will already be addressed, so those tools need not apply... I'm looking for real, permanent fixes here without adding more apps!
I am also trying to have topics that are easy working up to advanced. Obviously the more advanced topics are going to be harder to do. You've been warned.
So here's the disclaimer.
****DISCLAIMER****
Speed is as always relative. That basically means I don't want arguments about which build is faster. I want to argue about how to make every build faster .
Also, these tips should apply to any build, any device... they are pretty generic tips, but are obviously specific to Android, with some idiosyncrasies that apply to our port that wouldn't apply to native Android devices. Some is common sense, others are real ways to tear into the system. Hope you enjoy it!
Topic 1
Difficulty Easy - Apps/Widgets​
I've noticed the number of widgets i have on my screens, or the number of apps that I have installed/are running in the background to greatly effect performance, in an obviously negative way.
Once I removed all the widgets (I only have the basic analog clock widget & the Google search widget on one desktop...) this seemed to improve general speed. One minor thing to check is if apps are set to auto/background sync. Only enable the ones you really want syncing, others just check manually.
On this same topic, replacing the launcher (the stock launcher in Android, Launcher2 is quite slow) can help immensely. I like ADW, but I've used LauncherPro in the past and it is good. Zeam also seems like a good launcher. I haven't used Go Launcher EX, I've heard good and bad things about it. Use what works best for you, try 'em all!
The last thing on this topic I would like to mention is animations. Settings -> Display -> Animation -> No animations can make the phone feel quite a bit snappier, obviously at the expense of the look/feel of the OS.
Topic 2​
Difficulty Easy - Controlling app 'net Access​
This leads me into the next topic, DroidWall. I've noticed that blocking apps from accessing the internet has been a very good thing - it's not so much a performance booster (although it probably does provide a little bump) it's mostly about battery life. Just be warned, if you block an app that is set to background sync, it will probably have very negative effects. Only disable an app's access to the internet with DroidWall after you've checked that app's background sync feature is disabled. I have a few apps allowed in DroidWall, and the rest are blocked. You can "whitelist" everything and check apps you want to block, or "blacklist" everything and check the apps you want to allow. It's a little annoying to remember to enable/disable DroidWall (I use the DroidWall widget to enable/disable it globally) but if you do, it is much better - you have complete control over how apps access the 'net on your device. It is available on the Market.
Topic 3​
Difficulty Moderate - SD cache/readahead tweaking​
The only reason I'm calling this one 'moderate' is the number of choices you have for settings for this... It's basically telling the SD card how much to hold on to or... read "ahead" if you will . This was turned way up in FRX07, (from 256kb to 2048kb or 2mb...) and I think this might be the source of a lot of the complaints of 'mini-resets' if you will where the boot animation is suddenly seen after a long system hang...
So some cards will work better with a larger setting - I've heard some with spankin new C6 cards that said 3072kb or 3mb was a good setting. Others have found a sweet spot at 256kb or 1024kb (1mb).
There are two ways of doing this - you can hack the init in the rootfs and adjust the setting manually, or be lazy like me and use SD Booster (from the Market). Adjusts the same settings, and they are applied immediately!
I would like to find a "sweet spot" - a good default if you will. Can folks test out 512kb and 1024kb, see if you have any more mini-resets within Android or any other slowness, etc... Obviously this isn't a cure-all for the slowness or the mini-resets, what we're looking to do is mitigate the effects. So let's focus on that, thanks!
Topic 4​
Difficulty Moderate - Overclocking​
Overclocking is obviously one relatively easy way to improve the speed of Android. In your startup.txt, add a line
Code:
acpuclock.oc_freq_khz=710400
for example to overclock to 710.4mhz. How did I find this value? I actually put in 714000, but if you look at dmesg near the beginning you'll see "ACPU running at ..." - that's what clock is the actual maximum. It goes in 19.2khz increments.
Feel free to experiment with how high your phone can go, just be warned that the higher you go the potential for failure goes up as well . Phone shouldn't blow up, but it might not work correctly or at all. Rebooting and scaling it back will fix it.
Here's the full *example* startup.txt:
Code:
set ramsize 0x10000000
set ramaddr 0x10000000
set mtype 2292
set KERNEL zImage
set initrd initrd.gz
set cmdline "lcd.density=240 msmvkeyb_toggle=off gsensor_axis=2,1,3 pm.sleep_mode=1 physkeyboard=rhod400 acpuclock.oc_freq_khz=710400"
boot
You can put the command anywhere in the cmdline section, just make sure it's between the quotes and at least one space between each command.
Topic 5​
Difficulty Advanced - How Android Manages Memory/apps​
Ok, I'm going to take two approaches to this. The first, is the full explanation on how Android manages memory.
Please feel free to read the post I originally read that inspired me to start looking at this stuff - How to configure Android's *internal* taskkiller. It was very helpful for me to grasp how Android manages applications. This is the reason why application killers are not a good thing...
If you want to do it manually, Starfox suggests:
Code:
echo "1536,3072,8192,10240,12288,20480" > /sys/module/lowmemorykiller/parameters/minfree
To try to do these commands, adb is very useful. Once you get adb shell working, then you just need to "su" (provides 'super user' privileges (root)) and put in the echo command above ^^.
I had another user (thanks icevapor) suggest this script -
[Script] V6 SuperCharger! HTK & BulletProof Launchers! The ONLY Android MEMORY FIXER!
I tried it myself, and it works very well. This thread is a little overwhelming, but the jist of it is this:
Install Script Manager (on the Market)
Run the V6 SuperCharger script. I use "Aggressive 1 Settings" (#2) and then I use the OOM Grouping Fixes & "Hard to Kill" launcher (#17)
Point Script Manager to run /data/99SuperCharger.sh to run as root & on boot. This will ensure the tweaks are reapplied after a reboot.
Topic 6​
Difficulty Advanced - Managing Apps that auto-start on boot​
This is one of the most annoying things in Android. When you have no apps installed, it seems very fast. Then you install apps, and you never seem to get that original speed back... Now you can!
This is kind of difficult to do, I am still getting the hang of it... but here goes. All credit goes to hyc, his original post.
The basic idea here is you run a logcat (adb logcat is easiest here, or you can use GetLogs to pull logcat...) Look in this log for "for broadcast" and find apps that start on boot. For example,
Code:
Line 41: I/ActivityManager( 1394): Start proc nextapp.systempanel for broadcast nextapp.systempanel/.monitorservice.BootReceiver: pid=1752 uid=10060 gids={3003, 1015}
Notice there are two sides of the "for broadcast". The name of the package (nextapp.systempanel) and the name of the service, "nextapp.systempanel/.monitorservice.BootReceive". I made the mistake of disabling the app (the left side). Do not do this, you want to disable the right side!
So in the shell,
Code:
pm disable nextapp.systempanel/.monitorservice.BootReceive
This will be persistent across boots, it will go with your data.img.
Obviously this was just one example of an app to disable. So long as you disable the right side (after the 'for broadcast') you shouldn't disable anything that will cause a serious problem. The apps should still work, but for example if you disable Google Voice you won't get messages until you open the app. So think about that... You disable Titanium Backup schedules.BootReceiver, the schedules for Titanium Backup (if you have any) won't run. Stuff like that. Disable calendar, you won't get calendar events... Disable clock no alarms. Get it? Good. I have been rebooting several times, and I keep checking what is set to start on boot. I'm not quite happy with it yet, but there's some things I'm leery of disabling. Just be wary, if you do disable something and don't like it - just pm enable <whatever you disabled>.
Now experiment away! The one caveat is if you do break something with pm disable (and it's serious) you might get a failure to boot. It really depends on how bad you mess up. If you make a copy of your data.img before you start making these changes, you can revert to that data.img and start back there.
Alright guys. Going to use this thread as a way to brainstorm about ways to improve the speed. Read up what I've posted, let me know if I did anything wrong... Also let me know what you guys do to improve speed!
Don't care about what build you're running, this thread isn't about what build is fastest - this is a how do I make every build faster thread.
I've noticed Starfox's test kernel with that turbo mode enabled actually creates quite a boon. It's RHOD-only, so I didn't include it in the first post...
arrrghhh said:
Topic 4​
Difficulty Advanced - How Android Manages Memory/apps​.....
Right now I'm running (Thanks Starfox):
Code:
echo "1536,3072,8192,10240,12288,20480" > /sys/module/lowmemorykiller/parameters/minfree
.....
One word about durabilty:
If you change the settings like this, they are NOT PERMANENT.
Click to expand...
Click to collapse
I noticed that these settings are written in the /init.cfg/init.froyo.rc file. If I make the changes there, will they be permanent? Is this still the file that loads with FRX07? I am still playing with the settings so I have not tried to make anything permanent yet. I was trying to minimize the number of mini-reboots after an install. The new ext4 seems to help a lot, but I was still playing with this also.
vinceweis said:
I noticed that these settings are written in the /init.cfg/init.froyo.rc file. If I make the changes there, will they be permanent? Is this still the file that loads with FRX07? I am still playing with the settings so I have not tried to make anything permanent yet. I was trying to minimize the number of mini-reboots after an install. The new ext4 seems to help a lot, but I was still playing with this also.
Click to expand...
Click to collapse
Yea, that will definitely make them permanent.
I also thought using the user.conf file would, but someone PM'd me and said that didn't work...
I also was shown that there might be a much easier and more thorough way of doing that step... Seriously considering redoing that whole topic because of this:
[Script] V6 SuperCharger! HTK & BulletProof Launchers! The ONLY Android MEMORY FIXER!
I still need to verify if it works on my phone, but I don't see why it wouldn't...
Bah, it seemed to work but isn't persistent on a reboot... I'll try to figure out why. I see some issues with stock ROM's, so perhaps the issue is similar...
Edit - OK, using Script Manager I think I figured it out... I will update the first post with directions on how to use that "SuperCharger" script in lieu of the manual method.
arrrghhh said:
Yea, that will definitely make them permanent.
I also thought using the user.conf file would, but someone PM'd me and said that didn't work...
I also was shown that there might be a much easier and more thorough way of doing that step... Seriously considering redoing that whole topic because of this:
[Script] V6 SuperCharger! HTK & BulletProof Launchers! The ONLY Android MEMORY FIXER!
I still need to verify if it works on my phone, but I don't see why it wouldn't...
Bah, it seemed to work but isn't persistent on a reboot... I'll try to figure out why. I see some issues with stock ROM's, so perhaps the issue is similar...
Edit - OK, using Script Manager I think I figured it out... I will update the first post with directions on how to use that "SuperCharger" script in lieu of the manual method.
Click to expand...
Click to collapse
I went ahead and began using this script. Not sure if the phone is any speedier yet, as I just got the 99Charger script to run at boot using script manager. Will report back my findings. Im using the Aggressive 1 settings with launcher set to bulletproof.
ACoolGuy said:
I went ahead and began using this script. Not sure if the phone is any speedier yet, as I just got the 99Charger script to run at boot using script manager. Will report back my findings. Im using the Aggressive 1 settings with launcher set to bulletproof.
Click to expand...
Click to collapse
Yup, seems to reapply the settings correctly on a reboot. The only problem with Script Manager doing it is obviously the settings don't get applied until well into the boot process - well after the UI has come up.
Not the end of the world, at least it does get reapplied correctly now.
One last thing - in the article it seemed to indicate the 'bulletproof' method is no longer advisable, and the 'hard-to-kill' method should be utilized.
I'm going to rewrite the first post now.
arrrghhh said:
Yup, seems to reapply the settings correctly on a reboot. The only problem with Script Manager doing it is obviously the settings don't get applied until well into the boot process - well after the UI has come up.
Not the end of the world, at least it does get reapplied correctly now.
One last thing - in the article it seemed to indicate the 'bulletproof' method is no longer advisable, and the 'hard-to-kill' method should be utilized.
I'm going to rewrite the first post now.
Click to expand...
Click to collapse
I went ahead and set the launcher to hard to kill. Also I have manually editted /data/99Chargerminfree with your minfree values and it now boots with your minfree values, which im happier with. ill have to run it thru the paces to see if memory is managed as well as he claims.
autokiller memory
I've been using this app, AutoKiller Memory, from the marketplace and it seems to be working fine. You can put in the values you want for the 6 fields and in settings enable "apply settings on boot". I've ran
Code:
# cat /sys/module/lowmemorykiller/parameters/minfree
to double check after my reboots and without touching the app these changes took affect =). Of course like you said for script, it won't happen right at the start of the boot process.
nasapunk88 said:
I've been using this app, AutoKiller Memory, from the marketplace and it seems to be working fine. You can put in the values you want for the 6 fields and in settings enable "apply settings on boot". I've ran
Code:
# cat /sys/module/lowmemorykiller/parameters/minfree
to double check after my reboots and without touching the app these changes took affect =). Of course like you said for script, it won't happen right at the start of the boot process.
Click to expand...
Click to collapse
That app seems good. It just adjusts the underlying values for Android's memory management, which is exactly what we want. Kudos.
The reason I didn't want an app was a) I don't want more overhead and b) I wanted to have control over it. I wanted to be damned sure the values that were changing were what I wanted to change, and not something else.
arrrghhh said:
Difficulty Advanced - How Android Manages Memory/apps[/center]
Ok, I'm going to take two approaches to this. The first, is the full explanation on how Android manages memory.
Please feel free to read the post I originally read that inspired me to start looking at this stuff - How to configure Android's *internal* taskkiller. It was very helpful for me to grasp how Android manages applications. This is the reason why application killers are not a good thing...
If you want to do it manually, Starfox suggests:
Code:
echo "1536,3072,8192,10240,12288,20480" > /sys/module/lowmemorykiller/parameters/minfree
To try to do these commands, adb is very useful. Once you get adb shell working, then you just need to "su" (provides 'super user' privileges (root)) and put in the echo command above ^^.
I had another user (thanks icevapor) suggest this script -
[Script] V6 SuperCharger! HTK & BulletProof Launchers! The ONLY Android MEMORY FIXER!
I tried it myself, and it works very well. This thread is a little overwhelming, but the jist of it is this:
Install Script Manager (on the Market)
Run the V6 SuperCharger script. I use "Aggressive 1 Settings" (#2) and then I use the OOM Grouping Fixes & "Hard to Kill" launcher (#17)
Point Script Manager to run /data/99SuperCharger.sh to run as root & on boot. This will ensure the tweaks are reapplied after a reboot.
Click to expand...
Click to collapse
Seems to work fine, so far.
Edit: Have to use "Aggressive Setting 2", otherwise Xenonia 3 won't start.
arrrghhh said:
[Script] V6 SuperCharger! HTK & BulletProof Launchers! The ONLY Android MEMORY FIXER!
Click to expand...
Click to collapse
No launcher redraws? Assuming that means what it sounds like, I friggin hate those. That's a huge part of my android wait time. Can't wait to try this, thanks.
Found this script:
Ram Optimizer
Changed my froyo.user.conf to those settings (except lowlevelmemorykiller, using the supercharger script).
großa said:
Found this script:
Ram Optimizer
Changed my froyo.user.conf to those settings (except lowlevelmemorykiller, using the supercharger script).
Click to expand...
Click to collapse
Reading thru that, it seems redundant to that wacky SuperCharger script. OOM - already set, virtual memory - already set, and minfree - already set...
Honestly, that SuperCharger script does anything you could want in relation to memory/RAM. It's a little odd the way its laid out, and there's some qualms I have with how that guy arranged his post... but the script is all-encompassing. No need for others... they will literally bash heads with eachother... In the thread you linked to, it even mentions that if you've done other tweaks like this with other scripts, you should delete those scripts from init.d. So I would recommend the same, if you're going to use different scripts on boot, remove any other entries you have from the SuperCharger script. If you followed my directions, I use the startup script in /data/99SuperCharger.sh.
arrrghhh said:
Reading thru that, it seems redundant to that wacky SuperCharger script. OOM - already set, virtual memory - already set, and minfree - already set...
Honestly, that SuperCharger script does anything you could want in relation to memory/RAM. It's a little odd the way its laid out, and there's some qualms I have with how that guy arranged his post... but the script is all-encompassing. No need for others... they will literally bash heads with eachother... In the thread you linked to, it even mentions that if you've done other tweaks like this with other scripts, you should delete those scripts from init.d. So I would recommend the same, if you're going to use different scripts on boot, remove any other entries you have from the SuperCharger script. If you followed my directions, I use the startup script in /data/99SuperCharger.sh.
Click to expand...
Click to collapse
Yes I'm using the 99supercharger.sh on boot. I missed that supercharger also changes OOM and VM (thanks for the info), so I thought it can't hurt to change the froyo.user.conf directly. It should be logic, that 2 scripts, which do almost the same, will conflict.
BTW, did you try the 3G supercharger or the kickass kernel tweak?
I haven't had any launcher redraws since installing supercharger EXCEPT for keyboard induced orientation changes, which is a nice improvement for me. I'd like to get rid of the orientation change redraws too, since I gain nothing from the launcher itself going landscape anyway.
It did seem snappier, even not taking redraws into consideration. A link in the v6 thread claims the performance increase comes from the free ram being used to cache the filesystem. Not too clear on what "filesytem" means in this context (surely not the disk level filesystem, ext/ntfs/fat, I figure it must be linux terminology), still reading up on it, but if anyone felt like expounding a bit, I'd be grateful.
On this same topic, replacing the launcher (the stock launcher in Android, Launcher2 is quite slow) can help immensely. I like ADW, but I've used LauncherPro in the past and it is good. Zeam also seems like a good launcher. I haven't used Go Launcher EX, I've heard good and bad things about it. Use what works best for you, try 'em all!
Click to expand...
Click to collapse
I seem to recall from searches yesterday that there are a couple of 3rd party launchers that will let you lock in portrait orientation for the launcher only. I'll probably try Zeam later, don't see an option to lock against keyboard slide yet, but it's worth a try. Maybe if it switches back and forth faster, I won't need the lock.
My searches for a plaintext, no icon, no wallpaper launcher have come up empty so far. Zeam looks to have the smallest footprint. I've seen plaintext theme screenshots that I think was from LP+beautiful widgets, but what good is that if your footprint is still huge?
großa said:
BTW, did you try the 3G supercharger or the kickass kernel tweak?
Click to expand...
Click to collapse
I actually did not try those yet. It seemed like he had just started experimenting with that, and I was just trying to get the memory stuff hashed out.
Kinda wondering how it'll react with our build/kernels. But I guess it's worth a shot, worst case seems like a bootloop - might want to try it on an isolated setup before you move it to your main build . Let us know how it goes if you do try it!
fortunz said:
I haven't had any launcher redraws since installing supercharger EXCEPT for keyboard induced orientation changes, which is a nice improvement for me. I'd like to get rid of the orientation change redraws too, since I gain nothing from the launcher itself going landscape anyway.
It did seem snappier, even not taking redraws into consideration. A link in the v6 thread claims the performance increase comes from the free ram being used to cache the filesystem. Not too clear on what "filesytem" means in this context (surely not the disk level filesystem, ext/ntfs/fat, I figure it must be linux terminology), still reading up on it, but if anyone felt like expounding a bit, I'd be grateful.
Click to expand...
Click to collapse
Well, even tho we aren't using traditional file systems as you normally would, most of our files are in ext2. The data.img, the system.ext2 . I believe the rootfs.img is as well. They're just files that have entire file system structures and files underneath them - much like an ISO disc image if you're familiar with that concept.
fortunz said:
I seem to recall from searches yesterday that there are a couple of 3rd party launchers that will let you lock in portrait orientation for the launcher only. I'll probably try Zeam later, don't see an option to lock against keyboard slide yet, but it's worth a try. Maybe if it switches back and forth faster, I won't need the lock.
My searches for a plaintext, no icon, no wallpaper launcher have come up empty so far. Zeam looks to have the smallest footprint. I've seen plaintext theme screenshots that I think was from LP+beautiful widgets, but what good is that if your footprint is still huge?
Click to expand...
Click to collapse
I have heard good things about Zeam. I like ADW, but I haven't run much else than ADW and LauncherPro. Honestly only gave Zeam a whirl a few times, but it does seem snappy.
arrrghhh said:
I actually did not try those yet. It seemed like he had just started experimenting with that, and I was just trying to get the memory stuff hashed out.
Kinda wondering how it'll react with our build/kernels. But I guess it's worth a shot, worst case seems like a bootloop - might want to try it on an isolated setup before you move it to your main build . Let us know how it goes if you do try it!
Click to expand...
Click to collapse
Making a backup at the moment, gonna try it
Topic 5: doesn't show everything in autostart?!
Hmm, doesn't work properly:
Command:
'/system/etc/init.d/98kickasskernel'
-------------
Out:
exec sh '/system/etc/init.d/98kickasskernel'
/ # exec sh '/system/etc/init.d/98kickasskernel'
/ # exec sh '/system/etc/init.d/98kickasskernel'
sysctl: /etc/sysctl.conf: No such file or directory
mount: mounting none on /sys/kernel/debug failed: Device or resource busy
/system/etc/init.d/98kickasskernel: line 8: can't create /sys/kernel/debug/sched_features: Permission denied
vm.oom_kill_allocating_task = 0
vm.panic_on_oom = 0
vm.dirty_background_ratio = 60
vm.dirty_ratio = 95
vm.min_free_kbytes = 8192
vm.vfs_cache_pressure = 20
vm.overcommit_memory = 1
vm.min_free_order_shift = 4
kernel.panic = 0
kernel.panic_on_oops = 1
kernel.msgmni = 2048
kernel.msgmax = 64000
kernel.shmmax = 268435456
kernel.sem = 500 512000 64 2048
sysctl: error: 'kernel.sched_features' is an unknown key
kernel.hung_task_timeout_secs = 0
sysctl: error: 'kernel.sched_latency_ns' is an unknown key
sysctl: error: 'kernel.sched_min_granularity_ns' is an unknown key
sysctl: error: 'kernel.sched_wakeup_granularity_ns' is an unknown key
sysctl: error: 'kernel.sched_compat_yield' is an unknown key
sysctl: error: 'kernel.sched_shares_ratelimit' is an unknown key
sysctl: error: 'kernel.sched_child_runs_first' is an unknown key
kernel.threads-max = 5000
net.core.wmem_max = 524288
net.core.rmem_max = 524288
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_rmem = 6144 87380 524288
net.ipv4.tcp_wmem = 6144 87380 524288
vm.dirty_writeback_centisecs = 2000
vm.dirty_expire_centisecs = 1000
mount: mounting /dev/block/mmcblk0p1 on /card0 failed: No such file or directory
mount: can't find /proc/cmdline in /proc/mounts
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop0/queue/rotational: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop0/queue/iosched/low_latency: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop0/queue/iosched/back_seek_penalty: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop0/queue/iosched/back_seek_max: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop0/queue/iosched/slice_idle: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop0/queue/nr_requests: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop0/queue/iosched/fifo_batch: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop0/queue/iosched/quantum: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop1/queue/rotational: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop1/queue/iosched/low_latency: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop1/queue/iosched/back_seek_penalty: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop1/queue/iosched/back_seek_max: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop1/queue/iosched/slice_idle: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop1/queue/nr_requests: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop1/queue/iosched/fifo_batch: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop1/queue/iosched/quantum: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop2/queue/rotational: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop2/queue/iosched/low_latency: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop2/queue/iosched/back_seek_penalty: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop2/queue/iosched/back_seek_max: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop2/queue/iosched/slice_idle: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop2/queue/nr_requests: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop2/queue/iosched/fifo_batch: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop2/queue/iosched/quantum: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop3/queue/rotational: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop3/queue/iosched/low_latency: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop3/queue/iosched/back_seek_penalty: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop3/queue/iosched/back_seek_max: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop3/queue/iosched/slice_idle: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop3/queue/nr_requests: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop3/queue/iosched/fifo_batch: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop3/queue/iosched/quantum: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop4/queue/rotational: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop4/queue/iosched/low_latency: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop4/queue/iosched/back_seek_penalty: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop4/queue/iosched/back_seek_max: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop4/queue/iosched/slice_idle: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop4/queue/nr_requests: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop4/queue/iosched/fifo_batch: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop4/queue/iosched/quantum: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop5/queue/rotational: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop5/queue/iosched/low_latency: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop5/queue/iosched/back_seek_penalty: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop5/queue/iosched/back_seek_max: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop5/queue/iosched/slice_idle: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop5/queue/nr_requests: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop5/queue/iosched/fifo_batch: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop5/queue/iosched/quantum: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop6/queue/rotational: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop6/queue/iosched/low_latency: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop6/queue/iosched/back_seek_penalty: nonexistent directory
Yikes, Zeam is snappy, right up until an orientation change redraw, then it's even slower than the default launcher. ADW might be better for me even at twice the footprint because I'm pretty sure I remember that one has an option to lock in portrait. I was at peace with redraws until I read this and managed to cut them down dramatically, and now that I have a taste of freedom, my contentment is shot and I need them eliminated entirely
arrrghhh said:
Well, even tho we aren't using traditional file systems as you normally would, most of our files are in ext2. The data.img, the system.ext2 . I believe the rootfs.img is as well. They're just files that have entire file system structures and files underneath them - much like an ISO disc image if you're familiar with that concept.
Click to expand...
Click to collapse
First, thanks for expounding. I am familiar with disk images/isos. Are you saying that underlying disk structure is what is being cached in "free" ram by linux? If so, I'm even more confused than before and maybe this is just beyond my ability to grasp. I assumed when he said the filesystem was being cached, it was a reference to actual files that happened to be called a filesystem in linuxese. Like registry type stuff or some such.
fortunz said:
First, thanks for expounding. I am familiar with disk images/isos. Are you saying that underlying disk structure is what is being cached in "free" ram by linux? If so, I'm even more confused than before and maybe this is just beyond my ability to grasp. I assumed when he said the filesystem was being cached, it was a reference to actual files that happened to be called a filesystem in linuxese. Like registry type stuff or some such.
Click to expand...
Click to collapse
Hrm, maybe I didn't explain that right.
Cache is basically a buffer to store things in. So Android uses cache to store frequently opened programs, etc. It keeps them in memory (RAM) as long as possible before it's necessary to free up that RAM.
So nothing is actually being cached on the file system, all is being cached in RAM. The hurdle here is the stuff that is being cached in RAM normally has to be accessed from the file system - but if it's already in RAM, it's much faster to access it that way than going thru the file system to find what it needs.
It's not the entire file system, just apps or any outside things they might be accessing. To keep it simple, we'll say just apps .
I hope that makes sense...

[HOW TO][MOD] V6 SuperCharger Script

Hi all,
I own no credits to this mod/script, it's all put together by zeppelinrox, Thanks go out to him for this! Orginal thread can be found here.
http://forum.xda-developers.com/showthread.php?t=991276
This is the first post of this kind I have ever made, so it might not be that good, or any help at all, but for those who want to try this script for the first time, I shall try my very best to explain how to do so.
I had been running ROMS for my Nexus with the V6 SuperCharger built in, and decided to see if it'll run well on our humble little Tabs. And indeed it does, it could be a placebo of course, but I seem to notice a good difference.
First, there are a few requirements in order to use this script :-
You NEED to be Rooted, in order to do this (if you aren't already) you could try the excellent Quick and Easy Root Script by the genius Crossix http://forum.xda-developers.com/showthread.php?t=1472521
Download and Install Script Manager from the Market
https://market.android.com/details?id=os.tools.scriptmanager
You also need to have BusyBox installed for the script to be run, I suggest installing the Script attached to the above V6 SuperCharger thread (even if you already have BusyBox installed to avoid errors). Simply scroll to the bottom of the thread and download the file named "busybox_v1.19.3_installer_script_wraithdu.zip"
To install this version of BusyBox navigate to where you saved the ZIP file, if on the Tab it should have downloaded to "/mnt/sdcard/Download", extract it using your file manager, I use ES File Explorer. Then open Script Manager and navigate to the extracted folder, find the script that should be called "busybox_v1.19.3_installer_wraithdu.sh", open this and select the "su" icon, make sure it is selected as a script and not executable.
To Run the Script:-
Scroll to the bottom of the SuperCharger thread and Download the file named " V6_SuperCharger_for_Android-update8.sh.txt" Navigate to where this file is downloaded, if on the Tab it should have downloaded to "/mnt/sdcard/Download", rename it using your favourite file manager, usually via a long-press to "V6_SuperCharger_for_Android-update8.sh"
Then open Script Manager and navigate to the script, open it using script manager, again taking care to run it as "su" as a script not an executable. The script should Run and prompt you for an option numbered 1-17. I chose Option 2, which is Aggressive Level 2 and noticed a good improvement, you can of course opt for the balanced options of 3 or 4. To input a number touch the screen and the on screen keyboard should pop up, hit a number and enter it.
The Script Should run and then prompt you for another option, don't choose another one just yet.
If you are running the excellent build.prop by Crossix, Icewyng et al, it is recommended to disable the device keeping Launcher in memory for the script to run properly. To do this, open Root Explorer, navigate to the build.prop, in "/system", and open it in the text editor. Scroll to the part of the prop file that begins "store launcher in memory" and change the below string to "ro.HOME_APP_ADJ=0"
In order for this to be a persistent change to how RAM is managed on our Tabs, a script has to be set up to be run at boot. To do this, in Script Manager, navigate to "/data" and open the script named "99SuperCharger.sh", and check the boxes of "su" along with "boot" to run it at boot.
After you have followed these steps reboot your Tab and you *should* see a snappier Tab
Please be aware that this is the very first HOW TO I have ever written, and it will probably be inaccurate and crap. So, please, feel free to correct my errors and I will try to help running the script.
Yours,
Toyface
Awesome scripts. Im going to give it a try here in a bit and see if there is a difference in performance.
Could someone confirm if this really works?
I just did this and have notices an improvement but do follow instructions carefully
Sent from my A500 using xda premium
I can't download the update 8 sh.txt file it just opens it in my browser
I used taptalk to download it it worked great and is still working its magic
Sent from my A500 using xda premium
Super huge improvement. Thank you!
rando152 said:
I can't download the update 8 sh.txt file it just opens it in my browser
Click to expand...
Click to collapse
Which browser are you using? If chrome on the PC, try a right click and save as a txt file and rename it as a file ending .sh
Sent from my A500
Thanks for all the cool info. Using info I found in sin threads Skype seems to stay running for hours now instead of just 15 Minutes.
Sent from my modified A100 using Tapatalk and SlideIT keyboard.
so far so good.
Just had time to get this installed. So far it seems to be a bit snappier. Wish i had thought to benchmark first. Grrrr....
I think this should be in the dev section, I might ask to have it promoted... Good Work!
Frankly the whole you cant modify his script deal is a HUGE turn off. I understand him wanting credit for his hard work, BUT wth. I'll stick to safer things.
EDIT: Forget what I said I completely miss understood what he says in his post. He says
"Personal Use: You may tweak the V6 installation script (leaving credits intact) to your own personal liking as long as it is NOT redistributed in any way."
His autostart script script looks very handy. I was considering trying Gscript already here is a new reason hehe.
NoSudo said:
Frankly the whole you cant modify his script deal is a HUGE turn off. I understand him wanting credit for his hard work, BUT wth. I'll stick to safer things.
EDIT: Forget what I said I completely miss understood what he says in his post. He says
"Personal Use: You may tweak the V6 installation script (leaving credits intact) to your own personal liking as long as it is NOT redistributed in any way."
His autostart script script looks very handy. I was considering trying Gscript already here is a new reason hehe.
Click to expand...
Click to collapse
I can see why he doesn't want redistributables floating around, even with the open source (something I feel very strongly about) nature of the forum.
All I wanted to do was spread the word, maybe help along the way, if I've done this then I'm happy
Sent from my Nexus S using xda premium
NoSudo said:
His autostart script script looks very handy. I was considering trying Gscript already here is a new reason hehe.
Click to expand...
Click to collapse
You can also auto start scripts without having to use script manager or any other scripting program by calling them from within install-recovery.sh (see my sdswap mod).
For example if you had a script /data/app/supercharger.sh
in install_recovery.sh you'd add a line sh /data/app/supercharger.sh
crossix said:
You can also auto start scripts without having to use script manager or any other scripting program by calling them from within install-recovery.sh (see my sdswap mod).
For example if you had a script /data/app/supercharger.sh
in install_recovery.sh you'd add a line sh /data/app/supercharger.sh
Click to expand...
Click to collapse
Cool. I have re-written another version of my hulu script in .sh and set it up to be able to run in a normal verbose mode, or to accept "silent" as a command line argument to redirect output to a lhulu.log file instead to better allow for the option of running at startup like a cron entry or what ever our allowed methods are on android.(like the one you just referenced, thanks) I'm planning on playing with it a little to figure out the best and easiest method. Then repost the updated version that can be a semi permanent fix.
NoSudo said:
Cool. I have re-written another version of my hulu script in .sh and set it up to be able to run in a normal verbose mode, or to accept "silent" as a command line argument to redirect output to a lhulu.log file instead to better allow for the option of running at startup like a cron entry or what ever our allowed methods are on android.(like the one you just referenced, thanks) I'm planning on playing with it a little to figure out the best and easiest method. Then repost the updated version that can be a semi permanent fix.
Click to expand...
Click to collapse
install-recovery.sh won't work for the hulu lib, sometime after that script is loaded all the apks libs get extracted for whatever reason. Unless you put a wait in there for the prop sys.boot_complete or something like that. Might also need to use busybox run-parts for a seperate init.d script, not sure if the wait would actually stop the rest of the boot process.
It should be fine, install_recovery is called really late in the boot process you're right about putting the waits in, if you look at my swapscript you'll see the amount of time I used to get it to work (and it does not pause the other processes).
Sent from my MB860 using XDA App
crossix said:
It should be fine, install_recovery is called really late in the boot process you're right about putting the waits in, if you look at my swapscript you'll see the amount of time I used to get it to work (and it does not pause the other processes).
Sent from my MB860 using XDA App
Click to expand...
Click to collapse
It's not as late as I previously thought myself. dmesg won't work at that point and getting a logcat from there you'll see it's the start of the system log just when vold starts up. Which is why you need a few sleeps in your script. Using it was my second attempt at 2nd-init, which wasn't possible until after my first bootloop, the boot animation starts later but also before the libs are replaced.
For hulu I've just been running a gscript after a reboot because of this, at least until I find a different solution.
Anyway install-recovery is the perfect spot for any kind of kernel tweaks and also SuperCharger.
@toyface sorry for being off topic
Sorry a little confused with the last part how do I navigate to /data in script manager?
Edit.. never mind. ma bad noob moment, couldn't for the life of me figure out how to get out of the mnt part of the directory.
Sent from my A100 using Tapatalk

[Tweak][V2.4] Extend your Battery Life - init.d, build.prop and everything

(To any visitors to this thread,
Please Rate this thread based on your reading and tweaks that I provided. If the rate is too low, that means I'm doing a bad job in here! If the rate goes down below 4 stars, I'll stop providing these tweaks! So, please excuse me. Please don't rate this thread with the only reason that I do not provide the tweaks for your rom, which you are using! I'm using my own time for this just like lots of other users. Only the thing that makes me more happy and get focused on this would be your rates and 'thanks' on this thread)
** All the information in here is for informational purpose only. I'm getting lots of new requests and great feedbacks but I can't handle everything. Please don't ask me to do anything. If anything is causing a boot loop or force closing in here, I'll drop those contents. But be sure that any other rom users beside of rooted Stock ICS, don't try this and don't ask me to do anything.
Please don't post your battery life in here if it's not from the Stock ICS. This is not a place to show-up or for any competition. This is a place to show-up the battery life before and after the tweaks.
Currently supporting ROMS - Any sfhub's rom, any Calk's Rom, any Agat's rom, VeNuM_ICE_Rom_RL5.0, MIJJz BLEND ICS, AnaKonda Rom ICS, etc....
Now flashable zip files are available at http://forum.xda-developers.com/showthread.php?p=26201865#post26201865
*Note* Please read the second post also for quick install guide, Q/A, progress report, issues and change logs.
Maybe some of you already know that I was working on the tweaks to extend the battery life. In here, all the information is based on my experimental test and its result. Personally I spent lots of time for this stuff and to get the longest battery life. So, if you believe this information is not helpful, please don't blame me and don't even think about trying these tweaks.
But if you want to give it a shot, I would be more than happy to help you to get the better result.
Rule of thumb: Do it with your own risk and don't ask me to buy you a beer because you're doing it. But, if you like this info and/or you see any longer battery life of your phone, please don't hesitate saying 'thank you' and/or consider to buy me a beer.
I'm ok with not leaving any comments and just taking this tweak and recommendation but don't use this info in any other places with 'copy and paste' style.
OK. Now let's get started.
1. Who needs this tweak?
2. What do you need?
3. How to run init.d scripts?
4. what's in init.d scripts?
5. build.prop tweaks
6. Additional tweaks on your phone
7. Startups
8. Closing comments
1. Who needs this tweak?
If you are a heavy user or gamer, this place wouldn't be a right place for you. In here, I'm only focusing on extending battery life and keep it longer without recharging it under our daily usage.
Because it's really hard to save the battery during the screen on (awake status), I'm only focused on the battery savings during the screen is off or sleep (lazy) status. I've seen lots of battery drains during the stand-by mode and I tested lots of things to save the battery during this time frame.
Actually this was my first project working on this phone because I was never able to use my phone more than one day without recharging it before I started this project. In my location, almost everything is not good - so weak radio signal, 3G/4G is not enough to get the fast data speed.
Somehow, wifi is the biggest consumer of battery drain.
Guess what? I had to find out some way to extend my battery life.
I believe the information in here would be very helpful for the person who
keeps phone offline most of time
lives in bad signal area
reasonably think battery life is more important than performance (the performance with this tweak is still good but not best)
do not believe in battery saver apps
wants to experience the best battery life!
2. What do you need?
Most importantly your phone
init.d support (startup scripts during the boot)
Smanager if your kernel does not support init.d or install-recovery.sh
file editor like root explorer
root access, busybox (rooted phone)
init.d scripts and build.prop files (download)
3. How to run init.d script?
I've already posted one thread in here - http://forum.xda-developers.com/showthread.php?t=1610741 (thanks for the people who already left great feedbacks)
From there, you will find out how you can get the init.d script support during the boot and how to test whether it's working or not. If you don't have the Kernel that is not supporting init.d script or install-recovery.sh during the boot, you can also use the SManager tool to run the scripts in here during the boot.
4. what's in init.d scripts?
4.1 cpufreq_governor
21cpufreq_governor script sets the governor that contorls the CPU's thresholds and sampling_rates. I choosed ondemand governor and some values are changed from Calk's original script (big thanks to Calkulin and he provided some init.d scripts on his FD02 tweaked rom).
4.2 cpufreq_screenstate_scaling
31cpufreq_screenstate_scaling script defines the governor values and decides the actions based on the phone's state - conservative, ondeman, lazy, awake, sleep modes. I've changed lots of values from Calk's original script to save more battery power thru this script. As indicated in Calk's original thread for FD02, this script would not run if you have already installed some CPU control apps something like OC Widget, Quick Clock, SETCPU, and Android OC.
For both cpufreq_governor and cpufreq_screenstate_scaling scripts, I had to stay with maximum 1GHz CPU speed and it couldn't go down below 1GHZ because if it goes not below 1GHz, some of the apps could be force closed, frozen, or even you can see the random reboot. Especially, stock camera app and some other camera apps had issues running under 1GHz CPU speed (facebook camera, FX Camera Zoom). If you don't care about the camera apps and want to save more battery, then we can set up maximum CPU speed to 800 MHz and I had no issues with that except the camera apps. With 800 MHz setting, I saw more battery saving and battery life, but I'm not posting that script in here.
4.3 tweaks_kobridge
41tweaks_kobridge script has almost everything in it to improve the network speed, sdcard tweaks, other battery saving tweaks, VM management, Kernel, wifi tweaks, etc. For some of the values in here, there are some overlaps with build.prop tweaks. So, if you do not apply the tweaks to the build.prop file, many tweaks would still work.
4.4 zipalign
zipalign is an archive alignment tool introduced first time with 1.6 Android SDK (software development kit). It optimizes the way an Android application package (APK) is packaged. Doing so enables the Android operating system to interact with the application more efficiently, and hence has the potential to make the application and overall the whole system much faster. Execution time is minimized for zipaligned applications, resulting is lesser amount of RAM consumption when running the APK.
If less number of applications with an unaligned home application, you’d see slower application launch times. This is the best case scenario. For a worst case scenario, having a number of unaligned applications will result in the system repeatedly starting and killing processes, struggling with lags and huge battery drain.
4.5 Wifi Sleep Wait timer
In my original version of this tweak, it was required to manually insert the table row to use this tweak. But it's fixed and now you can use this tweak without manually handling the database.
What this tweak does is, it controls the time until wifi sleeps after the screen turned off. By default, it's 15 minutes. So, even you turned off the screen, by default, phone will wait for 15 minutes and then turn off the wifi. By using this tweak, you will have the control over wifi idle time until wifi sleeps.
5. build.prop tweaks
build.prop file is created while you flash the rom and /system folder will be totally replaced by your new rom. So, don't expect your tweak would be there forever even after you flashed a new rom (Every Rom format the /system partition before it's installed). If you have your own customized tweaks, then make backup those tweaks before you apply the new rom. After flashing new rom, those tweaks won't be there.
The file list needs to be backed up -
/system/etc/init.d folder and it's contents
/system/build.prop
/system/etc/install-recovery.sh (if it's there)
/system/etc/gps.conf (if you have GPS tweak)
Basically build.prop file defines lots of system values related to phone settings and those values are loaded to phone during the boot.
Because build.prop is created by rom, it holds some current rom's build related information. So, if you want to keep this file up to dated, whenever you flash the new rom, take the new build.prop file and compare it with this tweaked file.
Update the current rom's build.prop file based on your comparison -
1. don't update/replace any ro.build.xxxx and ro.product.xxx items
2. for any all other items, replace the lines with the items in tweaked file.
By doing above steps, I believe you've started already getting lots of battery savings. But there're some more critical things that could affect your phone's battery life. The below section is not directly related to init.d and build.prop tweaks but it's important as much as tweaks!
6. Additional tweaks on your phone
I've worked on this part so long time since I've started using ICS ROM. I also tried almost every battery saver apps but didn't get any better result using my own method because sometimes there are lots of overheads using it (I'm trying to avoid describing any individual app's pros and cons in here and just provide you the better way to configure your phone).
Currently I'm on FD26 rooted stock rom/modem/kernel. So, all the information in here is based on this rom but it's not limited to any specific phone or build. You could probably use it in anywhere.
1. Wifi
Some of you understand that wifi is faster than 3G and use less battery than 3G. You also say that 4G is the biggest monster consuming lots of battery. But that would be true and false.
Sometimes, wifi uses lots of battery to get the faster speed and keep the connection.
My suggestion is turning off wifi connection when you are in the area where wifi is not available and keep the 3G turned on. But if you are in the area where the wifi is available and connected, then you don't need to turn off the wifi.
Based on my and JC's test, turning on wifi (if you are connected to wifi), keeping wifi turned on during the standby or sleep mode does not affect the battery life a lot.
2. 3G
Keeping 3G turned on is a good habit. Because it covers wifi and 4G whenever those are not available. 3G uses battery a lot less than wifi and 4G.
Howto keep it on: setting -> more -> mobile networks -> check 3G DATA
3. 4G
Just like wifi, minimize turning on 4G network. This use a lot of battery if you are in the bad reception area. If the signal strength is really good, then it would be probably ok keeping 4G turned on. In some cases, 4G would be the only solution to watch the movies, streaming videos when the wifi is not available.
Based on my limited test, using 4G in good reception area is much better than using wifi with low/weak signal.
4. Call option
Mark checkbox for Turn on proximity sensor for your convenience even there would be a little battery drain. But if you are a heavy talker, then I recommend to uncheck this option.
5. Sound
Lower the sound/vibration level within the acceptable range for you. There would be some differences on battery behavior by turning off or on of sound/vibration. But I don't want to recommend anything in here because I don't want you to lose any incoming calls/messages/etc.
6. Display
Automatic brightness should be fine in most cases. It's really related to screen on time battery consumption. I don't want to deal with this option at this time.
Pulse notification light, display battery percentage - turn it on or off based on your preference. Battery consumption by turning on these options would be minimal. I saw that some people said that they recommend to turning off the 'pulse notification light'. But I don't agree with that. One blinking LED light almost does not use any battery!
display timeout - I set it with highest value provided. After using the phone, I manually press the power button to go to sleep mode. With short timeout value, I have to keep press the button or screen to keep the screen on. I don't like this method.
Turn on 'Auto adjust screen power'.
7. Power saving mode
I always keep this option off because I do not want to lose anything because of low battery. I would rather change the numbers in my tweak (battery profile 2 in scaling tweak).
8. Account and sync
Most of time, I keep this option turned off. This would be one of the battery eating monster. I would rather individually sync the apps whenever I need it or from the actual apps.
9. Battery
when you charge the battery and phone shows that 100% charged, unplug the cable few seconds and plug-in again to charger. Repeat this couple of times and your battery would be really fully charged. Many times, even phone shows 100% charged, it could be the minimum 100% range. Actually, there's some voltage allowed and considered as 100% charge. But by maximizing the voltage during the charge, your battery life could be extended.
10. Motion
Turn off this option if you don't need this.
11. email
If possible, turn off the option that pushing email immediately. Instead, put the retrieval interval as long as you can. Based on my test, it could extend your battery life as maximum as couple of hours. In my case, I put the 2 hours interval. By doing this, your phone is much easier to enter the 'deep sleep' mode.
7. Startups
For me, I don't allow the apps automatically start during the boot as much as possible. If it's the system app and critical app for the phone's normal operation, then you have to allow those startups but otherwise, you can disable the startup apps based on your test.
For this, I usually use Rom Toolbox and/or System Tuner Pro. These apps allow us to enable or disable the startup apps.
For any apps like I don't use frequently or at all, I disable the apps from the 'event' (rom toolbox) or startups (system tuner pro). Once you disable the startups, you may need some test to see what happens when you manually launch the apps. If your app does not start normally, then go back and enable the event again.
There's also one more battery eating moster - widgets (currently doing some experimental test on it)
Regardless of widgets are in foreground screen or just stays in widgets folder, almost same amount of battery could be used by widgets to make it upto dated and refresh the connections, etc.
So, if you don't need the widget or don't use, go to (from Rom Toolbox) Auto Start Manager -> Applications -> select app you want to check -> it will show that widget updating is enabled or not. If it's enabled and you don't want it, just disable it. Then the app is not going to use that specific widget and actually widget will disappear from widgets folder.
8. Closing comments
Thanks for reading my guide and tweaks. I hope everyone of you found some useful information in here.
I'm not perfect just like you. So, there could be some wrong information. If you find anything like that, please let me know.
Again,
Do it with your own risk and don't ask me to buy you a beer because you're doing it. But, if you like this info and/or you see any longer battery life of your phone, please don't hesitate saying 'thank you' and/or consider to buy me a beer.
I'm ok with not leaving any comments and just taking this tweak and recommendation but don't use this info in any other places with 'copy and paste' style.
What's in attachment:
all_in_here.zip First version of tweaks. build.prop is based on FD26.
70wifiSleepWait_kobridge.zip Tweak to handle the wifi lag time before sleep. Wifi will be turned on 10 seconds after the screen turned off. To make this tweak work, you will need sqlite3 and some manual task. Check here http://forum.xda-developers.com/showthread.php?t=1630792
FE07stock_build.prop.zip This is a build.prop file tweaked based on stock kernel FE07. This file would not work on other Roms but stock. You can use this on other stock based kernel but some information about the phone would be incorrectly displayed at settings > About phone. So, use the right version of build.prop. For any other Roms/Kernels, you can just keep your build.prop if you do not find any tweaked build.prop based on your kernel/rom.
init.d.v2b.zip Including CPU tweaks, additional tweaks, and wifi idle (lag) time tweak. Set to max cpu speed to 1Ghz on awake, max 500Mhz during the sleep. Fast and lots of power savings during the sleep mode.
init.dv2b2.zip Same as init.d.v2b scripts except some more CPU tweak changes. Same Max awake and sleep speed. Targeting more power save but no result yet. Experimental tweaks (you may experience a little slowness of phone with these tweaks).
Tweaked-FE10-build.prop.zip This is a tweaked Stock FE10 build.prop. This file would not work on other Roms but stock. Directly under /system folder and permission set to 644. Other init.d tweaks don't need to be changed.
zipalign.zip Two files included. zipalign goes to /system/xbin, permission 755, move the file if it's not there. 11zipalign goes to /system/etc/init.d. permission 755. If there is any apk files those are not zip aligned, this tweak will automatically align the apk files for better performance and battery savings.
zipalign.v3.1.zip 11zipalign modified a little to confirm the temporary APK file removal. If temporary APK is not deleted, it will be shown in log file and Temporary APK will be removed during the next boot.
init.d.v2.4.zip Complete set of init.d scripts. 41tweaks_other tweak changed a lot based on sysctl and fixed one error. 21&31cpufreq tweaks were also changed more aggressively. 11 & 70 are same. In the zip file, included sqlite3, busybox, zipalign executables in case you don't have it.
70wifiSleepWait_kobridge.v2.zip Check the section 4.5 from OP. Now this tweak works without any manual database handling.
Quick guide about how to install these tweaks :
Because many people asked me how to run these tweaks, I spent sometime to give you the quick instruction. To follow this instruction, you will need the following files downloaded and available at your sdcard.
Pre-requisite:
1. init.d scripts (able to download from op section). Download the zip file and unzip it. Save the files into your sdcard.
2. build.prop file (able to download from op section).
3. sqlite3 executable (just in case you want to use the tweak that updating wifi idle time before sleep). where to download and how to use it is here - http://forum.xda-developers.com/showthread.php?t=1630792
4. Get the install-recovery.sh from here if you are on the stock kernel (not repacked) - http://forum.xda-developers.com/showthread.php?t=1610741
If you have sfhub's auto root tool, then run the option 'E' to install the init.d support installed on your phone. Actually his tool will install the install-recovery.sh. (I assume that you've already have busybox installed, otherwise, you can download it too from above link)
Backup:
Do the backup for the following files -
1. /system/etc/init.d files - if there's any existing init.d scripts then back it up.
2. /system/build.prop - backup this file also for just in case
Now you are ready to start, follow these steps:
1. copy downloaded init.d script into /system/etc/init.d folder. If the init.d folder is not there, create the folder 'init.d' under /system/etc. Be sure that init.d folder permission should be 'rwxr_xr_x' (755). For the copied init.d scripts, check the permissions and changed it to same 755 (if it's not like that). If there's any script that you don't want to run during the boot, then change the permission to 'rw_r__r__' (644).
2. copy the install-recovery.sh file to /system/etc folder (only if you are on stock kernel or you've never installed sfhub's auto root tool (option 'E'). Change the permission to 'r_xr_x___' (550).
3. copy build.prop file to /system folder. Change the permission to 'rw_r__r__' (644).
4. Additional steps if you don't have sqlite3 or busybox.
copy the files to /system/xbin folder. permission 755.
5. You are done now. Reboot the phone.
How to verify that the script is running - the easiest way would be checking the Maximum CPU speed and SD tweaks applied to your phone. If you have any tool like Rom Toolbox (Pro) or System Tuner (Pro), then goto the options that showing CPU or SDcard (SD Boost), it will show the different values if you did not applied the tweaks previously.
Hope this help!
[Q/A]
On which Rom/Kernel this tweak is going to work?
The tweaks in here is mainly for the stock based ICS roms/Kernels only.
Any sfhub's rom, any Calk's Rom, any Agat's rom, VeNuM_ICE_Rom_RL5.0, MIJJz BLEND ICS, AnaKonda Rom ICS, etc....
init.d tweak files can be used for some other roms but it's not tested from my side. build.prop tweak is also mainly for stock roms and based on specific kernel version. If the kernel is upgraded, then you will need a different build.prop.
Can I try it on different rom and kernel?
Before applying the tweaks, make sure that you have the nandroid backup first and try it. If the phone is stuck on boot screen, you may need to flash your rom again thru the odin or CWM recovery.
(usually incorrect edit on build.prop file could cause a freezing on boot screen. So be sure that you know how to edit build.prop)
Does build.prop support different ROMs except the stock?
Basically, my answer is no. To make the build.prop working on different ROM, it needs to be modified based on your rom and kernel. Currently I have a few versions supporting stock rom and kernel - check the progress report and change log for any updates. For any other Roms, please check the same area also.
Progress report:
4/29/12 10:50 pm US EST I'm adding three more screenshots.
screenshot#4 : Lasting More than 21 hours and battery still left 52%
#5: showing screen-on statistics. In here, on battery time was reset somehow. But actual time is 21+ hours (same on screenshot #4,5,6)
#6: It shows which apps were running during the sleep mode and screen was off. If you wonder which apps are running when the phone is on sleep/deep sleep mode, you can check the apps thru this kind of tool (battery monitor widget). If you want to save more battery, you can change the options from each apps if it provides a such kind of options.
4/30/12 My first full battery cycle test was ended up with about 40 hours until battery capacity reaches to 30%. During my test, I found some apps were still running during the sleep mode and those were using lots of battery. In my case, some of those apps were touchdown (email), Kakao talk (sns), and facebook apps. In many cases, we are not able to control the method how the application run in foreground and background. Some apps provides us how to sync and when to sync but there are still lots of chances for those apps for the improvement at least in the perspective of battery consumption.
5/1/12 The second version tweak is coming soon -> done.
5/2/12 WiFi issue resolved. http://forum.xda-developers.com/showthread.php?t=1630792 and added one more tweak file. Before applying this file, read the attached thread first. You won't be disappointed.
5/4/12 Tested battery consumption with wifi turned on 24x7 (like JC's snapshot somewhere in this thread). Not bad at all. #7 snapshot shows that. About 19 hours and still 63% remaining (with on screen 30m, voice call 2m, lots of snapshots, lots of emails (100+), some SNS). Added snapshots #8 & 9.
5/5/12 Big Thanks to TeamERA and team member who converted build.prop for each Kernels. TeamERA provided build.prop files based on different Kernels(Roms). Check out the post #88.
Supported Kernel: AOKP CM9a3 (tested) CNA FD26 MIUI. For FD26, I've checked the items and values on it. There's some items sequence change made comparing build.prop in here and minor values changes - post #94.
So anyone who had issues on boot screen with build.prop that I posted, now you can try build.prop tweak based on your current rom.
5/6/12 GB Kernel Test - Blazer 4.1 EL29 - Not able to change the CPU frequencies and frequency change is causing phone freezing during the sleep & wakeup. No way to change this by init.d script so far. Only the way would be using Tegrak or System Tuner Pro tools. I tried System Tuner Pro and set the conservative governor (underclock to 1GHz) as on boot instead of init.d option. Working like a charm and no freezing yet.
Update: since applied, 19 hours and 70% of battery remaining. For more info, post your questions. Related post: http://forum.xda-developers.com/showthread.php?t=1625299&page=11 post #107.
5/8/12 Added FE07 Stock based tweaked build.prop. Only for Stock FE07 based Kennels.
5/9/12 Two more zip files added. init.d.v2b - moderate CPU tweaks. init.dv2b2 - agressive CPU tweaks (could save more battery).
5/10/12 Added AOKP FE07 version of build.prop at post #156.
http://forum.xda-developers.com/showpost.php?p=25907510&postcount=156
5/14/12 zipalign tweak added
5/16/12 wifiSleepWait tweak improved. Check the section 4.5 from OP. Now this tweak works without any manual database handling.
5/17/12 Now supporting flashable zip files. You may get customized flashable zip files based on your rom. Check out - http://forum.xda-developers.com/showthread.php?t=1658471
Issue Log:
5/1/12 a. It seems like changing the Wi-Fi option to 'Never' and pm.sleep_mode to 1 does not work. My previous test based on the 3G turned on always and minimized turning on wifi. Now I'm testing wi-fi options but status shows that wifi is turned on always. Checking more details... Checked with wifi fixer but wifi still does not sleep. Started removing anything related wifi, but no luck yet. Spending several hours but no luck. Going to test on fresh installed stock rom/kernel.
Status: Resolved. http://forum.xda-developers.com/showthread.php?t=1630792
b. AOKP Rom users or custom Kernel users - Do not sue these tweaks. Basically I cannot help any issues on AOKP because I'm not a user of AOKP. So far, it's known that 31tweak file is causing a boot loop on Samsung logo screen.
Change log:
4/29/12 41tweaks_kobridge tweak updated. changed value setprop pm.sleep_mode to sync with build.prop.
4/30/12 lcd_density value changed back to default 240. It's my mistake uploading the file based on my configuration and forgot to change it back to default. Thanks to TeamERA for findings. If anything else found, more updates will be added to build.prop.
Thanks again to TeamERA. He found another one - "In your kobridgetweaks script you have ring delay at 1000, and in build.prop 0, it should be 0". Updated attached zip file.
5/2/12 New wifi idle tweak init.d file attached (only for the update of existing table)
5/4/12 Added 11 email section.
5/6/12 Wrong link in wifi section corrected.
5/8/12 Build.prop created based on FE07. Rearranged tweaked items based on Stock sequence. Removed duplicates.
5/9/12 uploaded updated init.d scripts. CPU tweaks changed to deal with only ondemand governor. Fixed few errors on 41tweaks. Currently it's a beta version because very few times, I saw that wifi was not automatically reconnected after the sleep. I confirmed that it's the stock rom issue and it's not coming from the tweaks in here.
5/14/12 zipalign tweak updated to confirm the removal of temporary APK files.
5/15/12 Improvement on 41Tweaks_other tweak file (more tweaks based on sysctl). Fixed on error from previous file. 21&31 CPU tweak files were changed more aggressively.
5/16/12 70wifiSleepWait_kobridge version2 tweak uploaded.
I am basically running everything exactly as you mentioned with one exception... the wifi while I am asleep. I generally lose between 2 and 5% over eight hours but I am right next to the router. I never thought to try turning it off and letting the 3g sleep take care of things but I will definitely give it a shot since we are basically on the same page with sync, screen time out, etc. I do also have auto brightness off and slide across status bar to adjust but that wouldn't make an enormous difference. Also inverted apps really seem to get me on average an extra hour or so of screen on time. Very thorough info. I need to consider running my CPU at 1000 Max as well
Edit..all FD26 setup with init.d added by sfhub's auroroot option E
Sent from my SPH-D710 using Xparent Blue Tapatalk 2
JohnCorleone said:
I am basically running everything exactly as you mentioned with one exception... the wifi while I am asleep. I generally lose between 2 and 5% over eight hours but I am right next to the router. I never thought to try turning it off and letting the 3g sleep take care of things but I will definitely give it a shot since we are basically on the same page with sync, screen time out, etc. I do also have auto brightness off and slide across status bar to adjust but that wouldn't make an enormous difference. Also inverted apps really seem to get me on average an extra hour or so of screen on time. Very thorough info. I need to consider running my CPU at 1000 Max as well
Edit..all FD26 setup with init.d added by sfhub's auroroot option E
Sent from my SPH-D710 using Xparent Blue Tapatalk 2
Click to expand...
Click to collapse
Thanks John for the input! The easiest way to adding init.d support is adding his script (recovery-install.sh) into /system/etc folder with permission 550. recovery-install.sh is available thru my linked thread (just in case you don't have it).
Again thanks for trying and let me know your findings!
BTW the script is install-recovery.sh (not recovery-install.sh) I think you had it right in some sections but reversed it in others.
Also since we last discussed I made some improvements to the script. It is now compatible with other apps which like to use install-recovery.sh to get their stuff done like link2sd. The installer in Auto Root will move the existing install-recovery.sh to install-recovery-orig.sh and the install-recovery.sh (init.d version) will call install-recovery-orig.sh (if present) after it is done. The uninstaller will reverse the process.
Also install-recovery.sh will now defer to init.d support in the kernel regardless of which .rc file it was added to in the kernel. Previously it only looked in init.rc but I saw some repacked kernels were adding support in different .rc files (they also removed install-recovery.sh support from their .rc file, so it might be a moot point because install-recovery.sh might never get called)
Thanks kobridge. I think this script is just what I've been looking for and I'm going to give it a run.
sfhub, somewhat off topic, but continuing with kobridge's related thread, How to run init.d scripts on boot, how come chmod 755 is not expressed rwx-rx-rx instead of -rwxr-xr-x? Seems more logical to me.
sfhub said:
BTW the script is install-recovery.sh (not recovery-install.sh) I think you had it right in some sections but reversed it in others.
Also since we last discussed I made some improvements to the script. It is now compatible with other apps which like to use install-recovery.sh to get their stuff done like link2sd. The installer in Auto Root will move the existing install-recovery.sh to install-recovery-orig.sh and the install-recovery.sh (init.d version) will call install-recovery-orig.sh (if present) after it is done. The uninstaller will reverse the process.
Also install-recovery.sh will now defer to init.d support in the kernel regardless of which .rc file it was added to in the kernel. Previously it only looked in init.rc but I saw some repacked kernels were adding support in different .rc files (they also removed install-recovery.sh support from their .rc file, so it might be a moot point because install-recovery.sh might never get called)
Click to expand...
Click to collapse
Thanks so much sfhub!
It seems like I stayed too many nights awake. I corrected one place saying recovery-install.sh to install-recovery.sh.
Now I'm downloading your auto root package again and let me also correct the information accordingly.
RustedRoot said:
Thanks kobridge. I think this script is just what I've been looking for and I'm going to give it a run.
sfhub, somewhat off topic, but continuing with kobridge's related thread, How to run init.d scripts on boot, how come chmod 755 is not expressed rwx-rx-rx instead of -rwxr-xr-x? Seems more logical to me.
Click to expand...
Click to collapse
It's always rwxrwxrwx order.
rwx (read write execute) -> 4 + 2 + 1 -> 7
rw_ -> 4 + 2 + 0 -> 6
r_x -> 4 + 0 + 1 -> 5
r__ -> 4 + 0 + 0 -> 4
the second bit is always for w (write) permission. So, the order -rx is not possible.
Some basic binary calculation and permission related info:
The permission is consist of 9 bits for user, group, and other (each user group holds 3 bits).
With binary expression, it would be same
111 (user) 111 (group) 111 (other)
For first bit represent the read permision and the second is for write, third one is for execute.
so 755 equals in binary expression 111 101 101 (= rwxr_xr_x)
Thanks for the info kobridge, I still have not figured out why wifi causes a partial wake lock on ICS. But it plays much better with GB. Ive tested this also.
Sent from my SPH-D710 using xda premium
So these can be applied to gingerbread right?
Sent from my SPH-D710 using Tapatalk 2
Can we use this on aokp?
Transmission sent from my slim n trim Galaxy S II.
kobridge said:
It's always rwxrwxrwx order.
rwx (read write execute) -> 4 + 2 + 1 -> 7
rw_ -> 4 + 2 + 0 -> 6
r_x -> 4 + 0 + 1 -> 5
r__ -> 4 + 0 + 0 -> 4
the second bit is always for w (write) permission. So, the order -rx is not possible.
Some basic binary calculation and permission related info:
The permission is consist of 9 bits for user, group, and other (each user group holds 3 bits).
With binary expression, it would be same
111 (user) 111 (group) 111 (other)
For first bit represent the read permision and the second is for write, third one is for execute.
so 755 equals in binary expression 111 101 101 (= rwxr_xr_x)
Click to expand...
Click to collapse
Gotcha, with thanks.
Sent from my SPH-D710 using XDA
Pheno.menon said:
Can we use this on aokp?
Transmission sent from my slim n trim Galaxy S II.
Click to expand...
Click to collapse
It's not been tested on aokp. If the kernel is same, then there are high chances that this tweak would run. But, all the paths on this tweak needs to be verified and tested.
If someone want to run this from AOKP, please try it with scripting tool like SManager first before putting it into init.d folder.
Unfortunately, I don't use AOKP rom yet. Only the way, I can do the test would be downloading the rom and verifying the zip file manually. But if the kernel is different, then I couldn't do that because I don't know the command difference on AOKP rom.
TeamERA said:
Thanks for the info kobridge, I still have not figured out why wifi causes a partial wake lock on ICS. But it plays much better with GB. Ive tested this also.
Sent from my SPH-D710 using xda premium
Click to expand...
Click to collapse
To properly answer your question, we may need the kernel source to check the mechanism.
There are couple of options locking wifi (I think you already know about this, right?)
Sleep Modes: (pm.sleep_mode=)
This is supposedly for topaz/rhodium that I found on the xda wiki:
* '4' will do "wait for interrupt", no change in arm11's clock or voltage
* '3' will do "wait for interrupt and ramp clock", the arm11's clock is lowered to 20MHz instead of 300-500, and voltage is lowered too.
* '2' will do "app sleep", arm11 is still on, but put into low power mode (registers are still saved)
* '1' and '0' will totally power off the arm11 (so we have to restore registers and things ourself), don't know the differences between them
pm.sleep_mode=0 -> Power Collapse Suspend
pm.sleep_mode=1 -> Power Collapse (Provides best power savings)
pm.sleep_mode=2 -> Apps Sleep
pm.sleep_mode=3 -> Slow Clock and Wait for Interrupt
pm.sleep_mode=4 -> Wait for Interrupt
(http://forum.xda-developers.com/showpost.php?p=17680020&postcount=9)
The similar function is also provided by settings > wifi > menu > advanced > Keep wi-fi on during sleep options. There are three options, Always, Only when plugged in, and never.
If you set up above values in somewhere, partial wake up lock would be dependent on the values you've chosen. Aslo, if there is any application which is configured to use wifi for communication, you may also need to check the application if it's causing partial wakeup lock.
It seems like there's something needs to be tested from your side.
FYI, I set the pm.sleep_mode value to 1 in my tweak and build.prop.
Update: I just added some more screenshots on post #2. Check out screenshot #6 and comments on that.
sfhub said:
BTW the script is install-recovery.sh (not recovery-install.sh) I think you had it right in some sections but reversed it in others.
Also since we last discussed I made some improvements to the script. It is now compatible with other apps which like to use install-recovery.sh to get their stuff done like link2sd. The installer in Auto Root will move the existing install-recovery.sh to install-recovery-orig.sh and the install-recovery.sh (init.d version) will call install-recovery-orig.sh (if present) after it is done. The uninstaller will reverse the process.
Also install-recovery.sh will now defer to init.d support in the kernel regardless of which .rc file it was added to in the kernel. Previously it only looked in init.rc but I saw some repacked kernels were adding support in different .rc files (they also removed install-recovery.sh support from their .rc file, so it might be a moot point because install-recovery.sh might never get called)
Click to expand...
Click to collapse
Updated my thread based on your information! http://forum.xda-developers.com/showthread.php?p=25120392#post25120392
Thanks sfhub!
Updated info :
4/29/12 sfhub improved his auto root tool to support some other kernels, those are enabling init.d through different .xc files.
Stock kernels and some repacked kernels are supporting init.d scripts through init.xc and/or install-recovery.sh but some other repacked kernels are supporting init.d scripts running through different .xc files. So, sfhub made some modification on his script. Because he's adding a new install-recovery.sh file into /system/etc folder, if there's a existing install-recovery.sh file at the same location, the existing install-recovery.sh file will be replaced by his previous version of Auto Root Tool. To prevent the replacing existing install-recovery.sh file with his same named install-recovery.sh file which supports the init.d scripts, his tool now creates a copy of old file and create a new one. Old install-recovery.sh file will be named as install-recovery-orig.sh.
If you are enabling the init.d support by running his tool, be sure that the existing install-recovery.sh file was not created by his old Auto root tool nor you manually created it following this guide. If the file is the one you created by sfhub's tool or my guide in here, be sure that you remove the old file manually before you run his new Auto Root Tool. Otherwise, the init.d scripts would run twice whenever you reboot your phone.
If you just want to simply enable init.d support without using sfhub's tool, then download the new-install-recovery.zip file from my second post and unzip it. Like I explained above, if there's any existing install-recovery.sh file and it's not related to init.d support, then rename it to install-recovery-orig.sh and move the unzipped file to same directory (/system/etc). Assign the file permission 550 (r_xr_x___). New install-recovry.sh file will execute the init.d scripts (if it's there) and old install-recovery-orig.sh (if it's there) during the boot.
kobridge said:
If you are enabling the init.d support by running his tool, be sure that the existing install-recovery.sh file was not created by his old Auto root tool nor you manually created it following this guide. If the file is the one you created by sfhub's tool or my guide in here, be sure that you remove the old file manually before you run his new Auto Root Tool. Otherwise, the init.d scripts would run twice whenever you reboot your phone.
Click to expand...
Click to collapse
BTW the installer in Auto Root checks to see if the existing install-recovery.sh is the one that adds init.d support. If it is, it just overwrites it. Only if the existing install-recovery.sh has nothing to do with init.d support does it move it to install-recovery-orig.sh. The way it detects whether the existing install-recovery.sh is used for init.d support is the presence of the BusyboxBin string, which is the shell variable used to define the busybox location used by the script. The chances some arbitrary install-recovery.sh script defines that string is very low (but not zero)
So bottom line if Auto Root is working properly, it shouldn't be necessary to remove your existing init.d install-recovery.sh script as it will not cause a situation where init.d is run twice.
Also I forgot to mention that some people wanted to run init.d but didn't have busybox installed. I didn't want to clobber busybox for people that have installed it, so basically just had the init.d install-recovery.sh use /system/xbin/busybox-initd (which gets copied into place by the auto root installer) This makes it easier (more symmetrical) to remove init.d support and associated busybox-initd without worrying about who installed busybox to start with.
For the "new-install-recovery.zip" you should do a symlink from busybox-initd to busybox
Code:
su
cd /system/xbin
ln -s busybox busybox-initd
kobridge said:
It's not been tested on aokp. If the kernel is same, then there are high chances that this tweak would run. But, all the paths on this tweak needs to be verified and tested.
If someone want to run this from AOKP, please try it with scripting tool like SManager first before putting it into init.d folder.
Unfortunately, I don't use AOKP rom yet. Only the way, I can do the test would be downloading the rom and verifying the zip file manually. But if the kernel is different, then I couldn't do that because I don't know the command difference on AOKP rom.
Click to expand...
Click to collapse
didn't work for me. had to Odin a kernel and reflash. not sure which script as I tried all from the OP. tomorrow I can figure it out which.
anyway to delete init.d scripts via Odin if it fails to boot? I end up odining el26, wiping, and reflashing. :/
EDIT:
oops. I used the sh script.
want me to post the included fd26 aosp kernel from aokp?
gershee said:
didn't work for me. had to Odin a kernel and reflash. not sure which script as I tried all from the OP. tomorrow I can figure it out which.
anyway to delete init.d scripts via Odin if it fails to boot? I end up odining el26, wiping, and reflashing. :/
EDIT:
oops. I used the sh script.
want me to post the included fd26 aosp kernel from aokp?
Click to expand...
Click to collapse
Do you think aosp kernel works on stock rom? If it is, then I think I can make some test.
If init.d fails on boot, and boot screen is stuck on Samsung logo, then we would flash the rom again. Flashing kernel would not help because it does not delete the system partition. Once after the rom is flashed, do the nandroid recovery that you made before the init.d test.
kobridge said:
snip
Click to expand...
Click to collapse
Just curious if you are experiencing any Sleep of Death using the CPU screenstate settings you have, specifically enabling a powersave as the sleep governor with a cpu freq range of 200-500. A very common issue on the ICS builds so far is setting the max freq below 1ghz can cause Sleep of Death where the device will not wake from sleep and must be rebooted.
odub303 said:
Just curious if you are experiencing any Sleep of Death using the CPU screenstate settings you have, specifically enabling a powersave as the sleep governor with a cpu freq range of 200-500. A very common issue on the ICS builds so far is setting the max freq below 1ghz can cause Sleep of Death where the device will not wake from sleep and must be rebooted.
Click to expand...
Click to collapse
And I was curious if the undervolt or underclock have triggered any 4g reboots for you. A few of my friends were getting them on earlier ICS ROM and I had them delete the undervolt script and they stopped. Some people's phones just handle that stuff better than others though
Sent from my Nexus S 4G using Xparent Blue Tapatalk 2

Edit build.prop through updater-script

Hello fellas.
Back in the day, if I wanted to keep my dpi setting of 280 after flashing a new nightly (talking CM now), I just made a local.prop with the modified line and put it in /data.
Since, I think, CM10, though, local.prop doesn't get loaded, so I have to manually change build.prop.
I know a solution to this would be just keeping the same build.prop and flashing it after the rom (I already have a zip with the modifications I like that I flash after each nightly), but I don't really want to keep an old build.prop. What I want is to juat modify the line through my zip, so it stays updated while I don't have to modify the line every single day.
I found very quickly that I can use this line:
sed -i 's/ro.sf.lcd_density=320/ro.sf.lcd_density=280/g' /system/build.prop
to get the job done, and it does indeed work if I run it using the terminal. The problem is, I can't get it to work in recovery.
Having very little experience with programming, I'm just trying stuff to see if it works. I treid directly including the like line in the updater-script, didn't have too much hope for that.
I also tried including another simple file with this code:
#!/sbin/sh
sed -i 's/ro.sf.lcd_density=320/ro.sf.lcd_density=280/g' /system/build.prop
that I then extract and run, as I've seen in threads in the forum, but still doesn't work. The file gets extracted, but it doesn't work
I even tried to do it in a userinit script form, just to see if the rom loaded it on boot, but nope.
This is pretty friggin' simple to do, and I'm sure I'm probably making a silly noob mistake, but I just don't have any experience with this kind of code, so if someone can tell me how to make my zip run that very simple line, I'd much appreciate it.
Thanks.
Ok, after moar and moar and moar search, I finally found a script that does the job.
Problem solved.
yay
yay
Hi,
can you please provide your solution. I'm also trying to edit values in build.prop.
I tried to do via init.d script. The script is fine but / system seems to be read only when executing script at startup.
So it would be great if you can reply how you did it (maybe complete other way).
Thanks in advanced!
This is the post in question.
Swiftkey'd from my GNexus
Perfect, thanks a lot! I already found a workaround via an init.d script but this looks very promissing....
Sent from my XT894 using xda app-developers app
It's very useful.
I just included it in my after-nightly zip, so everything becomes automated with cyandelta.
Swiftkey'd from my GNexus
Hi,
So how do I edit AND add lines to build.prop from recovery ZIP?
Easy solution
Or maybe using just the updater-script and this code (this should also work on every rom)
run_program("/sbin/sh", "-c", "sed -i 's:ro.sf.lcd_density=.*:ro.sf.lcd_density=280:' /system/build.prop");
Click to expand...
Click to collapse
You can change 280 to another value if you want.
..
Molitro said:
Hello fellas.
Back in the day, if I wanted to keep my dpi setting of 280 after flashing a new nightly (talking CM now), I just made a local.prop with the modified line and put it in /data.
Since, I think, CM10, though, local.prop doesn't get loaded, so I have to manually change build.prop.
I know a solution to this would be just keeping the same build.prop and flashing it after the rom (I already have a zip with the modifications I like that I flash after each nightly), but I don't really want to keep an old build.prop. What I want is to juat modify the line through my zip, so it stays updated while I don't have to modify the line every single day.
I found very quickly that I can use this line:
sed -i 's/ro.sf.lcd_density=320/ro.sf.lcd_density=280/g' /system/build.prop
to get the job done, and it does indeed work if I run it using the terminal. The problem is, I can't get it to work in recovery.
Having very little experience with programming, I'm just trying stuff to see if it works. I treid directly including the like line in the updater-script, didn't have too much hope for that.
I also tried including another simple file with this code:
#!/sbin/sh
sed -i 's/ro.sf.lcd_density=320/ro.sf.lcd_density=280/g' /system/build.prop
that I then extract and run, as I've seen in threads in the forum, but still doesn't work. The file gets extracted, but it doesn't work
I even tried to do it in a userinit script form, just to see if the rom loaded it on boot, but nope.
This is pretty friggin' simple to do, and I'm sure I'm probably making a silly noob mistake, but I just don't have any experience with this kind of code, so if someone can tell me how to make my zip run that very simple line, I'd much appreciate it.
Thanks.
Click to expand...
Click to collapse
Sir can you tell me what to do to change ro.product.name if same phone in different regions is having different ro.product.name so that the build.prop for every phone that's installed.

Categories

Resources