[MOD] Improve your battery life

Status
Not open for further replies.
Search This thread
Ok now I must explayn you all something simple to stop those there who biching and give the happyness to those who happy with this mod.
For 50% of you this work but for 50% - not. Why?
There is why:
For those who notice batt + the reason is on your kernel , your dev for some reason make your kernels in somehow bad way and when you apply those changes you force your divace work better and you notice + of batt juice. That's it - simple as hell.
For those who not notice +batt it bicoz your devs make kernel for your phone perfect and applyng this not give you +juice . That's it ;)
And for those who notice bad pefr -batt and etc mean this values its high or conflict whit something your dev integrate into your kernel and etc.
In the end that's it ,no need bad feelings ,spams , show us how big engeneer you are , how google must be Boogle or Woogle , trow smartphone to the wall and go to buy Nokia 1100 for montly charge the batt and etc and etc.
Like my mom say :
Change your words change your World ;)

Hawe nice day :)

Sent from my E10i using xda premium
 
  • Like
Reactions: rraaka

Tof37

Senior Member
Oct 6, 2009
624
2,468
Tours
@PureMotive

Thanks for these tweaks ...

Which permissions needs init.d ?

There are set to "set_perm_recursive 0 0 0777 0777" is it good for your script ?


Thanks a lot
 

BarackMitzvah

Senior Member
Nov 20, 2010
722
120
The Moon
thank you so much, im gonna give it a try :)

edit : a few more questions :) after i make the new file in init.d, what command should i type from the terminal to know if the script is running as it should? i'm trying the second option you given me, using only the init.d and i deleted the sysctl.conf. many thanks before

"Sysctl -p" runs it
"Syscyl -a" or "sysctl -a | grep vm" checks it

Sent from my ADR6300 using xda premium
 
  • Like
Reactions: losta

losta

Senior Member
May 4, 2011
275
24
"Sysctl -p" runs it
"Syscyl -a" or "sysctl -a | grep vm" checks it

Sent from my ADR6300 using xda premium

Thanks for your response :) after running those command, here is what i get for the output, is this okay? Thanks in advance

Sent from my GT-I9100 using xda premium
 

Attachments

  • uploadfromtaptalk1336225004937.jpg
    uploadfromtaptalk1336225004937.jpg
    45.6 KB · Views: 443

mohsinraza

Senior Member
Jul 24, 2011
907
353
I'm really sad that I flashed this MOD. it's been over 24 hours I've flashed this and from that time my phone takes 15 minutes to charge 1% battery. The battery drain is very fast. My phone doesn't charge fully even after 6,7 hours plugging the phone in. I've reflashed the rom with full wipe. Changed my kernel. I've done evrything I could do to sort out this problem but I failed...
Please tell me what should I do? My battery keeps on going down even if I do texting while charging the phone. Even when the phone is turned off it takes so much time to charge. HELP...!!!!
I'm writing while the phone is plugged in and it was 7% and now its 5% battery left. Help me asap.. plz.. I need my phone... How to cancel the effect of this zip file?
I've provided you with maximum details. I'm not near my computer for next 20 days. Not even in a wifi zone... Help me... Suggest me something I can do from phone only...

Sent from my HTC Desire
 

cmlusco

Senior Member
Nov 20, 2010
3,244
968
Michigan City, IN
I'm really sad that I flashed this MOD. it's been over 24 hours I've flashed this and from that time my phone takes 15 minutes to charge 1% battery. The battery drain is very fast. My phone doesn't charge fully even after 6,7 hours plugging the phone in. I've reflashed the rom with full wipe. Changed my kernel. I've done evrything I could do to sort out this problem but I failed...
Please tell me what should I do? My battery keeps on going down even if I do texting while charging the phone. Even when the phone is turned off it takes so much time to charge. HELP...!!!!
I'm writing while the phone is plugged in and it was 7% and now its 5% battery left. Help me asap.. plz.. I need my phone... How to cancel the effect of this zip file?
I've provided you with maximum details. I'm not near my computer for next 20 days. Not even in a wifi zone... Help me... Suggest me something I can do from phone only...

Sent from my HTC Desire

If you believe this mod is causing the issue, then go to /system/etc and delete sysctl.conf, then go to /system/etc/init.d, and delete the sysctl file and reboot. Problem should be fixed if its whats causing the issue.
 

tiny4579

Inactive Recognized Developer
Jan 15, 2011
9,327
5,060
I'm really sad that I flashed this MOD. it's been over 24 hours I've flashed this and from that time my phone takes 15 minutes to charge 1% battery. The battery drain is very fast. My phone doesn't charge fully even after 6,7 hours plugging the phone in. I've reflashed the rom with full wipe. Changed my kernel. I've done evrything I could do to sort out this problem but I failed...
Please tell me what should I do? My battery keeps on going down even if I do texting while charging the phone. Even when the phone is turned off it takes so much time to charge. HELP...!!!!
I'm writing while the phone is plugged in and it was 7% and now its 5% battery left. Help me asap.. plz.. I need my phone... How to cancel the effect of this zip file?
I've provided you with maximum details. I'm not near my computer for next 20 days. Not even in a wifi zone... Help me... Suggest me something I can do from phone only...

Sent from my HTC Desire

If you've wiped system and flashed the rom again without the mod, the mod is definitely gone. However, it wouldn't be causing that excessive battery drain anyway. There's no way a file on the phone would affect it when it's off. It sounds to me like a hardware issue somewhere. Try a new charger or battery. Sorry I can't be of much help myself but most of what you say sounds hardware related and nothing to do with the mod.
 

tacosrdelicioso

Senior Member
Mar 23, 2011
1,800
394
So how can I tell if this is running for sure....other than battery
Edit:Got it. Did the terminal thing. I got a bunch of stuff from the file
Sent from my Galaxy Nexus using xda premium
 
Last edited:

prototype7

Senior Member
Apr 16, 2012
4,341
1,141
New Hampshire
Originally Posted by jimbub<br />
"Sysctl -p" runs it<br />
"Syscyl -a" or "sysctl -a | grep vm" checks it<br />
<br />
Sent from my ADR6300 using xda premium
<br />
<br />
Thanks for your response :) after running those command, here is what i get for the output, is this okay? Thanks in advance<br />
<br />
Sent from my GT-I9100 using xda premium
Yep, that looks good.

Sent from my Incredible 2 using Tapatalk 2 Beta-5
 

MidnightDevil

Senior Member
Apr 2, 2012
3,135
1,252
London
Redmi Note 9
Google Pixel 6 Pro
Well.. flashed yesterday using the zip.. I got the same output as losta... so I guess it's running and so far it's fine :)
The first thing I noticed is that takes a while longer to drop the percentage... but on heavy tasks such as using wifi or 3g can't really tell the diference so far... but I think i'm getting something out of this.. will know for sure in a couple of days :)

cheers for the effort.

HTC Desire
 

graymonkey44

Senior Member
Nov 12, 2011
916
412
New York
Well.. flashed yesterday using the zip.. I got the same output as losta... so I guess it's running and so far it's fine :)
The first thing I noticed is that takes a while longer to drop the percentage... but on heavy tasks such as using wifi or 3g can't really tell the diference so far... but I think i'm getting something out of this.. will know for sure in a couple of days :)

cheers for the effort.

HTC Desire
I would like to say that flashing the zip isn't a good idea, because it makes a folder called 10sysctl and every ROM I've flashed this on has 01sysctl; so it creates two different folders, which I think creates an issue. Also, I recommend the one without the semicolons too because I had issues with it on my Incredible.

Thanks for your contributions to the community PureMotive--ignore the haters.
 
  • Like
Reactions: Hero

Hero

Inactive Recognized Developer
Oct 15, 2010
1,397
5,129
Hidden Hills
I would like to say that flashing the zip isn't a good idea, because it makes a folder called 10sysctl and every ROM I've flashed this on has 01sysctl; so it creates two different folders, which I think creates an issue. Also, I recommend the one without the semicolons too because I had issues with it on my Incredible.

Thanks for your contributions to the community PureMotive--ignore the haters.

I'll check the .zip again and correct the issues. Thanks!
 

gecata

Senior Member
Oct 30, 2006
107
61
Lom
fs.file-max= ???

What is the correct value. It is set twice!

fs.file-max=165164 or fs.file-max=65535
 

Hero

Inactive Recognized Developer
Oct 15, 2010
1,397
5,129
Hidden Hills
My galaxy nexus has 1gb so...what value do I change? I just copied it and ran it...idk...maybe better but would compensating for my ram make more battery life?
Anyone?
Sent from my Galaxy Nexus using xda premium

For you, I'd say something around 64000 would be good, so (fs.file-max=65536). This tweak just sets the number of file-handles your kernel will allocate. Increasing the number allows the kernel to allocate more file-handles so you don't see error messages related to something like "extra files can't be opened because the maximum number of open files has been reached" However, a larger number uses more RAM. This is just a performance tweak to compensate for the battery increase that is primarily adjusted with stuff like vfs_cache_pressure, etc
 
  • Like
Reactions: megamanDJ
T

_thalamus

Guest
There is a line in the mod called kernel.panic. What this does is set a value (in seconds) at which the kernel will start panic-ing and reboot the device to free memory. Kernel panic only occurs in OOM (out-of-memory) situations. If the value is set to 0 (kernel.panic=0), then the kernel will NOT panic and will continue with its functions.

Oh dear. The above is from your first post.

And here are the facts:

A kernel panic occurs when something goes horribly wrong within the kernel, which OOM doesn't necessarily cause unless vm.panic_on_oom is set to 1. A kernel panic can be caused by various things.

The kernel.panic tunable sets a timeout for an automatic reboot after a panic. It does *not* stop the kernel from panicking! If the kernel is going to panic, it *will* panic, there is nothing you can do to stop it as it is a last resort when there is an unrecoverable error.

So, with your tweak, if the kernel panics due to a hardware problem or a bug, the device will not reboot automatically and would simply be stuck there, frozen solid until the user pulls the battery. How unbelievably useless that is for a mobile telephone! How on *earth* could that be a performance improvement?

Also, seeing as you mention OOM, it happens that OOM is highly unlikely to be invoked on Android as Android has it's own low memory killer driver which kicks in to manage memory usage long before the OOM killer does. I have never seen OOM invoked on Android. OOM is like using a sledgehammer to crack a nut, which is why the Android team wrote their own, more finely grained implementation.

Seriously though, a bit of advice, learn about the tweaks you are doing, the advantages and drawbacks and if it is actually any use at all preferably *before* making yourself 'popular' by releasing it on XDA with a bold claim in the title, otherwise someone like me, *will* come along and debunk the myth that it does anything useful...

I've said my piece now and I won't reply again, because it's become old rather quickly and further replies on my part would be foolish and counter productive, as this one probably is, but what the hell.

The users can make the choice between taking the advice of someone who knows about kernels and maintains several, or someone who has put a bunch of tweaks together in a script and doesn't understand most of them.

Good evening.
 

tacosrdelicioso

Senior Member
Mar 23, 2011
1,800
394
Oh dear. The above is from your first post.

And here are the facts:

A kernel panic occurs when something goes horribly wrong within the kernel, which OOM doesn't necessarily cause unless vm.panic_on_oom is set to 1. A kernel panic can be caused by various things.

The kernel.panic tunable sets a timeout for an automatic reboot after a panic. It does *not* stop the kernel from panicking! If the kernel is going to panic, it *will* panic, there is nothing you can do to stop it as it is a last resort when there is an unrecoverable error.

So, with your tweak, if the kernel panics due to a hardware problem or a bug, the device will not reboot automatically and would simply be stuck there, frozen solid until the user pulls the battery. How unbelievably useless that is for a mobile telephone! How on *earth* could that be a performance improvement?

Also, seeing as you mention OOM, it happens that OOM is highly unlikely to be invoked on Android as Android has it's own low memory killer driver which kicks in to manage memory usage long before the OOM killer does. I have never seen OOM invoked on Android. OOM is like using a sledgehammer to crack a nut, which is why the Android team wrote their own, more finely grained implementation.

Seriously though, a bit of advice, learn about the tweaks you are doing, the advantages and drawbacks and if it is actually any use at all preferably *before* making yourself 'popular' by releasing it on XDA with a bold claim in the title, otherwise someone like me, *will* come along and debunk the myth that it does anything useful...

I've said my piece now and I won't reply again, because it's become old rather quickly and further replies on my part would be foolish and counter productive, as this one probably is, but what the hell.

The users can make the choice between taking the advice of someone who knows about kernels and maintains several, or someone who has put a bunch of tweaks together in a script and doesn't understand most of them.

Good evening.

Hey uh that's nice. But nobody really cares sorry. This tweak gets results for lots of folks...stop flaming the dev who still should get a lot of credit....wow...a$$h***

Sent from my Galaxy Nexus using xda premium
 

s197

Senior Member
Jun 28, 2010
1,074
177
Hey uh that's nice. But nobody really cares sorry. This tweak gets results for lots of folks...stop flaming the dev who still should get a lot of credit....wow...a$$h***

Sent from my Galaxy Nexus using xda premium

I don't see it as flaming, he's refuting his claims with well reasoned arguments. Not everyone wishes to follow like blind sheep, I for one am glad to hear an opposing argument when it is well presented as his.
 
  • Like
Reactions: maatsby and azrash
Status
Not open for further replies.

Top Liked Posts

  • There are no posts matching your filters.
  • 99
    25152816.png
    Before we get to the mod, I want to get a little personal. I make these mods so that your Android experience will be enhanced. If you find something wrong with the mod then provide constructive criticism. Don't just sit there behind your computer and degrade the effects based on what you see in the code, especially if you are even unwilling to try the mod in the first place. That irritates the hell out of me and unfortunately, I can't help you with your issues...so do yourself and others a favor and either use the mod and provide constructive criticism such as results (positive or negative) or ways to improve it or don't use it at all. That being said, these tweaks work in conjunction with each other, they are not each meant to increase your battery life.​


    This is my mod for achieving good-great battery life. This is the mod I use in Anthem™ which has given me 50+ hours on a single charge. The increase in battery life may not be "tenfold" for you, but it does increase, which is still better than not increasing. Contact me before including it in your own ROM (that you plan on publicly releasing). I will allow you to use it, just ask first. Please give credit or thanks or both ;)

    First: Here is a flashable .zip of the mod that may or may not work with your ROM. I'd still advise doing it manually.

    Sysctl.conf - Updated May 3, 2012​
    Requirements:
    • HTC Incredible (preferably)
    • Kernel with zram swap (for swappiness)
    • Kernel with init.d support

    Currently working on:

    • HTC Incredible - Anthem, Clutch, AOKP, ICSenseless
    • HTC Amaze 4G

    Step 1

    Open up your ROM.zip (or whatever it's called) in 7zip (Windows) or Betterzip (OSX) and locate

    sysctl.conf in /system/etc

    If it's not in this directory, create it.

    Step 2

    In your sysctl.conf file, paste the following code and save it.

    Code:
    #sysctl.conf file
    fs.nr_open=1053696;
    fs.inotify.max_queued_events=32000;
    fs.inotify.max_user_instances=256;
    fs.inotify.max_user_watches=10240;
    fs.lease-break-time=10;
    fs.file-max=165164;
    kernel.threads-max=525810;
    kernel.random.write_wakeup_threshold=256;
    kernel.random.read_wakeup_threshold=128;
    kernel.sched_compat_yield=1;
    kernel.panic=5;
    kernel.panic_on_oops=1;
    kernel.msgmni=2048;
    kernel.msgmax=64000;
    kernel.shmmni=4096;
    kernel.shmall=2097152;
    kernel.shmmax=268435456;
    kernel.sem=500 512000 64 2048;
    kernel.sched_features=24189;
    kernel.hung_task_timeout_secs=30;
    kernel.sched_latency_ns=18000000;
    kernel.sched_min_granularity_ns=1500000;
    kernel.sched_wakeup_granularity_ns=3000000;
    kernel.sched_shares_ratelimit=256000;
    kernel.sched_child_runs_first=0;
    fs.lease-break-time=10;
    fs.file-max=65536;
    vm.dirty_ratio=90;
    vm.dirty_background_ratio=80;
    vm.oom_kill_allocating_task=1;
    vm.overcommit_memory=1;
    vm.page-cluster=3;
    vm.drop_caches=3;
    vm.min_free_kbytes=4096;
    vm.panic_on_oom=0;
    vm.dirty_expire_centisecs=1000;
    vm.dirty_writeback_centisecs=2000;
    vm.oom_kill_allocating_task=0;
    vm.vfs_cache_pressure=10;
    vm.min_free_order_shift=4;
    vm.laptop_mode=0;
    vm.block_dump=0;

    If the above code does not work for you, try this one. It has the semi-colons removed. Thanks Tiny

    Code:
    #sysctl.conf file
    fs.nr_open=1053696
    fs.inotify.max_queued_events=32000
    fs.inotify.max_user_instances=256
    fs.inotify.max_user_watches=10240
    fs.lease-break-time=10
    fs.file-max=165164
    kernel.threads-max=525810
    kernel.random.write_wakeup_threshold=256
    kernel.random.read_wakeup_threshold=128
    kernel.sched_compat_yield=1
    kernel.panic=5
    kernel.panic_on_oops=1
    kernel.msgmni=2048
    kernel.msgmax=64000
    kernel.shmmni=4096
    kernel.shmall=2097152
    kernel.shmmax=268435456
    kernel.sem=500 512000 64 2048
    kernel.sched_features=24189
    kernel.hung_task_timeout_secs=30
    kernel.sched_latency_ns=18000000
    kernel.sched_min_granularity_ns=1500000
    kernel.sched_wakeup_granularity_ns=3000000
    kernel.sched_shares_ratelimit=256000
    kernel.sched_child_runs_first=0
    fs.lease-break-time=10
    fs.file-max=65536
    vm.dirty_ratio=90
    vm.dirty_background_ratio=80
    vm.oom_kill_allocating_task=1
    vm.overcommit_memory=1
    vm.page-cluster=3
    vm.drop_caches=3
    vm.min_free_kbytes=4096
    vm.panic_on_oom=0
    vm.dirty_expire_centisecs=1000
    vm.dirty_writeback_centisecs=2000
    vm.oom_kill_allocating_task=0
    vm.vfs_cache_pressure=10
    vm.min_free_order_shift=4
    vm.laptop_mode=0
    vm.block_dump=0

    Step 3

    Now we need to enable it. So, navigate to /system/etc/init.d and create a file with the following code:

    Code:
    #!/system/bin/sh
    # grep sysctl /etc/init.d/*
    # Load /sys/etc/sysctl.conf
    sysctl -p

    sysctl -p is what initializes the code.

    Just FYI: You don't actually need these lines:

    Code:
    # grep sysctl /etc/init.d/*
    Code:
    # Load /sys/etc/sysctl.conf

    So this would have just sufficed.

    Code:
    #!/system/bin/sh
    sysctl -p

    If the above code does not work for any reason, try this:

    Code:
    #!/system/bin/sh
    sysctl -p /system/etc/

    Name your file something like this 10sysctl

    Save your file.

    NOTE: Your ROM must support init.d. You can do this by using dsixda's android kitchen

    Step 4

    Save your ROM and install it via recovery

    OR

    you could just push the files into your current ROM and try them out.

    forknowledge.png


    Credits to imoseyon for portions of the info

    Ok, so what exactly is sysctl.conf?

    The sysctl.conf is a configuration file for "sysctl" which is an interface for dynamically changing kernel parameters in the Linux OS. The configuration file contains the following elements, vm.min_free_kbytes, vm.dirty_ratio, vm.dirty_backgroud_ratio, vm.vfs_cache_pressure, vm.oom_kill_allocating_task. There are many other elements within the file, but we will be primarily focusing on these specifically (the vm prefix stands for virtual memory). The sysctl.conf file should be located in /etc (/system/etc) by default. To enable it you need your ROM to execute "sysctl -p" somewhere during the boot process (or shortly afterward). We will also be discussing how to enable it if it is not already done so. You can also run sysctl -p manually to enable it any time after the OS is started.

    Now, let’s get down to what sysctl.conf does and how it works.

    min free kbytes (vm.min_free_kbytes)
    This is used to force the Linux VM to keep a minimum number of kilobytes free. The VM uses this number to compute a pages_min value for each lowmem zone in the system. Each lowmem zone gets a number of reserved free pages based proportionally on its size. Default is 2048kb.

    dirty ratio (vm.dirty_ratio) and dirty background ratio (vm.dirty_background_ratio)
    This controls how often the kernel writes data to "disk" (in our case the internal microSD system card, not the removable microSD card). When your apps write data to disk, Linux actually doesn't write the data out to the disk right away, it actually writes the stuff to system memory and the kernel handles when and how the data is actually going to be flushed to the disk. These values represent a percentage, the higher the percentage, the longer it waits to flush, the lower the percentage, the more often flushes will occur. Now remember, we are dealing with solid state storage, not the traditional disk platter and spindle. So we are actually able to delay flushes a little longer with solid state versus a traditional hard drive disk.

    VFS Cache Pressure (vm.vfs_cache_pressure)
    Now here is where it gets interesting! File system cache (dentry/inode) is really more important than the block cache above in dirty ratio and dirty background ratio, so we really want the kernel to use up much more of the RAM for file system cache, this will increas the performance of the system without sacrificing performance at the application level. The default value is 100, as a percentage, and what you want to do is lower the value to tell the kernel to favor the file system cache and not drop them aggressively.

    oom allocating task (vm.oom_kill_allocating_task)(enable or disable, generally in Linux this value is either a "1" or a "0," representing as on or off.)
    This enables or disables killing the OOM-triggering task in out-of-memory (oom) situations. If this is set to zero, or disabled, the OOM killer will scan through the entire task list and select a task based on heuristics to kill. This normally selects a rogue memory-hogging task that frees up a large amount of memory when killed. If this is set to non-zero, or enabled, the OOM killer simply kills the task that triggered the out-of-memory condition. This avoids the expensive task list scan, which can take mass amounts of time and "hang" or freeze the system.

    block_dump (vm.block_dump)
    This enables block I/O debugging when set to a nonzero value. If you want to find out which process caused the disk to spin up (see /proc/sys/vm/laptop_mode), you can gather information by setting the flag.

    When this flag is set, Linux reports all disk read and write operations that take place, and all block dirtyings done to files. This makes it possible to debug why a disk needs to spin up, and to increase battery life even more. The output of block_dump is written to the kernel output, and it can be retrieved using "dmesg". When you use block_dump and your kernel logging level also includes kernel debugging messages, you probably want to turn off klogd, otherwise the output of block_dump will be logged, causing disk activity that is not normally there.

    overcommit_memory (vm.overcommit_memory)
    This controls overcommit of system memory, possibly allowing processes to allocate (but not use) more memory than is actually available.

    0 - Heuristic overcommit handling. Obvious overcommits of address space are refused. Used for a typical system. It ensures a seriously wild allocation fails while allowing overcommit to reduce swap usage. root is allowed to allocate slighly more memory in this mode. This is the default.
    1 - Always overcommit. Appropriate for some scientific applications.
    2 - Don't overcommit. The total address space commit for the system is not permitted to exceed swap plus a configurable percentage (default is 50) of physical RAM. Depending on the percentage you use, in most situations this means a process will not be killed while attempting to use already-allocated memory but will receive errors on memory allocation as appropriate.

    page-cluster (vm.page-cluster)
    This controls the number of pages which are written to swap in a single attempt. The swap I/O size.

    It is a logarithmic value - setting it to zero means "1 page", setting it to 1 means "2 pages", setting it to 2 means "4 pages", etc.

    The default value is three (eight pages at a time). There may be some small benefits in tuning this to a different value if your workload is swap-intensive.

    panic_on_oom (vm.panic_on_oom)
    This enables or disables panic on out-of-memory feature. If this is set to 1, the kernel panics when out-of-memory happens. If this is set to 0, the kernel will kill some rogue process, by calling oom_kill().

    Usually, oom_killer can kill rogue processes and system will survive. If you want to panic the system rather than killing rogue processes, set this to 1.

    The default value is 0.

    Panic is a system error that is detected by the kernel.

    dirty_expire_centisecs (vm.dirty_expire_centisecs)
    How old "dirty" data should be before the kernel considers it old enough to be written to disk. It is expressed in 100ths of a second.

    dirty_writeback_centisecs (vm.dirty_writeback_centisecs)
    This is the interval of when the writeback daemons periodically wake up and write "old" data out to disk. It is expressed in 100ths of a second.
    5
    Oh dear. The above is from your first post.

    And here are the facts:

    A kernel panic occurs when something goes horribly wrong within the kernel, which OOM doesn't necessarily cause unless vm.panic_on_oom is set to 1. A kernel panic can be caused by various things.

    The kernel.panic tunable sets a timeout for an automatic reboot after a panic. It does *not* stop the kernel from panicking! If the kernel is going to panic, it *will* panic, there is nothing you can do to stop it as it is a last resort when there is an unrecoverable error.

    So, with your tweak, if the kernel panics due to a hardware problem or a bug, the device will not reboot automatically and would simply be stuck there, frozen solid until the user pulls the battery. How unbelievably useless that is for a mobile telephone! How on *earth* could that be a performance improvement?

    Also, seeing as you mention OOM, it happens that OOM is highly unlikely to be invoked on Android as Android has it's own low memory killer driver which kicks in to manage memory usage long before the OOM killer does. I have never seen OOM invoked on Android. OOM is like using a sledgehammer to crack a nut, which is why the Android team wrote their own, more finely grained implementation.

    Seriously though, a bit of advice, learn about the tweaks you are doing, the advantages and drawbacks and if it is actually any use at all preferably *before* making yourself 'popular' by releasing it on XDA with a bold claim in the title, otherwise someone like me, *will* come along and debunk the myth that it does anything useful...

    I've said my piece now and I won't reply again, because it's become old rather quickly and further replies on my part would be foolish and counter productive, as this one probably is, but what the hell.

    The users can make the choice between taking the advice of someone who knows about kernels and maintains several, or someone who has put a bunch of tweaks together in a script and doesn't understand most of them.

    Good evening.

    Hey uh that's nice. But nobody really cares sorry. This tweak gets results for lots of folks...stop flaming the dev who still should get a lot of credit....wow...a$$h***

    Sent from my Galaxy Nexus using xda premium
    4
    i created a flashable zip of everything except the net.* tweaks as that was causing problems for me.

    download is here: http://www.mediafire.com/?j3gdgdcawj9imcq

    havent tested it yet and its not guaranteed to install on every phone as there are different mount points for /system
    4
    It can't.

    There is nothing in there which would increase battery life. You are about as likely to increase battery life by stroking your phone and making a wish. :rolleyes:

    XDA still doesn't disappoint me with it's random placebo posts. :D

    Why don't you try it first before posting?

    This line in particular "vm.vfs_cache_pressure=10" is important because we want the kernel to favor retaining the file system cache as opposed to trying to reclaim it. In essence, a low vfs_cache_pressure slows things down, saving battery life. This works in conjunction with your ROM's swappiness level (which should be 1,0, or close to 0) so that the Linux kernel no longer attempts to enlarge the cache by paging applications out (keeping the system fast).

    Sent from my Incredible using Tapatalk
    3
    I used the zip posted on page 12 by kevdliu. I am running an Evervolv ICS 4.0.4 with tiamat kernel and here is what I have found after the third day of use.

    Normally after 18 hours of light use I would be down around 20% and be ready for a charge. I just picked up my phone now to check the battery and at 20 hours still at 62% after the same amount of use. So standby time definitely uses less juice in my experience.

    Watching videos and heavy screen usages for example games, still blows though battery but is noticeably better. Probably wouldn't make it all day for heavy users.

    Every night I walk for about two hours and stream music over slacker radio to a bluetooth headset. (no use of the display mind you) Normally this takes almost 50% of my battery. last night 8%.... holy crap yes only 8%

    Thanks for everyone who put effort into this!

    I updated the OP with a new .zip that might have the same effects as the one posted on page 12. Dunno for sure, but if anyone wants to try it out, let me know how it works :)