Remove All Ads from XDA

[SCRIPT/TWEAKS] [LOTK] Smurfed Out V 6.6 (ultimate build.prop/init.d) 4-21

5,662 posts
Thanks Meter: 6,791
Post Reply Email Thread
I/O Scheduler Descriptions

Taken from this post here

Q. "What purposes does an i/o scheduler serve?"
Minimize hard disk seek latency.
Prioritize I/O requests from processes.
Allocate disk bandwidth for running processes.
Guarantee that certain requests will be served before a deadline.

So in the simplest of simplest form: Kernel controls the disk access using I/O Scheduler.

Q. "What goals every I/O scheduler tries to balance?"
Fairness (let every process have its share of the access to disk)
Performance (try to serve requests close to current disk head position first, because seeking there is fastest)
Real-time (guarantee that a request is serviced in a given time)

Q. "Description, advantages, disadvantages of each I/O Scheduler?"

1) Noop

Inserts all the incoming I/O requests to a First In First Out queue and implements request merging. Best used with storage devices that does not depend on mechanical movement to access data (yes, like our flash drives). Advantage here is that flash drives does not require reordering of multiple I/O requests unlike in normal hard drives.

Serves I/O requests with least number of cpu cycles. (Battery friendly?)
Best for flash drives since there is no seeking penalty.
Good throughput on db systems.
Reduction in number of cpu cycles used is proportional to drop in performance.

2) Deadline

Goal is to minimize I/O latency or starvation of a request. The same is achieved by round robin policy to be fair among multiple I/O requests. Five queues are aggressively used to reorder incoming requests.

Nearly a real time scheduler.
Excels in reducing latency of any given single I/O.
Best scheduler for database access and queries.
Bandwidth requirement of a process - what percentage of CPU it needs, is easily calculated.
Like noop, a good scheduler for solid state/flash drives.
When system is overloaded, set of processes that may miss deadline is largely unpredictable.

3) CFQ

Completely Fair Queuing scheduler maintains a scalable per-process I/O queue and attempts to distribute the available I/O bandwidth equally among all I/O requests. Each per-process queue contains synchronous requests from processes. Time slice allocated for each queue depends on the priority of the 'parent' process. V2 of CFQ has some fixes which solves process' i/o starvation and some small backward seeks in the hope of improving responsiveness.

Considered to deliver a balanced i/o performance.
Easiest to tune.
Excels on multiprocessor systems.
Best database system performance after deadline.
Some users report media scanning takes longest to complete using CFQ. This could be because of the property that since the bandwidth is equally distributed to all i/o operations during boot-up, media scanning is not given any special priority.
Jitter (worst-case-delay) exhibited can sometimes be high, because of the number of tasks competing for the disk.

4) BFQ

Instead of time slices allocation by CFQ, BFQ assigns budgets. Disk is granted to an active process until it's budget (number of sectors) expires. BFQ assigns high budgets to non-read tasks. Budget assigned to a process varies over time as a function of it's behavior.

Believed to be very good for usb data transfer rate.
Believed to be the best scheduler for HD video recording and video streaming. (because of less jitter as compared to CFQ and others)
Considered an accurate i/o scheduler.
Achieves about 30% more throughput than CFQ on most workloads.
Not the best scheduler for benchmarking.
Higher budget assigned to a process can affect interactivity and increased latency.

5) SIO

Simple I/O scheduler aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority quesues concepts, but only basic merging. Sio is a mix between noop & deadline. No reordering or sorting of requests.

Simple, so reliable.
Minimized starvation of requests.
Slow random-read speeds on flash drives, compared to other schedulers.
Sequential-read speeds on flash drives also not so good.

6) V(R)

Unlike other schedulers, synchronous and asynchronous requests are not treated separately, instead a deadline is imposed for fairness. The next request to be served is based on it's distance from last request.

May be best for benchmarking because at the peak of it's 'form' VR performs best.
Performance fluctuation results in below-average performance at times.
Least reliable/most unstable.

7) Anticipatory

Based on two facts
i) Disk seeks are really slow.
ii) Write operations can happen whenever, but there is always some process waiting for read operation.

So anticipatory prioritize read operations over write. It anticipates synchronous read operations.

Read requests from processes are never starved.
As good as noop for read-performance on flash drives.
'Guess works' might not be always reliable.
Reduced write-performance on high performance disks.

Q. "Best I/O Scheduler?"
A.There is nothing called "best" i/o scheduler. Depending on your usage environment and tasks/apps been run, use different schedulers. That's the best i can suggest.
However, considering the overall performance, battery, reliability and low latency, it is believed that
SIO > Noop > Deadline > VR > BFQ > CFQ, given all schedulers are tweaked and the storage used is a flash device

Explanation of Different Governors

Pulled from this page here

1) Ondemand:
Default governor in almost all stock kernels. One main goal of the ondemand governor is to switch to max frequency as soon as there is a CPU activity detected to ensure the responsiveness of the system. (You can change this behavior using smooth scaling parameters, refer Siyah tweaks at the end of 3rd post.) Effectively, it uses the CPU busy time as the answer to "how critical is performance right now" question. So Ondemand jumps to maximum frequency when CPU is busy and decreases the frequency gradually when CPU is less loaded/apporaching idle. Even though many of us consider this a reliable governor, it falls short on battery saving and performance on default settings. One potential reason for ondemand governor being not very power efficient is that the governor decide the next target frequency by instant requirement during sampling interval. The instant requirement can response quickly to workload change, but it does not usually reflect workload real CPU usage requirement in a small longer time and it possibly causes frequently change between highest and lowest frequency.

2) Ondemandx:
Basically an ondemand with suspend/wake profiles. This governor is supposed to be a battery friendly ondemand. When screen is off, max frequency is capped at 500 mhz. Even though ondemand is the default governor in many kernel and is considered safe/stable, the support for ondemand/ondemandX depends on CPU capability to do fast frequency switching which are very low latency frequency transitions. I have read somewhere that the performance of ondemand/ondemandx were significantly varying for different i/o schedulers. This is not true for most of the other governors. I personally feel ondemand/ondemandx goes best with SIO I/O scheduler.

3) Conservative:
A slower Ondemand which scales up slowly to save battery. The conservative governor is based on the ondemand governor. It functions like the Ondemand governor by dynamically adjusting frequencies based on processor utilization. However, the conservative governor increases and decreases CPU speed more gradually. Simply put, this governor increases the frequency step by step on CPU load and jumps to lowest frequency on CPU idle. Conservative governor aims to dynamically adjust the CPU frequency to current utilization, without jumping to max frequency. The sampling_down_factor value acts as a negative multiplier of sampling_rate to reduce the frequency that the scheduler samples the CPU utilization. For example, if sampling_rate equal to 20,000 and sampling_down_factor is 2, the governor samples the CPU utilization every 40,000 microseconds.

4) Interactive:
Can be considered a faster ondemand. So more snappier, less battery. Interactive is designed for latency-sensitive, interactive workloads. Instead of sampling at every interval like ondemand, it determines how to scale up when CPU comes out of idle. The governor has the following advantages: 1) More consistent ramping, because existing governors do their CPU load sampling in a workqueue context, but interactive governor does this in a timer context, which gives more consistent CPU load sampling. 2) Higher priority for CPU frequency increase, thus giving the remaining tasks the CPU performance benefit, unlike existing governors which schedule ramp-up work to occur after your performance starved tasks have completed. Interactive It's an intelligent Ondemand because of stability optimizations. Why??
Sampling the CPU load every X ms (like Ondemand) can lead to under-powering the CPU for X ms, leading to dropped frames, stuttering UI, etc. Instead of sampling the CPU at a specified rate, the interactive governor will check whether to scale the CPU frequency up soon after coming out of idle. When the CPU comes out of idle, a timer is configured to fire within 1-2 ticks. If the CPU is very busy between exiting idle and when the timer fires, then we assume the CPU is underpowered and ramp to max frequency.

5) Interactivex:
This is an Interactive governor with a wake profile. More battery friendly than interactive.

6) Lulzactive:
This new find from Tegrak is based on Interactive & Smartass governors and is one of the favorites.
Old Version: When workload is greater than or equal to 60%, the governor scales up CPU to next higher step. When workload is less than 60%, governor scales down CPU to next lower step. When screen is off, frequency is locked to global scaling minimum frequency.
New Version: Three more user configurable parameters: inc_cpu_load, pump_up_step, pump_down_step. Unlike older version, this one gives more control for the user. We can set the threshold at which governor decides to scale up/down. We can also set number of frequency steps to be skipped while polling up and down.
When workload greater than or equal to inc_cpu_load, governor scales CPU pump_up_step steps up. When workload is less than inc_cpu_load, governor scales CPU down pump_down_step steps down.
If current frequency=200, Every up_sampling_time Us if cpu load >= 70%, cpu is scaled up 2 steps - to 800.
If current frequency =1200, Every down_sampling_time Us if cpu load < 70%, cpu is scaled down 1 step - to 1000.

7) Smartass:
Result of Erasmux rewriting the complete code of interactive governor. Main goal is to optimize battery life without comprising performance. Still, not as battery friendly as smartassV2 since screen-on minimum frequency is greater than frequencies used during screen-off. Smartass would jump up to highest frequency too often as well.

8) SmartassV2:
Version 2 of the original smartass governor from Erasmux. Another favorite for many a people. The governor aim for an "ideal frequency", and ramp up more aggressively towards this freq and less aggressive after. It uses different ideal frequencies for screen on and screen off, namely awake_ideal_freq and sleep_ideal_freq. This governor scales down CPU very fast (to hit sleep_ideal_freq soon) while screen is off and scales up rapidly to awake_ideal_freq (500 mhz for GS2 by default) when screen is on. There's no upper limit for frequency while screen is off (unlike Smartass). So the entire frequency range is available for the governor to use during screen-on and screen-off state. The motto of this governor is a balance between performance and battery.

9) Intellidemand:
Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand. Unlike what some users believe, this governor is not the replacement for OC Daemon (Having different governors for sleep and awake). The original intellidemand behaves differently according to GPU usage. When GPU is really busy (gaming, maps, benchmarking, etc) intellidemand behaves like ondemand. When GPU is 'idling' (or moderately busy), intellidemand limits max frequency to a step depending on frequencies available in your device/kernel for saving battery. This is called browsing mode. We can see some 'traces' of interactive governor here. Frequency scale-up decision is made based on idling time of CPU. Lower idling time (<20%) causes CPU to scale-up from current frequency. Frequency scale-down happens at steps=5% of max frequency. (This parameter is tunable only in conservative, among the popular governors )
To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling, and (exits browsing mode) behaves like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off.

10) Lazy:
This governor from Ezekeel is basically an ondemand with an additional parameter min_time_state to specify the minimum time CPU stays on a frequency before scaling up/down. The Idea here is to eliminate any instabilities caused by fast frequency switching by ondemand. Lazy governor polls more often than ondemand, but changes frequency only after completing min_time_state on a step overriding sampling interval. Lazy also has a screenoff_maxfreq parameter which when enabled will cause the governor to always select the maximum frequency while the screen is off.

11) Lagfree:
Lagfree is similar to ondemand. Main difference is it's optimization to become more battery friendly. Frequency is gracefully decreased and increased, unlike ondemand which jumps to 100% too often. Lagfree does not skip any frequency step while scaling up or down. Remember that if there's a requirement for sudden burst of power, lagfree can not satisfy that since it has to raise cpu through each higher frequency step from current. Some users report that video playback using lagfree stutters a little.

12) Lionheart:
Lionheart is a conservative-based governor which is based on samsung's update3 source. Tweaks comes from 1) Knzo 2) Morfic. The original idea comes from Netarchy. See here. The tunables (such as the thresholds and sampling rate) were changed so the governor behaves more like the performance one, at the cost of battery as the scaling is very aggressive.

To 'experience' Lionheart using conservative, try these tweaks:
sampling_rate:10000 or 20000 or 50000, whichever you feel is safer. (transition latency of the CPU is something below 10ms/10,000uS hence using 10,000 might not be safe).
Lionheart goes well with deadline i/o scheduler. When it comes to smoothness (not considering battery drain), a tuned conservative delivers more as compared to a tuned ondemand.

13) LionheartX
LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend profile based on Smartass governor.

14) Brazilianwax:
Similar to smartassV2. More aggressive ramping, so more performance, less battery.

15) SavagedZen:
Another smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.

16) Userspace:
Instead of automatically determining frequencies, lets user set frequencies.

17) Powersave:
Locks max frequency to min frequency. Can not be used as a screen-on or even screen-off (if scaling min frequency is too low).

18) Performance:
Sets min frequency as max frequency. Use this while benchmarking!

So, Governors can be categorized into 3/4 on a high level:
1.a) Ondemand Based:
Works on "ramp-up on high load" principle. CPU busy-time is taken into consideration for scaling decisions. Members: Ondemand, OndemandX, Intellidemand, Lazy, Lagfree.
1.b) Conservative Based:
Members: Conservative, Lionheart, LionheartX
2) Interactive Based:
Works on "make scaling decision when CPU comes out of idle-loop" principle. Members: Interactive, InteractiveX, Lulzactive, Smartass, SmartassV2, Brazilianwax, SavagedZen.
3) Weird Category:
Members: Userspace, Powersave, Performance.
The Following 31 Users Say Thank You to Papa Smurf151 For This Useful Post: [ View ] Gift Papa Smurf151 Ad-Free
26th February 2012, 04:51 AM |#2  
Papa Smurf151's Avatar
OP Senior Member
Flag Atlanta
Thanks Meter: 6,791
Donate to Me
[SCRIPT] Smurfed Out V 5.0 (ultimate build.prop/init.d tweaks) Updated 3-18
Explanation of LMK Settings (Low Memory Killer)


Explanation of Adj and Minfree settings

When your phone boots up, a file inside the boot image (init.rc) sets the system parameters. Things like the path to framework files, setting up your networks, and setting the limits at which programs are killed off to free RAM are done by this file. Now a super-Android-geek might dig inside the init.rc file and completely customize the low memory killer, but you don't have to do this to still get good results. The init.rc sets up six different "levels" of open applications. Let's have a look at them:

FOREGROUND_APP: This is the application currently on the screen, and running
VISIBLE_APP: This is an application that is open, and running in the background because it's still doing something
SECONDARY_SERVER: This is a process (a service that an application needs) that is alive and ready in case it's needed to do something
HIDDEN_APP: This again is a process, that sits idle (but still alive) in case it's needed by an app that's alive and running
For the most part, we never want to adjust when these apps and processes are killed off. They are the things that the programs we use need to properly function. For the more bold and advanced users, changing settings for HIDDEN_APP settings is possible, albeit with a LOT of trial and error. There's two more settings, and these are the ones most interesting to us today:

CONTENT_PROVIDER: This is apps that provide data (content) to the system. HTC Facebook Sync? That's a CONTENT_PROVIDER. So are things like the Android Market, or Fring. If they are alive, they can refresh and provide the content they are supposed to at the set interval. If you kill them, they can't of course.
EMPTY_APP: I call these "ghosts." They are apps that you have opened, but are done with them. Android uses a unique style of handling memory management. When an activity is ended, instead of killing it off Android keeps the application in memory so that opening them again is a faster process. Theses "ghost" apps use no battery or CPU time, they just fill RAM that would be otherwise empty. When this memory is needed by a different application or process, the RAM is flushed and made available for the new app. To satisfy the geekier people (like myself) Android does this by keeping a list of recently used apps, with the oldest apps in the list given the lowest priority -- they are killed first if RAM is needed elsewhere. This is a perfect way to handle 'ghost' processes, so there's no need to touch this part

So when you see settings like this 8,14,40,50,60, 75 you start with the first setting and it looks like this


You can manipulate these numbers so that they are better managed and give You different aggressiveness and a faster UI

For the Smurfed Out script the settings are as follows

Lite = 8,14,55,70,85,100
Medium = 8,14,75,90,95,125
Max = 25,35,55,70,150,250
Extreme = 25,35,75,90,150,250

Minfrees are set as well but they are equal to the LowMemoryKiller ADJ settings.

I personally run them at Max while using ICS but everyone's experiences will be different.
The Following 19 Users Say Thank You to Papa Smurf151 For This Useful Post: [ View ] Gift Papa Smurf151 Ad-Free
26th February 2012, 04:51 AM |#3  
Papa Smurf151's Avatar
OP Senior Member
Flag Atlanta
Thanks Meter: 6,791
Donate to Me
[SCRIPT/TWEAKS] [LOTK] Smurfed Out V 6.6 (ultimate build.prop/init.d) 4-21
Welcome to Smurf Land.......Where you are whisked away to a smurfalicious place!

LA LA lalalala LA LA LA LA LAAAAAA....

Alright enough with the cuteness of all this.

Basically I have created a script that prompts you (the user) to answer some vital information them based on your answers the script will inject specific tweaks to your build.prop and also to a file in your init.d folder. These tweaks include battery tweaks, memory tweaks, speed tweaks, governor tweaks, 3g and wifi tweaks, SD card tweaks, and a bunch of random tweaks. Some collected from a bunch of different phones tweaks and others created by me.

The script will search out every line in your build.prop and remove any line that is there that I am adding and remove it first to reduce duplicate codes. It will remove a whole list of other init.d files that conflict with it. Will also create a few other files and folders to add functionality and speed optimization to your phone.

What if you do not like the tweaks that I added.....well the script creates back-ups for you and you can choose the option to Un-Smurf and it will set you back to before you installed.


zeppelinrox for his excellent scripts.
tommytomatoe for answering all my ridiculous questions and also the space in which to post my work
Lpy for his loopy smoothness
eoghan2t7 for his tutorial on loopy smoothness
knzo for his collection of tweaks
[email protected] for his collection of scripts which I pulled some tweaks from
metalspring for his explanation of a lot of tweaks and some build.prop and init.d tweaks
scottypeterson for his ultimatescript
cwc3 for his collection of scripts which I borrowed settings from
tazzz811 for his thread on some great init.d tweaks
droidphile for his incredible guides and some great governor tweaks and I/O scheduler tweaks

Each persons name has a link attached to it to show their work and threads which to thank them.

These Settings are all over the Internet across multiple forums and presented by more than a dozen people. If any setting in here was initially created by you and you did not get credit please PM me with your Info so I can add you to the credits. No work here has been stolen or taken on purpose. If you created or founded any of these setting and do not wish for me to use them then again please PM me and I will remove them as soon as possible. Please do not start a flame war on this thread due to my ignorance. I am just trying to get these settings out to as many people as possible to bring the smoothest experience to Our phones.


1. Download Smurfed Out script.

2. Open up Script Manager found here if you don't have it

3. Scroll Down to the file and click on it. This could Possible be in your downloads folder.

4. Click on the su key, the skull and crossbones, or run as root depending on which version of script manager you have then click run

5. Follow instructions on the screen.

!!! Warning !!!

By using this script you acknowledge that it could possible break your phone. In other words don't come running to me when you phone burst into flames and or it leaves you for someone as sexy as it has now become.


Smurfed Out V 6.6

Other Phones

Please feel free to post a thread in other forums or other site but please link back to here for the downloads. I am trying to give the user the best experience possible and if dl links are made all over the place then there is possibility for them to not get updated when I release a new version. Plus the info in the first three post here explains alot.


If you would like this baked into your ROM the PM me and I can help. I already have a ZIP file created with he exact files that you need and instructions with how to implement. I need to make a few corrections based on your specific Rom but it is an easy fix and would rather do it or help you do it so there arnt any conflicts at all. I have already helped a few other DEV's bake it into their Roms and it works great.

Thank Me

If You Find this post USEFULL and ENJOY using the SMURFED OUT Script then Please take the time out to THANK ME. I'm Not asking for Donations but this does take countless hours to put together. Also you can click the links in my sig to see my working in the google market(PLAY) follow me on my Twitter and Facebook sites


I/O Scheduler descriptions

Different Governors

LMK Settings (Low Memory Killer)/ADJ & MINFREE Values


IF running ICS then go here to auto patch your SERVICE.JAR for new OOM settings.
FYI your services.jar can be found /system/frameworks/services.jar.


If your coming from a version before 4.0 I Highly recommend Un-Smurfing First

Highly Recommended

If you want to make sure the settings stick....go into your /system/etc/init.d folder with script manager and set the 45smurfed file to run as root and run at boot. Some say this makes the setting stick others see no effect.


If your launcher does not show up in the auto detector then please inform me of the package name (found in /data/data) usually looks like this blah.blah.launcher. I will add it to the database and update the script rather quickly.

Change log

V 6.6
  • Added Instant Smurf-Power option which will clear out caches and give your phone an oh so fresh feeling (kinda like restarting your phone without having to)
  • Added in half a dozen build.prop tweaks
  • Fixed Some issues with the 45smurfed file
  • Added in ability to choose how much you want your Dalvik heapsize to be
  • Rearranged the Loopy Smoothness Tweak
  • Added in EXT4 Tweaks (convert your sd card over to ext4 and answer the question in the script for it to go into effect)
  • Added in swap support
  • Added in some new checks
  • Added in some permission sets so settings dont get overwritten
  • I'm sure there are more but can't think of any

Highly recommended that you UN-SMURF before you run the newest version as some of the files that the script removed in last version are needed in this version.

V 6.5.1
  • Fixed name of Launcher not being correct
  • Fixed wifi and 3g not switching, addition of last minute build.prop tweak jacked it all up

V 6.5
  • Fixed some syntax errors
  • Corrected names of a few launchers
  • Added in redundancies to back up everything the script removes so when unsmurfing there is no residual effects and everything is returned to Pre-Smurfed conditions
  • Everything is now backed up to a folder created on your SD card now instead of spread all over. File is called SmurfedBackups
  • Tried to fix Launcher Detector not reading some Launchers but cant get pm list packages to sent list to a file with out getting a segmentation error...any suggestions would be helpful
  • If your launcher is not found and you know the name of it try it out cause its saved in the detector as a launcher just isn't being autodetected
  • On AOKP and roms based off of it some of the init.d tweaks you find in rom control startup tweaks will not work anymore as i removed them becuase my script does it for you now. They will be restored if you Un-Smurf
  • Updated HTML doc with latest build.prop edits
  • Changed a few settings in build.prop

V 6.4
  • Fixed launchers not being found
  • Reorganized code
  • Added the google dns servers to the resolv.conf file
  • Added in check for HWA and if there it removes cpu rendering to speed up os
  • Fixed some syntax errors in init.d file
  • Added in a few new build.prop tweaks
  • Added in regroupings of OOM Settings into the build.prop

V 6.3
  • Added Miui Launcher
  • Added Lightning Launcher
  • Changed the way the I/O Schedule List shows up
  • Changed the defraging database process. Should be a lot cleaner now.
  • Added a few extra build.prop tweaks. If you look at them the values are
  • supposed to be blank.

V 6.2
  • Fixed problem with Cron files not copying over correctly

V 6.1
  • Fix syntax error

V 6.0
  • Added checks to make sure no typing error occur
  • Added info on which settings you are using to menu
  • Added more options to the menu that allows you to
  • Change your Launcher
  • Change your LMK Settings
  • Change your I/O Scheduler
  • Changed LMK settings names (Spaceballs Reference now)
  • Added adj actual numbers to LMK settings so user knows the values
  • Added CRON to wipe different cache every hour ever day and every week
  • Script now Auto finds your Launcher(s) and has you select from a list (If
  • yours doesn't show up tell me in this thread and I will add it. I already have over 60 different launchers presearched)
  • Fixed init.d file (some variables wernt getting sent correctly
  • Removed some build.prop edits as to fix 3g and wifi issues
I think that's it. But im sure I missed something

V 5.0
  • Changed delivery of the init.d file
  • Changed the numbering of the init.d file
  • Took away 3g/wifi tweaks that were interfering with wifi connecting and toggles not working
  • Added in checks to remove some conflicting init.d scripts
  • Added in checks for Selection of aggressivness of OOM (adj & minfree) settings
  • Added in an option of what I/O scheduler you want to run
  • Added in a few other build.prop tweaks
  • Cleaned up some code

V 4.7
  • Added OOM levels
  • Added Min free values
  • Added Min KB values
  • Added option to choose from AOSP or SENSE
  • Added Option to Choose from ICS or Gingerbread
  • Lowered the Wifi option to normal levels for connection issues

V 4.6
  • Changed
  • Changed net.tcp.buffersize.default=6144,87380,1048576,6144 ,87380,524288
  • Changed net.tcp.buffersize.wifi=524288,1048576,2097152,524 288,1048576,2097152
  • Changed net.tcp.buffersize.umts=6144,87380,1048576,6144,87 380,524288
  • Changed net.tcp.buffersize.gprs=6144,87380,1048576,6144,87 380,524288
  • Changed net.tcp.buffersize.edge=6144,87380,524288,6144,163 84,262144
  • Changed net.tcp.buffersize.hspa=6144,87380,524288,6144,163 84,262144
  • Changed net.tcp.buffersize.lte=524288,1048576,2097152,5242 88,1048576,2097152
  • Changed net.tcp.buffersize.hsdpa=6144,87380,1048576,6144,8 7380,1048576
  • Changed net.tcp.buffersize.evdo_b=6144,87380,1048576,6144, 87380,1048576
  • Added
  • Govenor Tweaks for Interactive, Ondemand, OndemandX, SmartassV2, Lulzactive, and Conservative
  • Changed kernel.msgmni=64000
  • Cleaned up Code even more

V 4.5
  • Added a few more tweaks to the 01Smurfed file
  • Added a few more build.prop tweaks
  • Hopefully fixed the wifi->3g->wifi issue
  • Cleaned up the code a little

V 4.1
  • Changed picture and video settings...camcorder works now
  • Increased and decreased a few values
  • Added a huge amount to the init.d file
  • Removed the minfree values from the init.d (if you want them back I can release one for Gingerbread and one for ICS)

V 4.0
  • Removed some tweaks that were causing issues
  • Added in some new tweaks
  • Changed a few Settings for better response
  • Script now checks to see if your using a local.prop and if so copies settings to it as well
  • Now script creates a file in you init.d folder called 01smurfed. This has many new tweaks that will run on every boot
  • Comments put into script to explain what exactly is going on
  • Credits given in OP

V 3.3
  • Removed some setting that were either not necessary or we causing issues for some
  • Added in some new tweaks I figured out
  • Fixed 3g not connecting right after turning off WiFi
  • Fixed WiFi not connecting sometimes
  • Script now wipes dalvik-cache and requires a restart. Restart will take a little longer due to rebuild of dalvik
I HIGHLY recommend UN-SMURFING before you apply the newest script. I have noticed huge improvements from this last update

V 3.2
  • Added a few more tweaks
  • Fixed a typo
  • Made sure system was remounted as read/write before settings took place

V 3.1
  • Removed super user check. (Giving errors to some)
  • Fixed my bad spelling (lol)

V 3.0
  • Added 10 new edits
  • Cleaned up code
  • Made sure temp files were being deleted correctly
  • Change a number of setting for better tweaking

V 2.0
  • Huge code change. Now with options.
  • Now scans and removes duplicate lines

V 1.0
  • Initial release
  • Over 30 build.prop edits with more to come.
For a detailed list of settings that this script copies to your Build.prop go to /sdcard/SmurfedBackups/Smurfed_Out.html

!!! WARNING !!!

This Script now interferes with alot of other scripts. I'd recommend unsupercharging and removing some other scripts as well...Tweaks, Read Ahead SD card tweaks, Governor Tweaks, and I'm sure there are a few others. This script searches for some of the scripts mentioned and removers them if found.


During the Smurfing process a copy of all removed files is sent the the SmurfedBackups folder on your SD card. When un-smurfing your phone will be restored back to the exact way before Smurfing.

Future Releases

1. Adds in as many battery saving, speed, and responsiveness tweaks as I can find throught out many different forums.
2. removes any other script that is previously installed that may be using same tweaks....if not removing the script itself it will search out each line of each script and remove the lines individually.


Please leave feedback after you run so others know how well this script works. I will try my best to help with any bugs that are found. If found please report in this thread with the following info
  • What Rom are you running?
  • What Phone are you using?
  • What settings did you choose in Smurfed Out script?
  • What Governor are you running?
  • What kernel are you using?
  • What things did you try before reporting?
  • What issues are you running into?
  • What is your Name and Social Security number? (lol)
  • What is your Blood Type? (LMAO)
  • Have you ever thought about donating an organ? (LMFAO)

Syntax Errors or Suggestions

If reporting syntax errors or suggestions to improve the script then please put them into code brackets so I can easily read them and also line number if you happen to remember helps as the script is over 2500 lines now. I appreciate all help with these errors and suggestions to improve the script.


My WiFi or 3G doesn't work or wont switch?
Go into recovery and wipe dalvik-cache and cache and reboot.
Check to see if data is enabled in your settings.
Check to make sure if your using a battery saver app like battery xl or juice defender that is not turning off your radios

My camcorder isn't working?
Make sure your using the most recent script. The fix was made available on V 4.1

Does this script work for other phones?
Yes in theory it does. Let me know if it works or not and I'll put it in the OP so others know

I can't get this script to run in script manager?
Make sure you are opening the script with superuser rights within script manager

Can I run this in terminal emulator?
yes type this is command line. also make sure that Smurfed Out is on root of your sd card
sh /sdcard/
After running the script and rebooting Im getting a blank black screen?
First scroll down and read just in case and follow those instructions then follow Bug Reporting procedures

My phone got up and ran away from me?
Well this can be a problem....On one hand that would mean that this script really works...on the other hand it means your just not cool enough for you phone anymore and it found someone better.

Just In Case attached is a flashable zip in case of emergency. It has the build.prop of aokp rom in it. If your not running that the zip. open it up. go into the system folder. Replace the build.prop with the build.prop from the that you are running. Put on your sd card. Flash in recovery. I am putting this here cause in the past there were issues with the script causing a freeze after boot and some people had to nand back or reflash their rom. This will fix that. Enjoy.
Attached Files
File Type: zip - [Click for QR Code] (157.6 KB, 1262 views)
The Following 136 Users Say Thank You to Papa Smurf151 For This Useful Post: [ View ] Gift Papa Smurf151 Ad-Free
26th February 2012, 05:07 AM |#4  
gruesomewolf's Avatar
Senior Member
Flag Mocksville, NC
Thanks Meter: 8,531
Donate to Me
Nice idea.....good job.

Sent from my PC36100 using XDA App
26th February 2012, 05:12 AM |#5  
sstory792's Avatar
Senior Member
Flag Minnesota
Thanks Meter: 32
Looking forward to trying this!

Sent from my PC36100 using xda premium
26th February 2012, 05:14 AM |#6  
Notorious's Avatar
Senior Member
Flag Sydney
Thanks Meter: 5,169
Donate to Me

Sent from my PC36100 using XDA App
26th February 2012, 05:29 AM |#7  
Account currently disabled
Flag india
Thanks Meter: 16
Donate to Me
gonna try this now .
26th February 2012, 05:32 AM |#8  
Roman G's Avatar
Senior Member
Flag Oregon
Thanks Meter: 72
Um, where is the file?
26th February 2012, 05:37 AM |#9  
Papa Smurf151's Avatar
OP Senior Member
Flag Atlanta
Thanks Meter: 6,791
Donate to Me
Originally Posted by Roman G

Um, where is the file?

Click on the link that says smurfed out basic
26th February 2012, 05:39 AM |#10  
moreno4xl's Avatar
Senior Member
Flag Brooklyn
Thanks Meter: 39
Donate to Me
Trying new things never gets old... Let's take her for a spin and see what happens, Thanks Bro!
26th February 2012, 05:43 AM |#11  
Papa Smurf151's Avatar
OP Senior Member
Flag Atlanta
Thanks Meter: 6,791
Donate to Me
Originally Posted by moreno4xl

Trying new things never gets old... Let's take her for a spin and see what happens, Thanks Bro!

Feedback is always welcome. As this is the first release I have many other changer that will be taking place in the future on this script nut wanted to release something I had working for now
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes