[Script] Hollyname CM7 Build.prop Tweaks

Search This thread

chairshot215

Senior Member
Oct 23, 2011
298
287
Philadelphia
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
 
Last edited:

manchucka

Senior Member
Aug 30, 2010
286
195
San Francisco
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
 
Last edited:

manchucka

Senior Member
Aug 30, 2010
286
195
San Francisco
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.

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
 
Last edited:
  • Like
Reactions: chairshot215

chairshot215

Senior Member
Oct 23, 2011
298
287
Philadelphia
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

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.

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


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.
 
Last edited:

Top Liked Posts

  • There are no posts matching your filters.
  • 1
    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.

    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