Related
Attention!
If you're looking for scripts, here it is:
[CWM][SCRIPTS][TWEAKS] Thunderbolt!
Script Reviews are here:
Script Reviews
Introduction
I've been meaning to share this with the whole Android community. It seems unfair that only the i9000 folks have access to the vast research that I've done so far. Hence I'm sharing this in the general Android thread in hopes that it'll benefit everyone in the long run
A lot of people often asked about how Android really works and the optimizations can be made to their Android to make it perform better in terms of:
- battery life
- raw performance
- GUI smoothness
With Android based on Linux, and with the experience I have with Linux/Unix (I deal with Unix/Linux on a daily basis for my work) I managed to find some tweaks that we can do to optimize our phones.
I also hope that people will experiment with the tweaks posted here and feedback to me if there are certain ways that I'm doing incorrectly or there are better ways than what I've posted here.
Script tweaks
There are a lot of scripts in XDA that specifically uses the optimizations (Linux or Android based) that I will explain below to actually increase performance/battery life. However, you need to know what those scripts do before using it.
I've done some reviews of the script here:
Script Reviews by Pikachu01
There are good scripts that are properly tested and made sure that it works. It's a script by Zacharias maladroit, the kernel dev who makes the platypus kernel for CM7 and snail kernel for i9000. I modded it to be compatible with i9000 and it'll probably do more than some of the scripts I reviewed
From there, I've also taken the liberty of modifying it some more based on my knowledge and research I've done. It's called ThunderBolt!:
LINK
Now onwards to what actually goes on beneath the hood.
Android Governors
Some custom kernels provide customized governors for you to choose. These are currently known:
- Ondemand (CPU scales to the highest frequency immediately after a certain CPU threshold)
- Conservative (CPU scales to the highest or 1 scale lower than that after a certain threshold gradually and scales down if CPU is below a certain threshold
- OndemandX (Has sleep codes that scales down the CPU when device is asleep. Threshold is set to scale slower)
OndemandX
OndemandX has a suspend frequency that it maintains when the phone is sleeping. It does have a known issue of waking up too slowly when a call comes in.
Conservative
Conservative is used when you would like the CPU to scale to the maximum through each frequency slowly before reaching the maximum. It saves more battery at the expense of smoothness. There are a few tunables that can be configured in Conservative governor, namely the freq_step and both the up and down thresholds.
freq_step is a tunable that determines how much frequency (a percentage of the maximum frequency of your device) to increase at each sampling rate. e.g. you have 5 as freq_step and your maximum frequency is 1GHz. At each sampling rate, it'll increase by 50MHz. If your current frequency is 100MHz, it'll increase to 150MHz at the next sampling. What if your device doesn't support 150MHz? This is done by splitting time between 100MHz and 200MHz (assuming your next frequency is 200MHz) so that in average, your phone is performing at 150MHz.
The up_threshold is how much threshold to wait for before increasing the base frequency to the next freq_step. I.e. if it is 80, the CPU will wait until it is 80% loaded before increasing the frequency. The down threshold is the opposite of up_threshold, which is the threshold to wait until the CPU downscales the frequency to the next frequency step.
Ondemand
Ondemand is a governor that basically a simpler version of conservative. One difference is that it scales to the maximum frequency after load has exceeded a threshold. This is usually 80. After that, it looks at the load again when it's at the max frequency. If it's below 80 (example), it'll scale down one frequency step. The frequency step mentioned here is the available frequency step. I.e. if your device has frequencies of 100,200,400,800 to 1GHz then it'll scale down from 1GHZ to 800, 400 then 200 and 100.
One optimization I have for Ondemand for i9000 TalonDev is that I tuned it to be 80 rather than 65. I have not felt any slowdowns from using this setting and it saves a tiny bit more battery. You can experiment on this value however you want, but bear in mind that I'm not responsible for any slowdowns or damage that is caused by it. Read up a bit more on thresholds to know more (Google it).
I/O scheduler tweaks
Another tweak that can be done is the I/O scheduler tweak. Some kernels come with a few standard I/O schedulers while others have extra schedulers that you can choose from. I'll explain the few that I know and if you have more information on the schedulers, you can post it here for everyone to discuss/share
CFQ - Completely fair. Most will come with this, but this is not optimized for android. Some kernels do optimize it and use it.
Noop - Simple and least overhead of all I/O schedulers. Produces the best outcome for some cases and some do swear by it. It's downside is that it is easily bogged down by high I/O transactions.
Deadline - Optimized for mobile-like devices like Android. Also, some do swear by this. If its writes_starve sysfs is tweaked to be fair, it's the same as SIO.
SIO - It's a fair deadline scheduler. It's the best scheduler. Nuff said.
VR - A newer I/O scheduler that places penalty on reverse seeks. Not for flash drives, though the R penalty can be tweaked to be a multiplier of 1. Even if this is done, it has a high overhead.. Read more here: http://www.gelato.unsw.edu.au/IA64wiki/IOScheduling/VRscheduler
BFQ - Too high of an overhead, it is optimized for spindle disks.
You can pick and choose from Voltage Control or other UV/OC apps and apply it immediately to feel the difference.
Here's my assessment of all the schedulers that I know:
SIO> NOOP> Deadline > VR > BFQ > CFQ
NOOP is a simple I/O scheduler without overhead that tries to do each I/O transaction as it comes (FIFO). When a group of transactions is detected, it will try to merge it together to make batches of transactions (makes the whole transaction faster). NOOP doesn't have starvation detection, hence if an I/O transaction takes a painfully long amount of time, it will still continue to do it rather than switch the CPU into doing something else e.g. GUI interrupts (i.e. scrolling lists, flicking screens). All other schedulers also have the "merge" feature. NOOP is the only one that makes the "merge" feature its only feature.
CFQ is a complex I/O scheduler that tries to determine the address space of the transaction and applies a cost algorithm in that if the address is close together, it will group them up and perform them. It also tries to make the transaction incremental (i.e. reading/writing through address incrementally so that the disk spindle needs to wind down the least in conventional platter hard disks) The problem is, our flash devices have very little delta between reading a far reaching address space (than the one currently being written/read) or a closer one as it doesn't rely on spindle/rotations. Hence, having this costing algorithm adds overhead and slows down the overall transaction. CFQ has a lot of algorithms to make sure each process gets a fair slice of time on I/O transcations. Too much overhead.
Deadline has a starvation detector and is simple enough that it doesn't have all the overhead of doing rotational/costing disks algorithm. However, reads are done 2x more likely than writes as it has a algorithm based on weights in that reads must be done first if both a read and a write is detected. It has a 2:1 ratio of read to write weights coded into the scheduler (that can be tweaked - writes_starved, will include it in the next version of system_tweak). Hence it's not a fair scheduler.
SIO is Simple I/O that tries to implement a NOOP type scheduler that has starvation detection. Hence, long I/O transactions will be preempted and given CPU time only after other faster transactions are completed, guaranteeing smoothness. Also, it doesn't have overhead of calculating costs. Also, it has a fair number of writes to read, guaranteeing that all transactions are equal.
BFQ has a lot of algorithms to make sure each process gets a fair slice of bandwidth (Budget Fair Queueing). Too much overhead.
V(R) tries to make sure that each transaction has a weight associated with it, being R. And if the seek is reversed, the R will be multiplied by a penalty making it less likely to be processed. Not for flash drives as reverse seek in a flash drive is just as fast as a forward seek.
In benchmarking tests, the tests normally consists of testing the time it takes for a contiguous I/O transfer from 1 point to another. NOOP excels at that because it won't let itself get interrupted to perform another I/O task. This would mean that in real life testing, NOOP will let a long arduous task to finish while at the expense of UI functionality (you will get UI lags)
SIO on the other hand will perform badly at benchmarking as it gets pre-empted when the contiguous tasks takes more than 0.5secs (for synchronous tasks as benchmarking tools perform a synchronous I/O task from one point to another) to another more important task like UI interrupt (when you're scrolling) or Kernel interrupt (when your kernel needs to perform garbage collecting or swap memory etc)
The 0.5 secs can be tuned in the SIO tuneables though, but I would think 0.5 secs for synchronous tasks and 5 secs for async tasks is pretty good to maintain a balance between long/short tasks enabling a smoother experience in Android.
LowMemoryKiller
The LowMemoryKiller is a constant debate between more free RAM and more multitasking capabilities as free RAM (more than 60MB free) is actually wasted RAM. The fact is SGS only has a puny amount of RAM left after a few big chunks are allocated to the Graphics, Modem, Sound and Video (and some others that I do not know a lot about). With that knowledge, Samsung decided to give the SGS SL a bigger amount of RAM when they released it ( about ~650MB of RAM read that from somewhere, can't remember).
The LowMemoryKiller is actually a feature in the Android OS for better memory management.
You can read about it more here:
http://forum.xda-developers.com/showpost.php?p=5442369&postcount=1
This is an important feature due to the perennial problem of having low free memory causing lagginess and slowness in launching apps. When you have free memory lingering around the number of 40MB or less, the Android OS just lags like hell.
What this would mean is, you would want to tweak the LMK to not have the situation of it having less than 40MB (or even close to that).
The modern Linux machine in the Android ecosystem relies on a mechanism called Low Memory Killer (LMK) to consistently free up RAM. This is due to Android's internal mechanism of caching apps (and never fully exiting them) when you press the back button. This is to enable faster app switching and provide a seamless experience for apps usage model. Android also, by itself will also constantly look for often used apps to cache them for faster app opening. This will happen even before your system fully boots.
Now, when you mention LMK, the most obvious thoughts that come up are minfrees and Out Of Memory (OOM) groupings. Yes, those two are integral parts when it comes to LMK. The issue here is that no one actually mentioned that there are two LMK systems in Android, that being:
- Linux LMK
- Android Dalvik VM LMK
Both are separate entities that kills/removes app/dalvik cache from RAM when RAM reaches a certain level.
What confuses most people (including me) is that the OOM groupings of both mechanisms have the same names being (Android 2.3 based):
LMK App Categories
FOREGROUND_APP: Your apps in the foreground, being used currently, interfacing with the user.
VISIBLE_APP: Visible app that is still viewable by the user, but not interacting with the user, example could be apps that reside in the status bar, and giving live information i.e. Os monitor graphs.
PERCEPTIBLE_APP: App that the user can still perceive i.e. Music app that is playing music.
HEAVY_WEIGHT_APP: RAM heavy apps that are not being interacted with, but will be a pain to load if its information is cleared in the memory.
SECONDARY_SERVER: App that acts as a secondary server. Not sure what this really means, but client-server thingy but secondary? Could be something that syncs with an app, but is not syncing currently?
BACKUP_APP: App that is currently making a backup (like Titanium backup?)
HOME_APP: Your launcher.
HIDDEN_APP: An exited app that still significant residual memory in the RAM. Exited only some time ago, or is constantly used by the user.
EMPTY_APP: An exited app that only has small remnants of residual memory in RAM. App that is exited quite some time ago.
Take note that this is my understanding of the OOM groupings. If there are mistakes, please correct me
Tuning LMK
Both the LMK and Dalvik VM has this groupings and they can be tunable by using prop and lowmemorykiller/parameters/adj respectively.
One errata about this is that the Dalvik LMK has one extra tunable which is CONTENT_PROVIDER, which affects widgets that are not currently refreshing or displaying information. The ADJ (which I will explain later) is not available to be tuned though. And it is clearly missing from the Linux LMK.
The ADJ is the so-called priority of the app categories, with 0 being the highest (should not be killed) and 15 being the lowest (should be the first to be killed). I haven't seen values other than 0-15 but I have a feeling that the numbers are arbitrary, and can be extended up to 65535, but who would want to do that since they're only 9 app categories
LMK are specified by pages, with memory = 4 * pages.
e.g.
4096 pages represents 16MB RAM (16 *1.024)
From the Linux LMK source code, the parameters can be adjusted as such:
Code:
* For example, write "0,8" to /sys/module/lowmemorykiller/parameters/adj and
* "1024,4096" to /sys/module/lowmemorykiller/parameters/minfree to kill processes
* with a oom_adj value of 8 or higher when the free memory drops below 4096 pages
* and kill processes with a oom_adj value of 0 or higher when the free memory
* drops below 1024 pages.
Take note that the oom_adj so far takes only 6 values (although I am confident that it can take more than that). Haven't experimented enough to validate that, but I shouldn't need to as assigning different oom_adj should be a given for all the app categories. This is to make the LMK intelligent enough to determine which app to kill first rather than grouping different app categories into one priority, in which a lot of popular LMK settings that devs provide do that.
And for the Dalvik LMK, my understanding is that it will remove all dalvik caches of <INSERT_APP_CATEGORY_ADJ> or higher if free RAM/pages reaches the level specified.
Hence, two things are learned here:
- Linux LMK will kill an app category of that particular RAM level or higher if free RAM drops below a certain level e.g.
Hidden_APP has a minfree of 16384 pages. If pages fall below this level, Empty_App will be killed first, free pages is recalculated, then if RAM is still below that, Hidden_Apps will be killed next.
- Dalvik LMK will clear all dalvik caches in RAM of all the App category if free RAM reaches the level e.g.
SECONDARY_SERVER_MEM is 8192 pages. When RAM reaches 8192 pages, all SECONDARY_SERVER caches are cleared.
Best Practices
Now, how do we tweak both so that it is efficient in doing its job, i.e. LMK.
From my experiments I can safely say that:
- Below 60MB free RAM you will feel lag 5-10% of the time.
- Below 52MB free RAM you will feel lag 5-15% of the time.
- Below 46MB free RAM you will feel lag 15-20% of the time.
- Below 42MB free RAM you will feel lag 20-50% of the time.
- Below 36MB free RAM you will feel lag 100% of the time.
The experience of lag increases exponentially from 60 down to 36MB. Hence, the LMK should be tweaked against that.
Also, it is considered best practices to group oom_adj settings of Linux LMK with the Dalvik LMK as when free RAM drops to that level, both the Linux LMK and Dalvik LMK will work together to free up at both sides.
The 6 oom_adj that can be tuned for Linux minfree also need to be tuned correctly, failing this would make the LMK too aggressive/under aggressive in mid levels (even if your EMPTY_APP is aggressive, if your oom_adj is selected incorrectly, you'll get to a point where memory leak occurs).
Talon LMK - This is obsolete, TalonDev is using ThunderBolt! LMK from 0.5.x
Take for example, the Talon default LMK setting where:
LMK_ADJ is 0,1,2,3,7,15.
It's EMPTY_APP is 15
It's HIDDEN_APP is 5
It's HEAVYWEIGHT, SECONDARY and BACKUP is 3
Last three values of MINFREE is 4096, 9216, 12288.
Where's the issue here? If you noticed it congrats.
If you didn't, here's the issue:
The minfree 12288 is tied to EMPTY_APP which has a OOM_ADJ of 15.
The minfree 9216 is tied to nothing but has a OOM_ADJ of 7
The minfree 4096 is tied to HEAVYWEIGHT,SECONDARY and BACKUP with the OOM_ADJ of 3.
The LMK_ADJ is important as it represents the checkpoints where the Linux kernel will check for minfrees and kill them. Here's a situation:
Memory is below 12288 pages, OOM is triggered and Linux looks for EMPTY_APP to kill and kills all of them. Job done. Memory is back to >12288 pages.
After a few days, memory is below 12288 pages again, OOM kills all EMPTY_APP, but free memory is still lower than that. It sees if the next checkpoint is fulfilled, which is 9216 pages, and yes memory is still below 9216 pages. It looks for an OOM_ADJ of 7 and above to kill, but fails to find any as 7 and above OOM_ADJ only consists of EMPTY_APP.
Here comes the quandary. The next checkpoint is 4096. We're not ever going to reach that as you'll need memory to fall below 16MB, and at that time it'll be super sluggish to even support GUI. Hence BAM, memory leak or lag or something.
Supercharger LMK 512HP - Multitasking
Let me just paste this to avoid a lot of retyping
Code:
FOREGROUND_APP_ADJ=0
VISIBLE_APP_ADJ=4
PERCEPTIBLE_APP_ADJ=2
HEAVY_WEIGHT_APP_ADJ=5
SECONDARY_SERVER_ADJ=6
BACKUP_APP_ADJ=7
HOME_APP_ADJ=1
HIDDEN_APP_MIN_ADJ=8
EMPTY_APP_ADJ=15
FOREGROUND_APP_MEM=1536
VISIBLE_APP_MEM=3072
PERCEPTIBLE_APP_MEM=1024
HEAVY_WEIGHT_APP_MEM=10240
SECONDARY_SERVER_MEM=10240
BACKUP_APP_MEM=15360
HOME_APP_MEM=1024
HIDDEN_APP_MEM=15360
EMPTY_APP_MEM=25600
LMK_ADJ="0,4,6,8,14,15"
LMK_MINFREE="1536,3072,10240,15360,20480,25600"
A few things here:
It's EMPTY_APP and HIDDEN_APP is too large, 80 and 100MB respectively, but the 80MB is a false flag hence it doesn't really matter if you tweak that and you can get a very minor degree of multitasking because of this false flag. I'll get to that in a moment.
It's PERCEPTIBLE_APP has higher OOM_ADJ than VISIBLE_APP (odd selection, but RAM rarely goes below 40MB before it starts lagging like hell) People would reboot their phones when it gets to that, but it rarely gets to that for this configuration as LMK is pretty aggressive here.
Now, it's LMK_ADJ is "0,4,6,8,14,15"
15 is EMPTY_APP,
14 is nothing
8 is HIDDEN_APP - it looks like it'll only kill HIDDEN_APPs when it reaches 60MB, with HIDDEN_APPs being the heavy hitter of apps as most apps will end up in this category. Hence why multitasking is still doable (to an extent) but an aggressive LMK means taking a call or switching to a browser will kill your game (losing saves). Inconvenient, but it works for some people who haven't played a long game without saving and never took a call in between. Imagine the horror LOL!
Juwe's RAM Script
Code:
if [ -e /sys/module/lowmemorykiller/parameters/adj ]; then
echo "0,1,2,4,6,15" > /sys/module/lowmemorykiller/parameters/adj
fi
if [ -e /sys/module/lowmemorykiller/parameters/minfree ]; then
echo "2560,4096,5632,10240,11776,14848" > /sys/module/lowmemorykiller/parameters/minfree
fi
No OOM_ADJ are given, hence the stock ones are in effect here.
From init.rc, this is the stock 2.3.5 OOM_ADJ.
FOREGROUND 0
VISIBLE, PERCEPTIBLE 1
HEAVY_WEIGHT, SECONDARY_SERVER, BACKUP 2
HOME 4
HIDDEN_APP 7
EMPTY_APP 15
This one also suffers from the false flag of the 2nd last minfree not being used. It will start killing HIDDEN_APP at 40MB, which is usable (you'll only get lags 15-20% of the time, and most probably after long usage). Other than that, it's pretty stable.
Misc
There are a few known scripts that tweaks the LMK as well as the app priority (yes, the priority of the process categories can be changed too by using setprop.)
Supercharger is one of them:
http://forum.xda-developers.com/showthread.php?t=991276
Take note that Talon doesn't permit Supercharger to be used (it will override it when booting through boot scripts) as Talon itself uses its own LMK settings that are optimized for ZRAM/Swap.
Kickasskernel script is also included in Supercharger. The script will clash with Zach's script in ThunderBolt! too as both of them tries to set different values for the same settings.
Note that Zach's script doesn't tweak LMK settings as i9000 Talon doesn't permit it. With that, if you're using Zach's scripts, you would need to find other ways of tweaking the LMK. Using Auto Memory Manager is good. You can download Supercharger, look at the presets and apply it using Auto Memory Manager. The preset is the only thing important here
LMK App Category Priorities
Using setprop, there is a way to set the priorities of the category. Since, app categories are different, I can only offer one recommendation: The HOME_APP_ADJ.
This prop setting sets how high of a priority your launcher is. A 1 or 2 is sufficient to make sure your launcher doesn't get killed. However, do you really want it to be on 1 or 2. Based on the previous article (LMK/OOM), you would know that OOM priorities are comparatively based on one another. Setting it 1 or 2 in stock 2.3.5 values would basically override PERCEPTIBLE/VISIBLE app priorities. Do you want your launcher to be killed only after your keyboard/music player to be killed? You decide
Journaling/Barriers
This has been a touchy subject here in XDA for most people who debate about it. Most recently, the SAS/Acid tweaks included a way to disable journaling on these partitions:
/system (System is read only, it's safe to remove journaling. However, you will not see speed increase by removing it as you're not writing onto /system 99.99% of the time unless you're using Titanium backup to remove system apps or copying init.d scripts to it)
/cache (Cache can be rebuilt on the fly. Data corruption on it is not game breaking)
/data (All of your data on your phone is here. Removing journaling can risk data corruption. Read more below)
On whether we need journaling or not, I will pose this situation:
Journaling is required to maintain data consistency in events that could lead to data corruption. Data could get corrupted in a number of situations:
- Misbehaving app that constantly writes without syncing/committing data to the disk
- Power loss due to forced reboots or bootloops when data is partially written/committed into disk
Android will normally buffer its writes before committing to the disk. This way, data stays in the RAM before data would only get written into the disk after a period of time. Take note that we as Android enthusiasts seek ways to better our phone to get the most out of it through experimental and sometimes wacky ways. Take OC/UV for example. When we OCed or UVed too much, sometimes our phone will get deadsleep or constant reboots. This leads to corruption if journaling is not turned on. However, we can get corruption too even with journaling but the risk is smaller.
Mount options too, play a role in whether journaling can be safe/unsafe. Most lagfixes will place a "barrier=1" in the /data to make sure that journals are actually committed before an out-of-order write is done. With that, the risk is greatly reduced at the cost of performance. You could experiment by removing barriers and see if it works for you. No guarantees on data if you remove barriers! More info on ext4/barriers:
http://lwn.net/Articles/283161/
http://kernelnewbies.org/Ext4#head-25c0a1275a571f7332fa196d4437c38e79f39f63
If you do disable journaling, make sure to manually run an fsck on your disk. Make sure the fsck binaries are in your binary paths (echo $PATH to show your binary paths). Don't ask how to do this if you're unable to do fsck. It is your own risk that you are disabling journaling/barriers.
One experiencing I would like to relate is this:
I've personally disabled ext4 journaling on my device. After experiencing a sudden power loss (forced reboot), my apps started FCing left and right and device became unstable that it sometimes rebooted when the device is sleeping. In other words, it's a lost case. Reflashing was the only way to restore my phone. This happened 1 day after disabling my journals.
Also note that ext2 is basically an ext4 without journaling. However, ext4 is updated all the time while ext2 source is not updated for quite some time (2 or 3 years?). Most optimizations are already in ext4 while ext2 even without journaling is slower than ext4 without journaling. A comparison of performance:
No journal:
ext4 > ext2
With Journal:
ext2 (can't do journaling in ext2) > ext4 > ext3
Update: Attached is a JournalingOn.zip for i9000 only that you can flash to rejournal your partitions (Only for i9000 devices!). Also attached is Acid Tweaksv6 - Removed Useless Stuff that will disable journaling only for /system and /cache, if anyone is interested. You will need to rejournal first before unjournaling. To be sure that /system and /cache has no journaling and your mounts are applied correctly, type "mount" without the quotes.
You'll be able to see that /data will have:
Code:
barrier=1, data=ordered
/system and /cache will have:
Code:
barrier=0, data=writeback
To be really sure, you can check by using tune2fs included in both the JournalingOn.zip and Acid Tweaksv6 - Removed Useless Stuff.zip.
Copy the tune2fs to /tmp and set rwxr-xr-x as its permissions using Root Explorer/File Expert
Code:
/tmp/tune2fs -l /dev/block/mmcblk0p2 | grep features
You can substitute the /dev/block/mmcblk0p2 (which is /data) to /dev/block/stl10 (/dbdata) /dev/block/stl9 (/system) /dev/block/stl11 (/cache) to check each partition.
Continued in Post #2 - Lack of space
Still posting ...
Undervolting/Overclocking
This is also another touchy subject, but more towards people complaining about phones that get forced reboots or bootloops. OCing is done to get better performance on your android. WARNING: Ocing will cause more wear and tear on your CPU and will reduce your CPU lifetime. How much it will reduce it? No one knows. It depends on how sturdy your CPU is, and that cannot be measured by any means. It could be reducing months out of year e.g. 6months out of 3 years? No one actually knows.
UVing on the other hand reduces battery drain especially when you UV your 100MHz as 90% of the time in normal usage, your CPU will idle at 100MHz. How much can it save? No one actually did a benchmark on it. Save to say, UVing does not harm your CPU, it will actually extend the life of it by reducing wear and tear Oh, bootloops do corrupt data if you're without journaling
Always remember to clear your UV/OC settings before flashing another kernel!
Take note that the ability to OC/UV depend on your phone. Some SGS can UV better or OC better and some might not.
On how to UV:
1. You can UV more on the lower frequencies than the higher frequencies.
2. Do a UV for
100MHz with (950-150=800) - Take note that 950 is the base value for the voltage. Some kernels might have changed this value to 925 or 900. This is why clearing your OC/UV settings is important as the OC/UV settings will only load the voltage difference, which in this case -150. If the base voltage is 900 and you do a -150 for it, you'll end up with 750 which might cause bootloops.
3. Limit the max frequency to 100MHz. WARNING: Doing this will significantly slow down your system to a crawl, but it is still running. This is done only to test the stability of your system. You can skip this if you want, but you would need to find a way to stress test your CPU at the 100MHz value (and other values as well by limiting the max frequency). Failing in testing this will result in deadsleeping (as your phone is in 100MHz when you sleep and if you undervolt too much, you deadsleep)
3. Test with RockPlayer (or MX Video Player) and play an RMVB file using software decoding for 10mins. If your settings is unstable, Android will freeze up and reboot. (this is just an example, but I find that this way stresses the CPU to the max. I fail to find another way of stressing it as even playing NFS is stable on some voltages but fails when I play rockplayer. Hence rockplayer is the best way so far)
4. After doing this, remove the limit and move on with the next few frequencies.
The rest of the voltages, just rinse and repeat.
200MHz with (950-100 = 850)
400MHz with (1050-75 = 975)
800MHz with (1200-25= 1175)
1000MHz with (no change)
You can experiment with lesser values than these if you get freezes/bootloops as this is by no means a one size fits all value. Some might think this UV is overly aggressive or some might think that this UV value is too underwhelming.
Mine if you're interested:
Code:
100MHz = -200 (950 base)
200MHz = -150 (950 base)
400MHz = -125 (1050 base)
800MHz = -75 (1200 base)
1000MHz = -50 (1275 base)
As for OCing, you would do the same to test the stability. Just that you will be enabling a higher clock for your L0 frequency (L0 is the highest frequency). Some kernels might add more frequency states i.e. from the 5 states above to 6. You can try using Tegrak OC app too. It all depends on your own experimentation.
Memory Leaks
If you found out that your Android is laggy after sometime and a reboot will make it faster, then you're experiencing memory leaks. "free" is a command to show your currently free memory. It will not necessarily be the same value as your phone's free memory (as it takes into account swaps and buffers)
1. Go to terminal emulator (or download the script at Post #3)
Code:
su <ENTER>
free <ENTER>
This will show your buffers and free memory.
My example:
Code:
total used free shared buffers
Mem: 348548 340280 8268 0 1320
Swap: 163836 47292 116544
Total: 512384 387572 124812
Then do this:
Code:
sync <ENTER>
echo 3 > /proc/sys/vm/drop_caches <ENTER>
Type:
Code:
free<ENTER>
And you'll realize that the buffers will reduce and free memory will increase, like this example:
Code:
total used free shared buffers
Mem: 348548 305212 43336 0 88
Swap: 163836 46804 117032
Total: 512384 352016 160368
That means it's done.
Click to expand...
Click to collapse
If this solves the laggginess problem, it's due to vfs_cache_pressure being too low and dirty_ratio being too high. However, in most cases, you don't have to do this as Linux will manage to clear the RAM in a timely manner as long as there are no apps that constantly hold on to the memory (not releasing it). Hence, only do this when necessary (lagginess and such).
With that, I've updated the system_tweak yet again, with this knowledge by making the VM settings more aggressive, which will trigger the memory leak faster. I made this so, as there's a workaround to clear the caches when it gets full.
Having a low vfs_cache_pressure and a high dirty_ratio will save battery and make your device perform faster at the cost of higher RAM usage.
You can actually automate it by using Script Manager by making a script, pasting the instructions and making a widget out of it. To learn more, read the android market description or the in-help guide in the app.
Some commonly asked questions about drop_caches that were answered by me from flolep:
http://forum.xda-developers.com/showpost.php?p=17727859&postcount=3428
http://forum.xda-developers.com/showpost.php?p=17731938&postcount=3446
http://forum.xda-developers.com/showpost.php?p=17736421&postcount=3450
Checking for Battery Drain/ Saving battery
Starting from Gingerbread, you can't really look for Partial wakelocks anymore to determine what is draining your battery at night. BetterBatteryStats is a way to check for that. It also can provide the process that drains your battery most of the time.
A high partial wakelock usually says that something is waking up your phone at night. With that, checking partial wakelock, you can see if these are the culprit:
-Network Location
-Location Manager Service
If so, disable Lattitude or any location check-in app that you're using. It's checking you in every few minutes that drains the battery.
Disabling Wifi/3G/HSDPA saves battery too. I find that Wifi/Edge drains the least amount of battery when idling. To switch to EDGE as opposed to HSDPA/3G.
Go to:
Code:
Settings > Wireless > Mobile Networks > Network Mode > GSM Only
Disabling "Use Wireless Networks" in location and security would save a little bit of battery too I guess. It's in:
Code:
Settings > Locations and Security > Use wireless networks
CSC
CSC is a folder that defines your APN settings and country/region specific configurations aside from Language/Time that is configured in build.prop(also for Samsung Apps).
Having to manually set your APN is annoying right?
Your product code being KOR by default is another annoying thing to deal with. How do I resolve this?
1. Get your CSC from your own country here: http://forum.xda-developers.com/showthread.php?t=948790
2. Extract from the zip file /system/csc/<folder> (where <folder> is your Country's CSC)
3. Use Root Explorer/File Expert to copy it to the phone's /system/csc/.
4. Use nitrality to change your product code. WARNING: This will wipe all your data.
Odexed vs Deodexed
I've been using Deodexed ROMs since I first flash my custom ROMs. One gripe I have is that I seem to have lost the stock smoothness/speed that I experience when I'm using a stock ROM. I found out that deodexing actually extracts the customization files back to the APK (using APK manager) and Odexed files are actually done to optimize the speed of those files itself.
The only reason ROM chefs are using deodexed files is that it is easier to theme. There is no need to decompile the odex files and make the changes as all the theme files are in the APK themselves.
Only other reason that I know of is the overscroll glow. Odexed files can't support it. However, that is a small price to pay for speed/smoothness that I am willing to sacrifice.
Busybox
Busybox is required to perform all of your superuser activities in your android phone. There are some problems associated with this when ROM developers decide to use a certain version of Busybox that are incompatible with the binaries that we use in our phones. When you found out that after changing your kernel/ROM:
- You still have superuser and Titanium Backup still works but,
- Root Explorer/File Expert can't copy files correctly to the /system after mounting rw
- Voltage Control/ Pimp My CPU/ Control Freak/ SetCPU cannot create the Svolt_scheduler file in /etc/init.d
You have a clashing busybox version issue. This can be remedied by:
- Installing the busybox installer from the market
- Installing busybox 1.17.x into /xbin
- Removing all other busybox binaries from your binary path. (This is optional if you found out that after installing busybox, everything works. Try it first before removing) To know your binary path, do an
Code:
echo $PATH
Nandroid Backup
Nandroid Backup is done in recovery (VolumeUp + Home + Power). In recovery, choose Backup And Restore. What it does is it backs up your:
- Boot
- System
- Data
- Cache
When you restore, you should preferably use Advanced restore and restore the /system and /data. All others can be built from scratch (except /boot). If you're converting from CM7 to Samsung Roms, it's best to start from scratch either ways. Restoring nandroid from any is considered dangerous and not supported by most cases. Best is to use Titanium Backup to backup as it can be restored both ways (only restore app though, restore data sometimes can lead to FCs)
Voodoo Color
Voodoo Color is also a point of contention among users. Some like it and some hate it with a passion. If your kernel does support it, here's a way to tweak it:
1. Tweak the color profiles. Can't see a difference, hence I would just pick Voodoo most of the time.
2. Tweak the gamma first to a comfortable value. I.e. drag the 3 sliders together to a comfortable gamma level. After that, try looking in the gradient (the gray slab below the slider) and try to find for neutral gray values. Adjust each slider until you find a neutral gray (i.e. left and right until you see that slab is truly gray)
3. Tweak the RGB multiplier until you have a comfortable level (3 sliders together). Then tweak it the same by referring to the gradient until you're comfortable.
4. Switch off your display for a while and look at your surroundings to reset your eyes. Then turn on your screen again and see if its too green/yellow/blue etc. Adjust the gamma/RGB multiplier until you're satisfied.
This might take a few rounds of testing, but in the end you'll be truly satisfied with it
i9000 Specific
i9000 Kernels - In Depth
You will need to have a stock odexed (why odexed? read a few passages below)ROM with root. You can easily do this by flashing stock XXJVS 2.3.5 and then flashing a custom kernel through Odin like:
- Dark Core - Uses Voodoo initramfs
- CF-root - Uses CF-root initramfs
- Semaphore - Uses CF-root initramfs
- Midnight - Uses Speedmod initramfs
- Galaxian - Uses CF-root initramfs
- Voodoo - Uses Voodoo initramfs
You can flash the custom kernel through Odin by placing the tar file into the PDA section and pressing Start. At this point, do not convert your partitions to ext4 (lagfix) unless you're using a Voodoo based initramfs as Voodoo based initramfs will convert your partitions to ext4 automatically at first boot.
After flashing a custom kernel through Odin, you will gain root. From there, you can choose to use any other custom kernels that use CWM to install or stick with the custom kernel that you've flashed through Odin like:
- TalonDev - Uses Voodoo initramfs
- TalonSH - Uses Voodoo initramfs
There are other kernels as well, but since I did not stress test them, I will not include them here. This thread lists the full repertoire of custom kernels that you can choose from:
http://forum.xda-developers.com/showthread.php?t=1196704
On which custom kernel to pick, you're advised to look at the individual threads original post as well as the last 5 pages of the thread to know about its stability and features. I pick TalonDev myself as it has compache as well as the latest upstream (kernel updates from the Linux OS as well as the official Android Open Source Project/AOSP and optimizations) patches.
At this point, you should decide if you would want to convert to ext4 (lagfix) or not. Your phone by default will reside in an RFS system. The RFS at this point in time is pretty stable and its performance can easily match ext4. Too bad Quadrant scores are bad for RFS, but who cares about Quadrant anyways. I myself choose to use ext4 as the TalonDev kernel has a lot of ext4 upstream patches that optimizes the usage of ext4 on Android.
If you're using Voodoo initramfs, you'll be converted to ext4 automatically.
If you're using CF-root initramfs, you will require the CF-root ext4 app to convert that can be found here:
http://forum.xda-developers.com/showpost.php?p=12651371&postcount=7
Note that on some kernels that use CF-root initramfs, the ext4 app will warn you that you're not on CF-root type kernels. Ignore this warning. You'll be able to convert to ext4 anyways unless you're on Galaxian. Certain Galaxian versions (since the kernels are not versioned, I can't tell which versions are not working) will bar you from converting to ext4 using the ext4 app. If that is the case, just flash CF-root, convert to ext4 and then flash back to Galaxian.
Also not that CF-root based initramfs kernels will remove your bootsounds on first boot. Don't be alarmed by this.
In terms of which lagfix is better (Voodoo vs CF-root lagfix), I can't tell at this point in time. Both are equally good. Since TalonDev uses the Voodoo initramfs, I am inclined to use the same when I am using the same kernel. That should be a good yardstick to follow.
BIGMEM/ Non-BIGMEM:
Some kernel developers released BIGMEM versions of their kernel:
-TalonDev BIGMEM
-TalonSH BIGMEM
-Semaphore bm version
The only difference a bigmem kernel can bring is more memory at the expense of 720p video recording. Playing a 720p video is still possible. Recording it is not on a bigmem kernel. Bigmem kernels normally have 13MB more than their non-bigmem counterparts. How this 13MB could affect you? It depends on the apps you use and how aggressive your LowMemoryKiller is.
XXJVT System apps
System apps can be frozen/removed to make your system faster/less battery draining.
In order to remove/freeze system apps, you would need Titanium Backup (Pro) or System Tuner.
The choice whether we want to remove or freeze the system apps should now be decided. Titanium Backup Pro and System Tuner uses a built in Android mechanism to freeze your system apps - PM disable. PM disable will actually disable the app from the system itself. It will not drain the battery or even launch itself. It is a safer way so to speak. Removing will physically delete the APK app from the system freeing up disk space. If you decide to remove, make sure to have a backup before proceeding. Even if you have a backup, restoring from Titanium Backup may sometime fail. Hence, do this only if you're sure you want to remove that certain app. Freezing an app will make it easier to defrost without any consequences.
Here are the apps that I disabled:
Code:
AngryGPS > Used to manually configure GPS. Not needed if GPS works OK.
BluetoothTest
Buddies Now
lcdtest
screencapture > Screen capture app
Daily Briefing
Days
EncryptApp
Factory Test
Gallery -> I use QuickPic as a replacement. It's faster than Gallery.
Google Partner Setup
Google Search > Google search widget
Home screen tips
HTML Viewer
Market Feedback Agent
Market Updater > I froze this to avoid being updated to Market 3.0. It currently sucks now
Mobile tracker > Mobile tracker, only if you use it, then keep it
Mobile tracker settings > Mobile tracker, only if you use it, then keep it
Perso
PhoneSetupWizard > Required if you're first booting/installing the ROM, not needed afterwards
PopupuiReceiver
Press Reader
Print via Bluetooth
RoseEuKor
Samsung Account
Samsung Keypad -> I use Swype beta instead
Self Test Mode
Service mode
SimDetachNotifier > Will notify you if you detached your sim card. Seems pointless
SNS > Only necessary to sync your contacts if you're using Social hub to do so or syncing calendar from Facebook
SNSAccount > Same as above
Social Hub
Software Update
Synchronise
TwLauncher -> Using Go Launcher Ex instead
wipeoutreceiver > Wipe if phone is stolen. Not needed if you don't use the Samsung service
WlanTest
wssyncmlnps
There are others that you can remove as well. I'm hoping to gather feedback on the other APKs that can be removed and what will be affected by its removal. Please post if you have more information
Disabling Lagfix
Most ROMs would advice you to disable lagfix before flashing a new ROM. Although this is not necessary in most cases (as all Gingerbread kernels support ext4 from the get-go) moving from one kernel to another might need it (to optimize the initramfs it is used on). Hence if you're swapping from one kernel (that has a different initramfs) to another. It is adviseable to undo the lagfix.
CF's lagfix can be undone by using the ext4 app.
Voodoo lagfix can be undone by using the Voodoo Control App.
Speedmod lagfix can be undone by using it's recovery.
Odexed ROM
You might say, hey if I'm using stock, I'll be missing extended power menu, battery percentage and all other theme mods that are not in the stock ROM. Fear not, you can get all these back including Gtalk2, CRT screen off etc here:
$omator's stock+
Gtalk2
There are odexed themes too, in which the developers would decompile the odex files into APKs, make the changes then compile the APKs into odex files again. It is more tedious than deodexed themes but odexing generally makes the phone smoother
You can find the themes here:
http://forum.xda-developers.com/forumdisplay.php?f=666
WIFI Issue on JVR/JVS/JVT
You might be facing some wifi connectivity issues on JVR/JVS/JVT ROMs i.e. it disconnects every few seconds.
This is due to some changes in the ROM that doesn't permit a "Forever" lease time from your modem. Change your lease time to an hour (or two) or if you don't have that option, remove your address reservation option from your modem (Yes, it's a modem only tweak, nothing you can do on your phone)
Memory Freak
Memory Freak is an app in TalonDev that tweaks the ZRAM/Swap and LMK settings. There's a golden rule to the ZRAM/Swap that is:
Swapping to and from the ZRAM will be slower if the amount of ZRAM is more than 50% of the total usable memory, . Hence, I set mine to 160MB (from the 340 total usable RAM). Swappiness in most Linux machines is 60. This means, the system will be inclined to swap in/out more than just using the RAM. I set mine to 50 as a personal preference so that there would be 50% chance that the system will use swap or RAM.
HiddenApp is the amount of free memory to be when LMK starts looking for hiddenapps to kill. I set mine to 52 for my multitasking preference. Experiment with it to see how much multitasking vs smoothness you're looking for. My preference will change in time. Check my signature for the most updated ones.
WIP:
This is obviously a work in progress article that will undergo changes as the Android scene improves. I will spend time to make edits and additions to the post whenever I see fit. Sometimes I will post changelogs at the end of the thread, sometimes I won't if I only make minor edits. Just be sure to check back often to see any new tips offered
Credits:
I claim no credit on these findings except for the ones that I've researched on my own. However, all of it is not of original work since I form my own opinions after reading a lot. I also don't claim that the settings I posted are the most optimal there is. It might not even work well for most of you guys. The key here is tweaking it to your own perfection as there is no setting that will cater to everyone's needs. Hence the real people who deserve credits are:
* All the devs' kernel/apps that I posted here
* XDA forum
* Google
Attention!
If you're looking for scripts, here it is:
[CWM][SCRIPTS][TWEAKS] Thunderbolt!
Script Reviews are here:
Script Reviews
GUIDE UPDATES
UPDATE 1/10/12
* Edited some sections with some new knowledge that I have. A few places, can't name them all Check them out and see if you can spot them.
UPDATE 10/19/11
* Moved around some guides and grouped them together
* Updated some guides to make them more Android centric (as opposed to i9000 centric)
UPDATE 10/18/2011 - Added an indepth article about LMK/OOM. CTRL-F for LMK.
UPDATE 10/12/2011
* Added some comments on the apps removed/frozen so that you can make an informed choice of why the apps can be removed/frozen.
* Added my analysis of most schedulers that I know of and why they are good/bad.
* Moved the scripts to ThunderBolt!: LINK
* Added a guide on the wifi issue for JVR/JVS/JVT
UPDATE 10/1/2011 - Moved the script reviews to this post LINK
UPDATE 9/23/2011:
* Removed the JournalingOn.zip and Acid Tweaksv6 - Removed Useless Stuff.zip because people might use it for devices other than the i9000. This is because in other devices such as SGS4G, the /dev/block/stl10 is /data while in i9000 it's /dbdata. The JournalingOn.zip will not enable journaling on /dbdata without some editing. Hence, I removed it as I don't have a time to put up a warning or notice, and didn't have time to edit the script inside the zip file.
* Readded an edited JournalingOn.zip and readded the Acid Tweaksv6 - Removed Useless Stuff.zip (did not change) to the first post. Only for i9000 devices!!
* Added another way to check if you're journaled or unjournaled. Check the guide below.
* Added some more explanation on common scripts I found.
* Moved the guides around due to lack of space. I added some minor changes to most of the guides. See if you can detect them
Reserved - 10 char
Reserved - 10 char again ...
Changed the name to get more attention. Surprised that no one gave a comment about it
Appreciate any comments or criticisms or correction of what I've written here.
Thanks!
Excellent Read!
Thank you very much!
carnagecjb said:
Excellent Read!
Thank you very much!
Click to expand...
Click to collapse
Glad you enjoyed it
this is actually really helpful. half the time I really didnt know what I was messing around with thanks.
Dataslycer said:
this is actually really helpful. half the time I really didnt know what I was messing around with thanks.
Click to expand...
Click to collapse
Cool Glad that you liked it.
Hope this gets more attention as I would want it to be beneficial to people who uses tweaks and to know how to use them
Nice read Mate. I used to wonder about I/O schedulers and which one to use etc. I like to add build.prop scripts and int.d scripts. This thread just helped me to understand more about it.
Thanks!
read every word, thank you very much. I'll be talking to my kernel dev about BIGRAM... on miui our 720p recording doesn't work right anyways. Thanks again for the great info.
Sent from my MIUI SCH-i500
ShyamSasi said:
Nice read Mate. I used to wonder about I/O schedulers and which one to use etc. I like to add build.prop scripts and int.d scripts. This thread just helped me to understand more about it.
Thanks!
Click to expand...
Click to collapse
Thank you for reading. Hope the knowledge comes in handy when you tweak your phone
sageDieu said:
read every word, thank you very much. I'll be talking to my kernel dev about BIGRAM... on miui our 720p recording doesn't work right anyways. Thanks again for the great info.
Sent from my MIUI SCH-i500
Click to expand...
Click to collapse
Wow, great! Hope you enjoy reading it as much as I enjoyed writing it
having trouble with your thunderbolt tweak. I downloaded the file for I9000 placed it on my phone (SD card) mounted my system and data in recovery mode then proceeded to install the thunderbolt zip file. Using script manager i found the bolt_scripts file and ticked the run at boot button. Then i hit the run button and got 14 permission denied messages asking are you root. Do i have to run this as root. Might be a dumb question but im very new to trying this. Thanks
kevnac said:
having trouble with your thunderbolt tweak. I downloaded the file for I9000 placed it on my phone (SD card) mounted my system and data in recovery mode then proceeded to install the thunderbolt zip file. Using script manager i found the bolt_scripts file and ticked the run at boot button. Then i hit the run button and got 14 permission denied messages asking are you root. Do i have to run this as root. Might be a dumb question but im very new to trying this. Thanks
Click to expand...
Click to collapse
Yes, you need to run everything as root . Scripts in init.d would already be running as root. You just need to make sure Script Manager is running as root for the remount script
Excellent thread, very well written, had a quick skim read, but I'm going to take some time tonight to absorb it all ;-).
Thank you!
zeekiz said:
Excellent thread, very well written, had a quick skim read, but I'm going to take some time tonight to absorb it all ;-).
Thank you!
Click to expand...
Click to collapse
Cool Thank you for reading such a long article
Let me know if you have any questions or if you think I made a mistake
superb thread !
testomat said:
superb thread !
Click to expand...
Click to collapse
Thank you for reading
testomat said:
superb thread !
Click to expand...
Click to collapse
+1
10 chars
rom-g said:
+1
10 chars
Click to expand...
Click to collapse
Thank you for the support
Hi, this is my very first thread.
When my favorite 3d MMO game (only one of it's own kind for armv6 devices, I was playing for more than one year) shifted from ARMv6 devices to ARMv7, I had to do something obviously beside buying an armv7 device. So what I did.
1> shifted to a faster custom ROM (actually nearly doubled the old bench mark score) from stock ROM, problem is, cant overclock cpu, due to, no kernal source access, though that's not a problem cuz, the the game does not need more speed.
2> Though processor speed is less than 1Ghz, I installed Chainfire 3D drivers and the app is also working.
3> V6 supercharger script working.
4> Swap memory ~200MB though not sure, kernel does not support swapping, guessing it works.
5>Most important, tweaked build.prop so that market showing armv7 apps, not only that - apps are getting installed also
but, really frustrated apps are getting forced closed instantly on launching, few apps opened just to show initial screen and to say there's on net connection, when net on, getting force closed.
I'm quite sure there are some ways to be discovered to install and run armv7 apps on armv6, maybe it will lag but that's a different matter...also my build.prop tweak is not complete cuz as market showing armv7 apps but few apps still showing this device is ARMv6-compatible, even after catch/data clear.
Frustratedbird said:
Hi, this is my very first thread.
When my favorite 3d MMO game (only one of it's own kind for armv6 devices, I was playing for more than one year) shifted from ARMv6 devices to ARMv7, I had to do something obviously beside buying an armv7 device. So what I did.
1> shifted to a faster custom ROM (actually nearly doubled the old bench mark score) from stock ROM, problem is, cant overclock cpu, due to, no kernal source access, though that's not a problem cuz, the the game does not need more speed.
2> Though processor speed is less than 1mhz, I installed Chainfire 3D drivers and the app is also working.
3> V6 supercharger script working.
4> Swap memory ~200MB though not sure, kernel does not support swapping, guessing it works.
5>Most important, tweaked build.prop so that market showing armv7 apps, not only that - apps are getting installed also
but, really frustrated apps are getting forced closed instantly on launching, few apps opened just to show initial screen and to say there's on net connection, when net on, getting force closed.
I'm quite sure there are some ways to be discovered to install and run armv7 apps on armv6, maybe it will lag but that's a different matter...also my build.prop tweak is not complete cuz as market showing armv7 apps but few apps still showing this device is ARMv6-compatible, even after catch/data clear.
Click to expand...
Click to collapse
It really isnt just a case of making your device look like it has a ARMv7 processor, and its not just about having more RAM or CPU speed, the ARMv7 SoC is architecturally different see http://en.wikipedia.org/wiki/ARM_architecture#Architecture
The app will need porting to get it running on ARMv6 if at all possible
This is a simple STARTER REF/GUIDE to kernel features/parameters and everything you need to know about custom kernel goodies. Now that there are a few custom kernels out there for our device, you may want to know about these.
I’d be glad if you could help me complete this guide.
First of all I’d like to thank all kernel guys who put countless hours into this to bring us these kernels/kernel hacks.
Index:
Post 1:
A.1: What you want to know about the CPU/GPU of your device
A.2: MUST KNOW FACTS
B.1: Main Kernel Parameters
B.2: CPU/Governor Adjustments
Post 2:
B.3: Extra Features/Parameters
More Coming Soon!!!
Post 3:
Coming Soon!!!
A.1. What you may want to know about the CPU/GPU of your device:
Galaxy S4 4G/LTE (i9505) features a Qualcomm SnapDragon (600) 1.9GHz Quad Core krait (300) CPU and an Adreno 320 GPU.
A.2. MUST KNOW FACTS:
AOSP/GE/TW versions. Which one to flash on ROM X?
Firstly you have to see that what is your ROM's base. You can find this the thread of ROM.
- TW (As for TouchWiz): These ROMs are based on samsung's official firmwares. Mostly these ROMs are modified version of Samsung firmwares. These are also called Stock ROMs. You can find out a ROM is Touchwiz by looking at its base version. In ROM thread, you may see 'based on samsung's latest firmware "XXBMGA"'. Sammy's firmwares are like that. They consist of a region/carrier code + base version. (XX + BMGA). TW framework is essential for the Sammy's apps to work (like splanner). Also most of the TW ROMs are under Android Development forums.
For these ROMs you should Flash TW version of the kernels (obviously!).
- GE (As for GoogleEdition): These ROMs are based on Samsung's official Google Edition firmwares. GE ROMs contain TW materials, so they somehow are considered as TW ROMs (well, not entirely). Everything which is said in TW section is applied here, too.
So if there wasn't a GE edition kernel, the most likely version that is for GE is TW 4.3 version of the kernel. (Talking about Ktoonsez's kernel). It appears like GE Kernels also works on TW ROMs, too. (Very similar sources).
- AOSP (As for Android OpenSource Project): These ROMs are based on opensource projects like CM, AOKP, PA and... Basically these ROMs does not include TW materials. And so the TW apps does not work in these ROMs (Like Sammy's fine camera). Also most of the AOSP ROMs are under Original Android Development forums.
Flash AOSP version of the kernels for these ROMs.
- Other Bases: There are other bases like MIUI out there which are usually closed source on kernel side. So nothing much you can do here about them.
Click to expand...
Click to collapse
The modifications and changing values of kernel parameters will stick until the next reboot. They will be set to default when you reboot your device. So if you want them to stick, you have to do one of the following:
1. Init.d Scripts: Here is a complete guide, how to make one. (The guide is for another device, but the basics are the same!).
2. Set on Boot: The programs like Trickster Mod, have an option named 'Set on Boot'. If you want the settings you have in Trickster to stick, you have to check that option.
Click to expand...
Click to collapse
And a quote from the elite developer that everyone know:
However, if you put any trust in Quadrant scores you could use them to prove that dancing naked for 5 minutes in your garden affects device performance. - Chainfire
Click to expand...
Click to collapse
B.1. Main Kernel Parameters:
Some info:
- The different frequencies of the CPU are usually called CPU states (In very general way of talking!). CPU jumps from one state to another. The different states of CPU frequencies are seprated using a certain value called "step". So to put it simple the frequencies can be certain numbers.
- Min/Max frequency refers to the frequency that CPU is not able to go below/above.
Click to expand...
Click to collapse
OC/UC (As for OverClock/UnderClock):
As you may know, CPU or any other processing unit features a clock frequency. Over/Under Clock simply means raising/decreasing the clock frequency of CPU.
Reason: Why would one need to overclock? Because one needs more processing power. For example if you want to experience smoother gameplay when playing high-graphic games.
Why would we need underclock? Higher processing power demands more battery. So underclocking helps us, reserve more battery. Searching internet and texting don’t need much of processing power. So we can limit the processing power and save battery during low use of our device.
•Note1: OC/UC is not limited to CPU. GPU is also capable of OC/UC.
•Note2: Gamers may not use GPU UC. Limiting GPU processing power impacts significantly on your gaming experience.
•Note3: These apply to both min and max frequency of the CPU. What we said is mainly about the max frequency. Min frequency defines where the CPU frequency can't go below. So by lowering it (not too much) when in low use CPU will stay in lower states, preserving more power. The exact opposite goes for increasing it. The good thing about increasing it is improving performance and snappiness of the device!
UV (As for Undervolt):
Every frequency of a processing unit, demands a certain amount of power to be supplied. Undervolting to put it simple means decreasing the voltage of a certain frequency (or all of them).
Reason: The more voltage CPU/GPU gets, more heat will be generated. So mainly we UV to decrease the generated heat of CPU/GPU.
•Note1: One Frequency needs a certain minimum amount of voltage to perform correctly and the system be stable. Undervolting more than a certain amount of voltage will cause system instability.
•Note2: UV improves battery life by using less power. See this.
•Note3: In most of the kernels you can perform a -50mv UV across the board (means in all frequencies).
CPU Governors:
Frequency scaling is the means by which the Linux kernel dynamically adjusts the CPU frequency based on usage of the device. Governors refer to schemes which dictate to the kernel how it should do these adjustments. (From rootzwiki)
To put it simple, Governors are the way that CPU frequency is adjusted according to the demand of operating system.
Selecting a proper governor for your CPU is crucial to the performance and battery preserving of your device. For example if you are low using your device you may use a more battery friendly governor and if you want to play games you may use a (more power consuming) performance governor.
I/O Schedulers (As for Input/Output):
Input/output (I/O) scheduling is the method that operating systems use to decide which order block I/O operations will be submitted to storage volumes. I/O Scheduling is sometimes called 'disk scheduling'. (From Wikipedia)
To put it simple, Schedulers are the way reading and writing to the SD card is managed.
The same things that is said in the Governors part is applied here, too.
Governors and schedulers explained:
http://forum.xda-developers.com/showthread.php?t=1687578
http://forum.xda-developers.com/showthread.php?t=1369817
http://tinzdroid.blogspot.com/2012/07/android-kernel-governors-modules-io.html
http://forum.xda-developers.com/showpost.php?p=21638852&postcount=56
Click to expand...
Click to collapse
ReadAhead buffer size:
In terms of reading data from SD card, there is a cache which is used as a buffer. The size of that cache is readAhead buffer size. The size has a direct impact on your reading speed of your SD. So giving it a right amount is crucial.
Profiles:
Some kernels let you specify the parameters stated above in different profiles which are based on different usages of the device. In other words, you can have different parameters in some specific device states.
Different profiles can be Screen Off, Call, Music, Charging, etc...
One of the most useful profiles is Screen off.
When screen is off, you don't expect your device to be smooth (!!!) and snappy! Because mainly nothing important is happening when screen is off. So as a profile you can specify different settings for this state.
For example: Screen Off Max CPU can be really a very low number. Max Frequency is 1.89GHz by default, you can go down to 486MHz when the screen is off.
File System “X” R/W (As for Read/Write):
Android by default doesn’t support all the File Systems (What are file systems?! See here). So some kernels may add certain file system R/W. exFAT and NTFS are such file systems.
B.2. CPU/Governor adjustments:
MP-Decision:
Mpdecision decides when the second core shall be active and sets the idle and screen off freq while the governor decides when the freq should be increased/lowered.
Click to expand...
Click to collapse
Hotplug:
Hotplugging as we know dynamically activates second CPU core ON on load conditions and turns second core OFF on low load conditions.
Click to expand...
Click to collapse
- auto hotplug: Make available the hotplugging for the non-hotplugging governors.
Gentle Fair Sleepers:
Sleeper Fairness is a concept which treats sleeping/waiting tasks as if they were in a run queue. This implies tasks which spend most of the time waiting for an user input and such will get a fair share of CPU when they need it. Disabling Gentle Fair Sleepers could improve UI responsiveness.
IntelliPlug:
In kernel replacement of MP-Decision.
Click to expand...
Click to collapse
Eco Mode:
I quote faux123 here:
Eco Mode is an optimized dual core solution for quad-core SOC (System on Chip) like the Qualcomm S4-pro. This should allow for Maximum battery life without sacrificing performance.
Click to expand...
Click to collapse
Eco Mode mainly turns off two cores of the CPU, and in a way turns your device to a more battery friendly dual core system. optimized settings for dual core operations.
Snake Charmer:
This feature tends to cap the minimum frequency of all cores to the value you set.
- Lock Frequencies: This options prevents other apps to change frequencies.
Adjustments:
Here I will explain some useful adjustments.
- touch_boost_CPU: Specify the frequency of the cores when you touch the screen. Low value results in lags and high value lowers battery life, makes your device experience smooth.
- touch_boost_X_core: Specify if the X core comes online when the screen is touched. More online cores result in smoothness, and lower battery life.
- boost_X_core_on_button: Specify if the X core comes online when the button is pressed.
- sync_extra_cores: Specify if extra cores should be synced with single first core when they come online.
Work in progress, will add more info soon.
thanks and credits to:
ktoonsez - for his great kernel and ktweaker. Here.
faux123 - for his great kernel and app. Here.
droidphile - for his great guide. Here.
PM me if I missed someone.
B.3 Extra Features/Parameters:
TCP Congestion Control:
The choices in this section, address how the operating system kernel manages flows of information in and out of the kernel, which is at some level the "switchboard operator" of your handset. More info here.
Better to leave this options as is. Cubic or Westwood as the default of your kernel.
Init.d Support:
There are some scripts that run every time your device boot up which are located in /etc/init.d Those are called init.d scripts. One of the most popular init.d scirpts that is available for Note 10.1 is this.
FastCharge:
This feature makes it possible for the phone to ask for more current from USB host. So your device would be charged faster connecting to a USB host (Or USB Battery) Be aware that enabling FastCharge would block the USB access to your Phone Storage.
Dynamic FSync:
fsync is a system call in Unix/Linux. "man fsync" says:
fsync() transfers ("flushes") all modified in-core data of (i.e., modified buffer cache pages for) the file referred to by the file descriptor fd to the disk device (or other permanent storage device) so that all changed information can be retrieved even after the system crashed or was rebooted. This includes writing through or flushing a disk cache if present. The call blocks until the device reports that the transfer has completed. It also flushes metadata information associated with the file (see stat(2)).
Click to expand...
Click to collapse
So it's something embedded in programs after a related set of write operations to ensure that all data has been written to the storage device. The bolded part is what makes it interesting for some to disable it - "The call blocks" means the calling program waits until it's finished, and this may create lag. The downside is that if the system crashes, the data on the storage devices may be inconsistent, and you may lose data. (From here).
Dynamic FSync, makes it possible for fsync operation to be asynchronous when the screen is on, and synchronous when the screen is off. And what does asynchronous mean? Means OS issues fsync call, but not necessarily immediately at commit time for each transaction. It delays the FSync call for a certain amount of time. In case of a crash, the transactions not yet sync'ed in the last delay time before the crash may be rolled back, but the state of the data is always consistent. (From here).
MultiCore PowerSaving:
This feature try to group up tasks in the least cores possible. To put it simple, it will focus in using least cores for your tasks to be done. This means less cores are active and so more battery life. Also this will decrease performance.
•Note: To enable use TricksterMod app. 0 for disable and 2 for the most aggressive.
Special Modules:
Special modules can be available in kernel files that can be mounted and used in system. For example CIFS:
In order to manage your cifs/nfs network shares on your Android device you need the proper and working modules. And so you can mount/unmount your network accessible file resources and access your data.
zRAM:
In order to explain zRAM more precisely first we need other terms defined clearly:
Swap can be compared with the swap file on Windows. If the memory (RAM) is almost complete, the data which is not used actively (ex. background applications) will be stored on hard drive so as to re-evacuate RAM free. If required, this data is then read back from there easily. This will preserve performance with no lose at multitasking (the main reason we use swap).
In zRAM unnecessary storage resources are compressed and then moved to a reserved area in the fixed RAM (zRAM). So in other words, zRAM is a kind of swap in memory. As the data is compressed not much memory needs to be preserved as zRAM. However, the CPU has to work more because compressed data has to be unpacked again when it is needed). The advantage clearly lies in the speed. Since the swap partition in RAM is much faster than this is a swap partition on a hard drive.
In itself a great thing. But Android does not have a swap partition, and therefore brings Android ZRAM under no performance gain as would be the case with a normal PC. (From here with some editing.)
Click to expand...
Click to collapse
What we need to know essentially lies here:
zRAM off = Low use data will be stored the way they are in the memory. This will cause no extra load on CPU, yet need more RAM.
zRAM on = Low use data will be stored compressed in the memory. This will cause extra load in CPU as to store or restore data, yet preserve more Free RAM.
The main use of zRAM is when you are using a heavy ROM that eats up all your RAM. This will allow multitasking to be more functional. On light ROMs, or for those who don't multitask much, this is not necessary.
Note: Also there are methods to use a part of internal memory as Swap space. This is not as fast as zRAM. But no RAM will be used at all and CPU load is less. Though I am not sure that this has been brought to our device yet. Will add more data soon on this part.
Work in progress, will add more info soon.
Reserved for OP
Very useful thread
Very informative.. Im learning mew things in xda everyday.. Thanks..
ps000000 said:
Very useful thread
Click to expand...
Click to collapse
dannyella said:
Very informative.. Im learning mew things in xda everyday.. Thanks..
Click to expand...
Click to collapse
Glad to be of help.
Very informative. Might want to consider adding zram definition?
lzk123 said:
Very informative. Might want to consider adding zram definition?
Click to expand...
Click to collapse
Of course, zRAM, throttle and some other stuff are in my list.
Awesome guide!
LuigiBull23 said:
Awesome guide!
Click to expand...
Click to collapse
Glad you approved
Also I'd be happy if you could help me complete it with your suggestions.
zRAM added to the guide. (see post 2).
lzk123 said:
Very informative. Might want to consider adding zram definition?
Click to expand...
Click to collapse
Great guide, very useful. Will point this thread to some people in the future. Thanks
xdeal said:
Great guide, very useful. Will point this thread to some people in the future. Thanks
Click to expand...
Click to collapse
Thanks. Glad to be of help.
Recently added to the GUIDE:
- Must know facts. (This really was making mass confusion for some people!).
Stay tuned, more to come!
Quick questions:
Are the governors included on the kernell? if not, where do I get them? I don't know mucho of this things but i'm assuming that each kernell should have thier own governor ot at least the parameters that each governor should follow.
My other question is if the governors change from kernel to kernel or they are standard? The ''ondemand'' governor on a stock kernell it's the same/ behave the same ina cutom kernell? I don't see the point of a custom kernell if the govenor is going to behave the same regardless of the kernell so the kernell should provide the governor with the parameters or the governor itself.
Anyone knows this?
dclarkg said:
Quick questions:
Are the governors included on the kernell? if not, where do I get them? I don't know mucho of this things but i'm assuming that each kernell should have thier own governor ot at least the parameters that each governor should follow.
My other question is if the governors change from kernel to kernel or they are standard? The ''ondemand'' governor on a stock kernell it's the same/ behave the same ina cutom kernell? I don't see the point of a custom kernell if the govenor is going to behave the same regardless of the kernell so the kernell should provide the governor with the parameters or the governor itself.
Anyone knows this?
Click to expand...
Click to collapse
Yes governors are in the kernel, you don't get them any where. You can set governor with the apps that usually come with the kernels.
Custom kernels usually have more governors that stock kernel, letting you choose the one that suits you the best. Usually the governor that is tweakable or have nice settings is there to choose (like Ktoonzactiveq in Ktoonsez's kernel).
Also sometimes the same governors from stock kernel are tweaked to work better in custom kernel.
The main thing is that the well known governors are mostly standard and same in different kernels. But some are tweaked and some are specifically tweaked for the custom kernel (ex. Ktoonzactiveq or Abyssplug).
Sent from my GT-I9505 using Tapatalk
csec said:
Yes governors are in the kernel, you don't get them any where. You can set governor with the apps that usually come with the kernels.
Custom kernels usually have more governors that stock kernel, letting you choose the one that suits you the best. Usually the governor that is tweakable or have nice settings is there to choose (like Ktoonzactiveq in Ktoonsez's kernel).
Also sometimes the same governors from stock kernel are tweaked to work better in custom kernel.
The main thing is that the well known governors are mostly standard and same in different kernels. But some are tweaked and some are specifically tweaked for the custom kernel (ex. Ktoonzactiveq or Abyssplug).
Sent from my GT-I9505 using Tapatalk
Click to expand...
Click to collapse
Ktoonzactiveq?? Hmm.. Never heard of it but sounds much better than Ktoonservativeq lol.
Yes I know what you meant but you almost had me there a sec for a completely different governor that the boss has not shared with me.
csec said:
Yes governors are in the kernel, you don't get them any where. You can set governor with the apps that usually come with the kernels.
Custom kernels usually have more governors that stock kernel, letting you choose the one that suits you the best. Usually the governor that is tweakable or have nice settings is there to choose (like Ktoonzactiveq in Ktoonsez's kernel).
Also sometimes the same governors from stock kernel are tweaked to work better in custom kernel.
The main thing is that the well known governors are mostly standard and same in different kernels. But some are tweaked and some are specifically tweaked for the custom kernel (ex. Ktoonzactiveq or Abyssplug).
Sent from my GT-I9505 using Tapatalk
Click to expand...
Click to collapse
That's what I thought! I appreciate the help!
One more question: what about the Schedulers? Do they come with the kernel as well? can thos be modified? For waht I've been reading in the forum the Schedulers are more a data allocation sort of thing, those can be modifed depending on the kernel values? do they have anything to do with governors or can they be set regardless of the kernel/governors parameters?
I don't know mucho of this things but since I got the S4 I just felt in love with android and I'm trying to learn a bit. =]
dclarkg said:
That's what I thought! I appreciate the help!
One more question: what about the Schedulers? Do they come with the kernel as well? can thos be modified? For waht I've been reading in the forum the Schedulers are more a data allocation sort of thing, those can be modifed depending on the kernel values? do they have anything to do with governors or can they be set regardless of the kernel/governors parameters?
I don't know mucho of this things but since I got the S4 I just felt in love with android and I'm trying to learn a bit. =]
Click to expand...
Click to collapse
The same thing that I said about the governors applies to schedulers, too. They are in kernel, can be modified, tweaked, and are standard ones are the same in different kernels.
LuigiBull23 said:
Ktoonzactiveq?? Hmm.. Never heard of it but sounds much better than Ktoonservativeq lol.
Yes I know what you meant but you almost had me there a sec for a completely different governor that the boss has not shared with me.
Click to expand...
Click to collapse
Hahahaha, sorry. I mistyped this the first day, and SwiftKey got the best of me!
But thinking logicly, it's based on conservative, and so I think that's why there's the "servative" part! That's it, burnt into my mind. :good:
[email protected]@T:
Hi guyz today im gonna discuss about top apps which increses perfomance or are helful in any other way on rooted devices only.
1 >Greenify
Greenify is an Android app that can improve your device's battery life and performance by hibernating certain apps.
2>SEEDER
Many people might not be aware of this app.This app reduces the lag which every one of you might have experienced while switching between apps.I personally have experienced this app and it actually does remove lags.
3> XPOSED INSTALLER
Xposed is a framework for modules that can change the behavior of the system and apps without touching any APKs. That's great because it means that modules can work for different versions and even ROMs without any changes (as long as the original code was not changed too much). It's also easy to undo. As all changes are done in the memory, you just need to deactivate the module and reboot to get your original system back. There are many other advantages, but here is just one more: Multiple modules can do changes to the same part of the system or app. With modified APKs, you to decide for one. No way to combine them, unless the author builds multiple APKs with different combinations.
4> SET CPU
SetCPU is a tool for changing the CPU settings on a rooted Android phone or tablet. SetCPU works with a great variety of Android devices and ROMs, including the HTC One series, Samsung Galaxy series, and Nexus devices. You're under control: SetCPU can improve your performance, save battery, or both!
Automate SetCPU with profiles! SetCPU allows you to set up powerful profiles to change your settings under certain conditions, such as what app is running, when the phone is asleep or charging, when the battery level drops below a certain point, when the phone's temperature is too high, or during certain times of day. See the screenshots for examples of how you might set up profiles.
SetCPU's wide feature set make it useful to Android beginners and enthusiasts alike. Accelerate yo...
5> CHAINFIRE 3D
Chainfire3D is an intermediary OpenGL driver. What does that mean? It means that Chainfire3D sits between your apps and the graphics drivers, and can intercept and/or change commands between the two. It has some built-in functions, and can be further extended with plugins too.
6> NO-FRILLS CPU
No-frills CPU Control is a tool you can use on your Android phone to quickly set the CPU frequencies and governor to use. It allows you to use the highest frequency your phone supports and gain some precious FPS in your preferred game, or go down to the lowest frequency and gain some more juice when your phone is sitting idle. All of this without any memory footprint or services running in the background!
8> TITANIUM BACKUP
Titanium Backup is a backup utility for Android that backs up your system and user applications along with their data on external storage of your choice. It is a leading Android application that uses root access to pull all your important applications and data from the system partition and stores them for future restoration. Whether your phone is corrupted or flashed with a custom ROM, Titanium Backup can save the hassle to get your phone loaded up just like it was before. Best of all, it is FREE! If you use it regularly, the PRO version will enhance the experience like never before! Get it today and protect your precious data before its too late!
9> ROOT APP DELETE
best tool for android users, and works better with root permission.
it helps you easily and quickly manager system apps (freeze or remove), the best tool for managing your android system.
compared to other clean or uninstall tools, it is much more better and special:
* tiny,fast, even running on old phones with low memory.
* "modify" MODE, change system apps before uninstalling
* can "Disable" backgroud system service, such as "google backgroud transport" and "contact sync service"
I have personally used all the apps and I think they are very good.
Sent from my Micromax a110 using XDA Free mobile app
Where can I get that Seeder app? Thanks.
Sent from my SM-N910C using XDA Free mobile app
ALCATEL IDEAL 4060A
STOCK KERNEL WITH INIT.D. & INSECURE BOOT SUPPORT
SPECIFICATIONS:
Model: Alcatel Ideal 4060A
Android Version: 5.1.1 Lollipop
Kernel Version: 3.10.49-g3d12fcb
GCC Version: 4.8
Build Date: Tuesday, July 26, 2016
Revisions Date: Saturday, August 5, 2017
Board Platform: Qualcomm Snapdragon 210 (MSM8909)
FEATURES:
CPU Governors: Interactive, OnDemand, Performance, Userspace, Powersave
Frequencies: 200MHz, 400MHz, 533MHz, 800MHz, 998MHz, 1094MHz
Minimum & Maximum Core Control
VDD Restriction & Temperature Throttle Control
GPU Frequencies: 200MHz, 307MHz, 409MHz
GPU Governors: bw_hwmon, bw_vbif, cpufreq, gpubw_mon, msm-adreno-tz,
performance, powersave, simple_ondemand, spdm_bw_hyp, userspace
I/O Schedulers: cfq, deadline,row, noop
Adaptive Low Memory Killer: 5 Presets & Tunables
Z-RAM Support
Virtual Memory Tunables: Dirty Ratio, Dirty Background Ratio, Dirty Expire Centisecs, Dirty Writeback Centisecs, Overcommit Ratio, Swappiness, VFS Cache Pressure, Laptop Mode
SELinux Permissive/Enforcing Toggling
Entropy Read/Write Ahead Support
TCP Congestion Algorithms: cubic, reno
Hostname Editing
ADB Over WiFi Support
Android Logging Support
Init.d Script Support & Emulator
REQUIREMENTS:
In order to use init.d script support, and in order to be able to tune this kernel and use its features, you need to be running a ROM with root privileges. Also, while not absolutely required, it is recommended that you have TWRP custom recovery installed. This kernel can be installed by on-device flashing apps such as Rashr, Flashfire, etc. However, for this thread, I will be instructing on TWRP installation only. In order to utilize init.d support, you also need to install a recent version of BusyBox.
DISCLAIMER: You flash this kernel at your own risk. As always, rooting or flashing the partitions of your device comes with the inherent risk of rendering your device inoperable.
You hereby assume responsibility for your own device, and absolve me of any liability for any damage caused to your phone by flashing this kernel. Follow the simple instructions carefully and you should experience no adverse results.
NOTES: This is a stock kernel which has been modified to provide init.d and insecure boot support. The advantages of insecure boot support include having root access through adb shell -- it enables adbd to run as root. Init.d support gives you enormous flexibility in the ability to run scripts and mods to be run at boot -- everything from battery tweaks to performance mods. Aside from init.d, the Kernel Adiutor-Mod application, included in the download link below, allows you to tune several parameters of the kernel, change CPU/GPU governors, adjust I/O schedulers, set CPU/GPU frequency minimums & maximums, apply an adaptive low memory killer preset, etc. With some modding, you will notice a remarkable increase in responsiveness, stability and overall performance of the Android OS, as well as a tremendous increase in battery life. . Trial and error is key. Do some research on the best kernel mods and set your own preferences. You are the captain of your own ship...
THANKS & MENTIONS:
Thanks to @Grarak for developing the original Kernel Adiutor application. Thanks also to "Yoinx" for modifying the original application and thus creating Kernel Adiutor-Mod.
KERNEL SOURCE CODE: https://github.com/zombah/android_kernel_alcatel_msm8909
INSTRUCTIONS:
1. Assuming you have root, BusyBox & TWRP custom recovery installed on your device, boot into TWRP and flash the zip installer in the below download link;
2. Wipe the dalvik cache and reboot system;
3. Upon reboot, install the Kernel Adiutor-Mod application from the below download link.
Open the app, grant superuser access when prompted, and tap on the menu icon near the upper left of the screen;
4. Done.....use the options in the menu to tweak the kernel's settings, change CPU governors,
set CPU/GPU frequencies, toggle SELinux mode, etc., etc.
DOWNLOAD LINKS:
Kernel Installer: https://drive.google.com/file/d/0B1Sfod4HWfk2NjUzWGVldThtQ0U/view?usp=sharing
Kernel Adiutor-Mod APK: https://drive.google.com/file/d/0B1Sfod4HWfk2OC1ORURoN3hTeUE/view?usp=sharing
Been trying out KA mod for about a week, not using the cus kernal tho. Just happened to run into it after a search since when I tried Garak's official back awile it didn't seem to have any effect. Not sure but it may have been due to not (unrestricting) it in apps, or not enabling init.d emulation in it? In any case, using it to set SElinux permissive and trying to squeeze a little more battery life out. After not really knowing what I'm doing, I ended up staying with interactive and just making a few guesses from what I could find out in searches. I think battery life is a (little) better?
Interactive:
CPU minimum freq 400 MHz
tunables:
go_hispeed_load 95
target_loads 1 533000:85
800000:90
998400:90
1094400:80
If there are other/additional things to try, please let me know!
scohut said:
Been trying out KA mod for about a week, not using the cus kernal tho. Just happened to run into it after a search since when I tried Garak's official back awile it didn't seem to have any effect. Not sure but it may have been due to not (unrestricting) it in apps, or not enabling init.d emulation in it? In any case, using it to set SElinux permissive and trying to squeeze a little more battery life out. After not really knowing what I'm doing, I ended up staying with interactive and just making a few guesses from what I could find out in searches. I think battery life is a (little) better?
Interactive:
CPU minimum freq 400 MHz
tunables:
go_hispeed_load 95
target_loads 1 533000:85
800000:90
998400:90
1094400:80
If there are other/additional things to try, please let me know!
Click to expand...
Click to collapse
Set your Adaptive Low Memory Killer to Very Aggressive. This will restrict background apps from flooding your free RAM and save on battery life.
Are you not able to use init.d with this kernel?
MotoJunkie01 said:
Are you not able to use init.d with this kernel?
Click to expand...
Click to collapse
I have init.d emulated ticked on. Settings work, even on reboot. I'll try the memory settings.
scohut said:
I have init.d emulated ticked on. Settings work, even on reboot. I'll try the memory settings.
Click to expand...
Click to collapse
Good to hear
MotoJunkie01 said:
Set your Adaptive Low Memory Killer to Very Aggressive. This will restrict background apps from flooding your free RAM and save on battery life.
Click to expand...
Click to collapse
This DOES seem to be helping also..
scohut said:
This DOES seem to be helping also..
Click to expand...
Click to collapse
It does me too. With a free RAM widget running, I notice about 325Mb+ free RAM most times with 24 user apps installed.
With only a 1750 MAh battery we need all the help we can get
scohut said:
With only a 1750 MAh battery we need all the help we can get
Click to expand...
Click to collapse
Amen there