Related
Hey guys, in search of tips to speeding up Android on our phones, I stumbled across this article, which was written about an XDAer's script that helps fix the problem of our phones taking FOREVER to come out of sleep to answer incoming calls. Lately, I've simply just been UNABLE to answer calls and have had to just call the person back as soon as my screen came fully alive.
http://www.techalps.com/android/app...our-phone’s-response-to-an-incoming-call.html
I tried this out today and it does indeed help. Also, apparently turning off vibration helps too.
I believe this is the same thing as the renice script we already have implemented. It's in the initrd (part of the nbh) and runs at every boot. It pretty much does the same thing as that app, sets the priority of the phone higher.
phone prioritiser (app) helps only on heavy cpu.
thanks for the replies guys! Good info for us non-devs to know!
Actually, my phone is having the acore force close problem now, after installing this, so it looks like I'll have to reflash
so I DON'T RECOMMEND INSTALLING THIS everyone!!
the thing is though, I noticed that after installing it, it was indeed helping my phone come out of sleep a lot quicker!! any explanations?
The things it does is this:
Code:
busybox renice 5 `pidof com.google.process.gapps`
busybox renice -18 `pidof com.android.phone`
busybox renice -18 `pidof mediaserver`
busybox renice -18 `pidof mediaserver`
busybox renice -16 `pidof com.android.launcher`
busybox renice -15 `pidof com.htc.music`
busybox renice -15 `pidof com.android.music`
First of all one line above is reduntant but basicly what it does is that it gives the phone and the mediaserver process high priority (low is high when we're talking about process priorities). I assume that the mediaserver plays the ringtone otherwise it wouldn't make sense.
Then it puts the launcher and then the music player.
At least increasing the priority for the phone and mediaserver makes sense, the rest I do not know, maybe just a personal preference by the one who wrote the script.
I can't see why this would cause a force closing phone app though.
kallt_kaffe said:
I can't see why this would cause a force closing phone app though.
Click to expand...
Click to collapse
i just tried the super E rls3/2 from incubus because its 5.0.8. his build is already pretty slow so the upgrade to rls3 that had the phone priority script in it was necessary for me to be able to pick up a call.
i did notice that other programs suffered in response. i never got force closes but i got a few close/wait
my opinion is that if a build is too slow to pick up...change. myns eclair and vaniljeclair and aquatrans are all fast enough for me to pick up. (some with slight lag, but only slight)
also keep tasks closed and use rogue tools to over clock to around 500
But the idea is still interesting... I wouldn't use this app though but rather make a script and set it up as a service. However I did a quick test just bumping the phone and mediaserver to -18 and then calling my phone and I noticed no difference (with VaniljEclair RLS5 on NAND, compcache enabled and fully odex:ed).
I read and watch so many contradicting things about this subject, I just cannot seem to understand the truth..
I know Android works off of a linux type of OS, and that the memory function is superior to many others..
I read that having any app killer is actually bad because it drains your battery even more than if you don't have it, that the apps running in the background aren't really running as the memory or most of it is now running the application you're using.
Now what if the app killer program has a function that lets you disable the auto kill, I assume that is the part that runs and drains the battery?
would it be good then? or is it still bad?
Finally if so, do I even bother to close out the applications after a full days use?
It just seems very confusing when a large group of people tell you NO and a large group of people tell you YES.
and its reputable places too, not just amatures
http://www.youtube.com/watch?v=DVWZFNHq0uQ
I would just like to add to your confusion by saying that I read that the new Android 2.2 API disables the ability to "kill" apps. It can kill background services or something to that effect, so the program is still in memory, but not actively performing operations or something. That's all paraphrased from a 3 month old memory, so take it with a grain of salt, but if that is true, is there any point to a Task Killer if you have Froyo?
Actually, thinking about a reply gave me a good idea. More on that some other time
Long story short: it all depends.
Short story long:
Anyways, task killers are not inheritly bad, but they are "dangerous". How dangerous depends entirely on how you use them. In general I would say, if you have a device with sufficient memory available, I would only use a task manager to manually kill games (only) that you played but are no longer playing, or some apps if you understand what they do and how they work. Generally we refer to task killers that do not have an automatic component as task managers instead of killers.
One danger is how the app is killed. If it is not killed "gracefully" corruption may occur. This is very rare to occur, though. Apps will almost always be killed gracefully.
Another danger is killing apps that are tied to background services. In most task killers (if not all) there is no way to see if they have such a background service. What most task killer display is actually only visible components of applications. However, killing them will also kill the background services. This may prompt Android to just restart it, but this time invisibly, and you just wasted quite some CPU (not to mention time) to save a little bit of memory you won't miss. Some services are hefty on the initialization but light on running on purpose, and this will make the effect bigger. Another option is that the service simply no longer runs -as it is NOT restarted- and some part of your phone may not behave as you expect it to. Common sense helps here. For example, you could kill the browser like this, but killing a system service app like (I assume) SetCPU, JuiceDefender, etc will generally be a bad idea. Automated task killers do not usually distinguish between these.
Now, Android's internal killer does distinguish between these things (and many more important factors). Say you are in this situation:
- A is running in the foreground
- B is in the background and has a service
- C is in the background
- D is in the background
If we run low on memory, Android will kill C and D before killing B, and it will kill B before killing A. Which is pretty much exactly how we want it done. Android will know when it is necessary to do this. An automated task killer may for example kill B. But B might automatically restart it's invisible parts. Then the automated task killer is in the same situation again, and will shortly after that kill C or D. This operation just wasted a whole bunch of CPU cycles!
Keep in mind, that if an application is not specifically built to do something while it is not in the foreground (i.e. directly visible on your screen), it will not actually be executing any code at all. It will just take up some memory. This is a good thing, because if you go to this app again it will still be exactly as you left it, without the app having to go through all the loading and initialization steps again. How much effect that has depends on the app, obviously. You should see this more as a cache, or ramdisk, or something similar. Well-built apps do generally not have a negative effect on CPU or battery use when they are not in the foreground. They would only use background resources if truely needed.
There is no noticable negative side effect on battery to this. If Android needs the memory and it doesn't have any to spare (for example for your foreground application), it will simply kill off one or more of the background applications.
Also keep in mind that if you "close" an app by using the back button, on many devices and ROMs this will actually close the application instead of keeping it in the background. There is no foreward button, after all.
Now, to the battery issue. I have seen, heard, and read endless complaints by many users regarding poor battery life, RAM being full (there is hardly any reason to care, on a proper firmware), etc. and that these task killers help them. The fact is, that 95 times out of 100 these users are running "a bunch of crap". Because make no mistake, there are a lot of crap apps, widgets, even complete custom ROMs out there. Using system resources when they don't need to, using background services when they don't need to, constantly polling data instead of being event based, etc. Just badly done stuff.
Finding the culprit is often difficult, though in my personal experience (your mileage may vary) the culprit is most often a app+widget combo rather than a bar app. That is, unless you install a serious hack (again, like CPU speed managers, battery savers, etc) and configure them exactly how they shouldn't be configured for your usage situation, with all the resulting adverse effects. When someone I know personally has these issues, the first thing I have them do is uninstall all apps that provide widgets. You would be surprised how often that has solved the issue altogether.
Automated task killers are a band-aid solution in these cases. Of course, there also exist cases of improperly configured Android memory management in the firmware, and if you have a device with very little RAM this can also be problematic, but these are much less common than the user installing crappy stuff (though sometimes it is the carrier with bad bloatware). Usually, automated task killers just fight symptoms, not the cause.
My advice would definitely be, check what you're running and what you install. If you're a bit techsavvy, use a task manager, but only kill tasks manually. Never "kill all" unless absolutely necessary, and don't run it automated unless you are absolutely sure the developer is worth his salt. Even then, don't make a habit out of killing apps manually. Do make a habit out of exiting apps (especially games) with the back button, instead of for example using the home button to switch to the app launcher.
A case can be made for manually killing apps as it gives you more control over what is killed when, but the time you would spend doing it is worth more than what you would save (generally). Also keep in mind that the automated task killer itself will also be running a background process to check on your situation and kill apps, and thus may actually be part of the problem instead of the solution.
@nukedukem: I'm running Froyo and the task manager I'm using kills apps just fine when I tell it to do so...
I say they are bad unless you have rogue apps. And even then they are not needed. Hit Menu-Settings-Applications-Manage Apps-Running Tab-Click App-Kill. But instead of that, you can make a widget on your homescreen that goes straight to it. Long press homescreen-shortcuts-settings-manage applications. Done. I use that when I want to kill a game or something eating CPU. Otherwise I just let Android do its thing. Also, I like Watchdog Lite. It monitors apps using the CPU and alerts you when one exceeds the threshold and gives you option to kill or ignore(app may have a legitimate reason for hogging CPU) the app in question. This is good because app or processes are really only hurting or effecting the battery when they are using the CPU, not RAM. However, another option for task management is Autokiller in the Market. It allows you to change Android's minfree settings, or internal task manager, to kill off apps sooner. I set mine to be aggressive. I actually never worry about task management. Unless Watchdog beeps at me. I think the last time I killed an app was 3 weeks ago. I remember the day Autokiller came out well. I had the HTC Hero back then. To do what that app does I had to change them manually each boot and eventually a script was made to change the settings. Those early days of Android were so much fun. ;D
If anymore questions let us know.
They are just like everything, use in moderation. I use mine all the time but I don't mess with system services and only use it to kill stuff I've been using.
And yes they still work in 2.2 as long as the app is not active
LATEST UPDATE: 02.02.2013
A question that I'm often asked is:
"Can I have your permission to use your script in my ROM etc...?"
That answer to that is:
"Yes it is ok to use the code. I don't really believe it's useful anymore, but if you can find a use, and possibly improve the code to make it work better, go for it."
Version 1.0.2
Download available for ClockworkMod: requires Root (Superuser/Busybox), and a kernel that supports "init.d" scripts (script files that are stored in /system/etc/init.d/).
Always have a backup before installing any modification. Even though this script is rather simple, I can't guarantee it will work on every ROM! It appears to freeze custom ROMs such as CM, I don't know why. Maybe someone else knows.
NOTE: This script appears to be less and less useful as newer ROMs and phones become more sophisticated in dealing with any sort of lag. Tested on I9000XWJW9 and it doesn't seem to help. This ROM is quite smooth anyway.
What this script hopes to achieve:
- Entering your PIN with minimal/no delay/lag
- Minimising delay with lock screen pattern/unlock (not the time it takes to wakeup, but the touchscreen response lag)
- Having smoother notifications on the status bar, and smoother pulldown menu response
- Minimising Launcher lag while Media Scanner is running (can scroll through screens without heavy pauses)
- Minimising lag when scrolling through the market while icons are still loading
- Installing/Uninstalling apps while continuing other tasks
- Minimising/eliminating intermittent lag spikes in gaming
- No delay in being able to answer phone calls
... you get the idea
#!/system/bin/sh
#
# Loopy Smoothness Tweak v1.0.2 - 02/02/2013 (http://forum.xda-developers.com/showthread.php?t=1137554).
#
# An attempt at keeping the UI running a little smoother.
# Optimised for Galaxy S1 stock ROM, but can be modded for other Android devices. Backup recommended before running scripts.
# Not recommended for custom ROMs, such as CM. The "sleep" command appears to halt the OS, rendering the script useless.
# Feel free to edit how you wish, but please leave at least the first comment above as is.
# Any editing must be saved in UNIX (LF) format. Google "text editor unix lf" to read more.
#
Click to expand...
Click to collapse
However, as phones get faster, this script will probably have less of an effect.
Even with 2.3.6 and ext4, RAM scripts, governor tweaks, other tweaks, etc. the occasional lag still appears to be there, especially noticable when installing/unistalling, gaming, or even just scrolling through the launcher screens and menus. I decided to investigate. Being a linux newbie, I had to also source the appropriate commands.
The following has been discussed a little here and there on other Android forums, but surprisingly I couldn't find anything about it in the I9000 section...
Thinking of how processes in Windows can be run with six different priorities (Low, Below Normal, Normal, Above Normal, High, Realtime), I investigated to see what the deal was with Linux/Android. Turns out there are forty settings, ranging from -20 (Highest) to 0 (Default) to 19 (Lowest).
The next step was to see which process was causing the CPU bottleneck as it was happening. The top command is handy for this. I used this in adb shell (these tests were performed quite some time after reboot when there was craploads of stuff in the memory - the impact is not very noticeable after a fresh boot, or with very few apps installed/running.
UPDATE: The reason behind the majority of the kswapd0 issue was due to modified code of a custom kernel I was once using. I do however still find the script of benefit to me, and maybe you will too. You can still read below if you wish, but it may be irreverent.
Code:
adb shell
top -n 1
At the top of the list was:
18 16% R 1 0K 0K fg root kswapd0
Click to expand...
Click to collapse
kswapd0 is a kernel thread responsible for managing the memory.
I know Angry Birds can show a little lag from time to time, so I performed a little testing while playing that.
To change the priority of a running process, I used the renice command as such:
Code:
su
renice -20 `pidof kswapd0`
where -20 equals highest priority and `pidof kswapd0` returns the PID of the process, which is required by renice. In this case, 18.
To confirm the change, the ps command will give you what you need to know. Interesting to note "krfcommd" with a value of -10, and "mediaserver", -8.
Code:
ps -p kswapd0
If you enter "ps -p" all processes in memory are shown, along with their "nice" value.
It shouldn't take long before the game becomes barely playable at times (for a split second), as kswapd0 completely takes over the CPU until it performs its task. Setting the priority to
Code:
renice 0 `pidof kswapd0`
returns kswapd0 back to its default, and Angry Birds with the seldom lag. Let's go the other way now with
Code:
renice 19 `pidof kswapd0`
setting kswapd0 to its lowest priority, it should now have barely any impact on the game, if at all. Will this have negative impact on Android, though? Not sure yet.
We can even go one better and give Angry Birds all the CPU it needs via
Code:
renice -20 `pidof com.rovio.angrybirds`
With these settings in place, you could virtually play this all day, and your battery would probably be flat way before any lag becomes noticeable.
One problem though, when you close and reopen the game - assuming it's left the memory - it will have a new PID and the priority is set back to 0 (default).
Now, with my very limited knowledge of Linux/Android/Busybox, I'm not sure if there's a way to tell an app to open with a priority other than 0. Well, there is the nice command, but I couldn't get that working.
A common problem is the phone dialer app taking too long to popup when someone calls. Luckily, processes such as this one enter the memory from boot and seem to remain there. Setting its priority to -20 will basically tell the CPU to hold everything with less priority and open the phone dialer ASAP so you can take that call. And it works. I was on Angry Birds when a call came in, and was able to answer it on the first ring. I tried then calling myself without the -20 phone or the 19 kswapd0 settings, and there was an extra 2-3 second delay before I was able to answer. A few other apps that usually never leave the memory are default launcher (in my case, ADW Launcher EX), SMS/MMS app, Swype, Status Bar, and some others.
Even with apps launching at the default priority, with kswapd0 at 19, it still allows them more CPU, and may just be enough to combat this lag that people have tried to rid of with RAM scripts, Overclocking, and what not.
The script shown below is not the current init.d download script.
And the result (still a work in progress):
Code:
#!/system/bin/sh
###### Loopy Smoothness Tweak for Galaxy S (Experimental) #######
sleep 3
renice 18 `pidof kswapd0` # please give credit and thanks to loopy for this line if it works
##### Set nice levels for smoothness loop BEGIN #####
### Let's loop this in the background for a bit
for i in {1..20}
do
sleep 5
### Phone dialer app ###
renice -20 `pidof com.android.phone`
### Launcher apps ###
renice -19 `pidof com.sec.android.app.twlauncher` # TouchWiz Launcher
renice -19 `pidof org.adwfreak.launcher` # ADW Launcher Ex
renice -19 `pidof org.zeam.core` # Zeam launcher
### System apps ###
renice -19 `pidof com.android.mms` # Text message app
renice -19 `pidof com.swype.android.inputmethod` # Swype keyboard
renice -15 `pidof com.sec.android.app.controlpanel` # Task manager
renice -15 `pidof com.android.systemui` # Status bar
renice -9 `pidof com.android.settings` # Settings menu
renice -9 `pidof com.android.browser` # Browser app
renice -9 `pidof com.android.vending` # Market app
renice -6 `pidof com.sec.android.app.camera` # Camera app
renice -6 `pidof com.sec.android.app.fm` # FM Radio app
renice -6 `pidof com.google.android.youtube` # YouTube app
renice -6 `pidof com.google.android.apps.maps` # Maps
renice -3 `pidof android.process.acore`
renice -3 `pidof android.process.media`
### Memory management kernel thread ###
renice 19 `pidof kswapd0` # please give credit and thanks to loopy for this line if it works
done
##### Set nice levels for smoothness loop END #####
What would be ideal is if programs such as launchers (TouchWiz Launcher etc..) had the ability to set its "nice" level upon launch, and have kswapd0 set real low, assuming it's safe to do so. If Android isn't doing this, why not? This isn't a good idea? Maybe it's only Samsung? If so, then... well, I won't ask why not...
NOTE: These commands/parameters vary depending on the su/busybox version installed.
Common SGS1 apk's:
com.android.phone # Phone
com.sec.android.app.dialertab # Dialer
com.sec.android.app.twlauncher # TouchWiz Launcher
com.android.mms # Messaging
com.swype.android.inputmethod # Swype keyboard
com.sec.android.app.controlpanel # Task manager
com.android.systemui # Status bar
com.android.settings # Settings menu
com.android.browser # Internet Browser
com.android.vending # Google Play
com.sec.android.app.camera # Camera
com.sec.android.app.fm # FM Radio
com.google.android.youtube # YouTube
com.google.android.apps.maps # Google Maps
com.android.phone # Phone
Common SGS3 apk's:
com.android.phone
com.android.contacts
com.sec.android.app.controlpanel
com.android.browser
com.android.mms
com.android.vending
com.android.settings
mediaserver
com.sec.android.app.camera
com.sec.android.app.videoplayer
com.sec.android.app.myfiles
com.android.browser
com.sec.android.app.camera
Click to expand...
Click to collapse
Quick FAQ:
I wanna see how it works without it again, how do I remove the script?
To remove, delete the file /system/etc/init.d/S00loopyst. If using Root Explorer, use Mount R/W before you attempt to delete. For adb, use the commands at the DOS prompt:
Code:
C:\>adb root
restarting adbd as root
C:\>adb remount
remount succeeded
Code:
[SIZE=2][SIZE=2]C:\>adb shell rm /system/etc/init.d/[/SIZE][/SIZE][SIZE=2]S00loopyst
[/SIZE][SIZE=2]
[/SIZE][SIZE=2]C:\>
[/SIZE]
For the Test versions (prior to v1.0.0):
Code:
[SIZE=2][SIZE=2]C:\>adb shell rm /system/etc/init.d/S_loopy_smoothness_tweak[/SIZE][/SIZE][SIZE=2]
[/SIZE][SIZE=2]
[/SIZE][SIZE=2]C:\>
[/SIZE]
How can I make this script run first/last?
Scripts in the init.d are run in alphabetical/numerical order, following the letter "S". For example, script "S_ramboost" would run AFTER "S00loopyst", because "r" is after "l". Renaming it to "S_1ramboost" will now run that script BEFORE "S00loopyst".
How do I edit the script and add apps I use?
Open the .zip file and extract the file S00loopyst from /system/etc/init.d/. Alternatively, if installed, you can edit the file directly from the phone's init.d folder. File must be saved in UNIX format.
So I can just edit the script and add apps I use?
You can, but there is no guarantee this will actually work. Very few processes remain in memory...there is a lot of chopping and changing going on in the background. You could alter the script's timing variables, but even then results are unpredictable with anything other than what I call the resident system processes. If you're able to improve the script in any way, let us know.
Will this work on a custom ROM such as CM/MIUI?
Probably not. The "sleep" command within the screen appears to run in the foreground as opposed to the background in a stock ROM, hence making the script useless. Not to mention it may prevent anything else loading.
Are the settings permanant?
Usually. Most apps remain in the memory, although some do come and go. If you use the Task Manager to clear apps from the memory, or use the "Clear memory" option, the apps will have lose their priority when removed from the memory.
Changelog:
v1.0.2a:
Added option for "low priority" tasks.
Early script finish if 2nd loop is complete before "number of checks" is complete.
More detailed log file.
v1.0.1:
Cleaned up some invalid code.
Tested OK on rooted Samsung GT-I9000 2.3.6 ROM.
Tested OK on rooted Samsung GT-I9305T 4.1.1 ROM.
Tested NOT OK on CM 9.1 GT-I9000 ROM. Phone freezes on boot until loop is complete.
v1.0.0:
User friendly - a lot easier to configure.
Total number of processes automatically calculated (used to shorten 1st loop if all apps are in memory).
Debug file created for troubleshooting (includes "renice" pass or fail test) - can be saved to /data partition or sdcard.
Simple "Aggressive" option to increase priority of resident and other apps.
In addition to kswapd0 checking before continuing, launcher app is also checked in a loop before continuing (usually no more than ~15 seconds after start-up).
oom_adj & oom_score settings for launcher to remain resident (doesn't seem to work too well... settings don't appear to "stick").
T2:
"Smarter" script.
Checks for kswapd0 every 3 seconds until found, and then 'nice' level is set.
1st loop: checks for apps 60 times, at an interval of 3 seconds. Once an app is found in memory, 'nice' level is set, and it is not checked again during the loop. (Some apps enter and then leave the memory, which ain't helpful.)
2nd loop: checks again 6 times at an interval of 5 seconds and sets 'nice' level.
Settings are a little more user-friendly.
Debug option (if kernel stores a log file).
T1:
Sets kswapd0 'nice' level after 3 seconds.
Pauses for 15 seconds, sets 'nice' levels for other apps (many of which don't remain in memory).
Download:
Download file and transfer to SD card
Enter ClockworkMod Recovery via Vol+Up/Menu/Power button combo
Select zip and install (remove any "Test" versions before using Version 1 or above)
I'm not a Linux/Android master myself, but this actually is food for thought. I'll try and do some reading, and i would really like to hear more experienced users's opinion about it.
Thanks for the explanatory post.
Very interesting idea
Sent from my GT-I9000 using XDA Premium App
Thanks for the feedback so far. I too would like to hear what more experienced users have to say, as I've only been using linux for a few days now and have quite a lot to learn.
The other good thing about this is, if it turns out to be a good idea, I'm guessing it can be used on basically any Android device.
this is something to be looked at
interesting
I'd personally like to see more discussion on this and input from more experienced people as well so...
BUMP
A good place to start from...
Will take a look more....i am very interested on this and if u need help in scripts i can help u....
Sent from my GT-I9000 using XDA Premium App
interesting approach lpy !
FYI:
looping should be fine since it is also done, e.g. on the Galaxy Spica and CM7
but with different parameters
I have some ideas back in the back of my mind that might help with this issue (kernel-patches and other stuff)
Thanks !
edit:
related:
On Saturday, May 07, 2011 09:35:48 PM Ali Ahsan wrote:
> Hi All
>
> I have xeon server with 16 Gb Ram and no Swap memory.I am running
> cassandra server on two node in cluster.When there is high load on
> server kswapd0 kicks inn and take 100% cpu and make machine very slow
> and we need to restart out cassandra server.I have latest kernel
> 2.6.18-238.9.1.el5.Please let me know how can i fix this issue .Its
> hurting us badly this our production server any quick help will be
> appreciated.
There is more than one bug that causes this behaviour. A few related memory
managent situations (possibly responsible) may actually be avoided if you add
some swap (even if it's not used). My suggestion would be to add some swap,
set swappiness to 0 and see what happens.
/Peter
_______________
Click to expand...
Click to collapse
http://www.linux-archive.org/centos/523508-kswapd-taking-100-cpu-no-swap-system.html
Tried the script with go contacts,go sms, go launcher (edited ofcourse)
it seems to make them open instantly even when they aren't running in the background..
if some1 could make an app which make the app you use as -20 or something and if you close it or move to another one make it back to 0..
It would be really interesting to see this being controlled at Kernel level (if possible.)
I know that it contains the govenors to control the CPU and UV settings (smartass, conservative, etc.), but wouldn't it be awesome if you could determine a priority level for apps installed on your phone so that it removed a load of junk from memory?
I mean I know app developers would all start setting their apps "attention level" to -20, but if there could be an intelligent manager for this, it would make things alot faster I would think.
lttldvl said:
It would be really interesting to see this being controlled at Kernel level (if possible.)
I know that it contains the govenors to control the CPU and UV settings (smartass, conservative, etc.), but wouldn't it be awesome if you could determine a priority level for apps installed on your phone so that it removed a load of junk from memory?
I mean I know app developers would all start setting their apps "attention level" to -20, but if there could be an intelligent manager for this, it would make things alot faster I would think.
Click to expand...
Click to collapse
that s the goal , ultimately all these task killers try to achieve problem as of today is it usually creates more problems then it solves ..
having a script in init.d folder or using gsript (market app ) to run script manually on a regular basis to ensure your apk have the proper level ..
@ OP : good thread
that's really interesting approach but it has also some drawbacks. With nice you give a process more CPU time and in case that the application is not written properly you could end up with frozen system.
looping this script will eat my battery? i see it like a permament recursive process running in background.
phone will sleep properly after? cpu usage?
Indeed there is a speedup if I use parts of your script. This is an interresting approach to gain your most important task faster. I often recognized a large latency if I opened phone or sms/mms. Is their a way to preload this apps and prevent its swapping out of ram?
Edit: recognized a reliable process when updating a lot of apps at once -> no update failed message any more
using scripts should be fine and the resource consumption should not be a problem, if it is used properly
while using nice/renice will gain some benefits in controlling the priorities (i use nice too in some cases), i doubt the effectiveness if all thoese processes are set to low priorities
also, on my phone, the kswapd0 only consumes very little resources and it's not even in the top 10 in the top results but somewhere near 20
All good responses so far, and definitely making a lot of sense.
@simone201 many thanks re the script offer. There is no doubt this script can be improved, for example, having an 'if ... then' condition where once an app enters the memory, the "`pidof" changes from 0 (false) to a PID (true), and then the nice value can be set.
matematic said:
that's really interesting approach but it has also some drawbacks. With nice you give a process more CPU time and in case that the application is not written properly you could end up with frozen system.
Click to expand...
Click to collapse
Very true. -20 can be quite a dangerous setting if an app decides to play up.
lttldvl said:
I mean I know app developers would all start setting their apps "attention level" to -20, but if there could be an intelligent manager for this, it would make things alot faster I would think.
Click to expand...
Click to collapse
haha. I can see "priority wars" happening between developers and apps.
If Android doesn't take advantage of nice, I don't see why we can't. It's possible that in 12 months from now when many phones are dual core (or more?), this may have little impact, but for now this should prove very handy.
ykk_five said:
using scripts should be fine and the resource consumption should not be a problem, if it is used properly
while using nice/renice will gain some benefits in controlling the priorities (i use nice too in some cases), i doubt the effectiveness if all thoese processes are set to low priorities
also, on my phone, the kswapd0 only consumes very little resources and it's not even in the top 10 in the top results but somewhere near 20
Click to expand...
Click to collapse
I agree with all that, however, I don't really see it as a matter of "how much" it uses in terms of resources, but rather "when". My example with Angry Birds and a stock ROM, you will notice little glitches here and there, due to the work kswapd0 does. Lowering its priority still enables it to complete its task/s, but without interfering with real-time action.
Here are examples of some improvements I've noticed:
- Entering your PIN minimal/no delay
- Minimising delay with lock screen pattern/unlock (not the time it takes to wakeup, but the touchscreen response lag)
- Having smoother notifications on the status bar, and smoother pulldown menu response
- Minimising Launcher lag while Media Scanner is running (can scroll through screens without heavy pauses)
- Minimising lag when scrolling through the market while icons are still loading
- Installing/Uninstalling apps while continuing other tasks
- Minimising/eliminating intermittent lagging in gaming
- you get the idea..
The way I see it, at the very least, lowering the priority of kswapd0 already helps with the way everything runs. Setting an app's nice/renice value (if managed in a practical way) will be a bonus.
Just a quick note (uncertain if this is even related):
A couple of kernels ago (yes, i switch a lot) i noticed a large battery consumption by "Android System". This was running JVP, and DarkCore 2.7.3 i think... But it wasn't until I read this thread that I remembered that the reason I switched kernels was because of a "laggy" system. After a while the phone seemed a lot slower, and I had to reboot to get the initial speed.
Now with Galaxian kernel I have an extremely snappy phone, and the "Android System" drain is gone aswell....
How do you get the process name of an application (to edit the script)?
Edit\\ open app in app manager (astro)
I think this is an important topic, but don't see much feedback from developers.
My question as a non developer is:
is there a way for me to use this? seems like the script is already there, so it could be possible to have a flashable zip or a tutorial because different apps/versions require a different script.
Cool thing. I remember something very similar to this when I was having HTC Dream. There was scheduling app which runs similar script like this Will try it and post my opinion
Hey guys,
Seems there's a lot of ways you can improve the speed of Android in general. Some seem to be snakeoil... others, work quite well and there's proof to back it up.
I'm only interested in discussing the latter .
A lot of people have helped me gather a better understanding of Android (hyc, stinebd to name a few) in addition to a lot of Google searching. I am going to compile a list of what I have done, I would like to hear what you guys have done! Most app killer apps / app control will already be addressed, so those tools need not apply... I'm looking for real, permanent fixes here without adding more apps!
I am also trying to have topics that are easy working up to advanced. Obviously the more advanced topics are going to be harder to do. You've been warned.
So here's the disclaimer.
****DISCLAIMER****
Speed is as always relative. That basically means I don't want arguments about which build is faster. I want to argue about how to make every build faster .
Also, these tips should apply to any build, any device... they are pretty generic tips, but are obviously specific to Android, with some idiosyncrasies that apply to our port that wouldn't apply to native Android devices. Some is common sense, others are real ways to tear into the system. Hope you enjoy it!
Topic 1
Difficulty Easy - Apps/Widgets
I've noticed the number of widgets i have on my screens, or the number of apps that I have installed/are running in the background to greatly effect performance, in an obviously negative way.
Once I removed all the widgets (I only have the basic analog clock widget & the Google search widget on one desktop...) this seemed to improve general speed. One minor thing to check is if apps are set to auto/background sync. Only enable the ones you really want syncing, others just check manually.
On this same topic, replacing the launcher (the stock launcher in Android, Launcher2 is quite slow) can help immensely. I like ADW, but I've used LauncherPro in the past and it is good. Zeam also seems like a good launcher. I haven't used Go Launcher EX, I've heard good and bad things about it. Use what works best for you, try 'em all!
The last thing on this topic I would like to mention is animations. Settings -> Display -> Animation -> No animations can make the phone feel quite a bit snappier, obviously at the expense of the look/feel of the OS.
Topic 2
Difficulty Easy - Controlling app 'net Access
This leads me into the next topic, DroidWall. I've noticed that blocking apps from accessing the internet has been a very good thing - it's not so much a performance booster (although it probably does provide a little bump) it's mostly about battery life. Just be warned, if you block an app that is set to background sync, it will probably have very negative effects. Only disable an app's access to the internet with DroidWall after you've checked that app's background sync feature is disabled. I have a few apps allowed in DroidWall, and the rest are blocked. You can "whitelist" everything and check apps you want to block, or "blacklist" everything and check the apps you want to allow. It's a little annoying to remember to enable/disable DroidWall (I use the DroidWall widget to enable/disable it globally) but if you do, it is much better - you have complete control over how apps access the 'net on your device. It is available on the Market.
Topic 3
Difficulty Moderate - SD cache/readahead tweaking
The only reason I'm calling this one 'moderate' is the number of choices you have for settings for this... It's basically telling the SD card how much to hold on to or... read "ahead" if you will . This was turned way up in FRX07, (from 256kb to 2048kb or 2mb...) and I think this might be the source of a lot of the complaints of 'mini-resets' if you will where the boot animation is suddenly seen after a long system hang...
So some cards will work better with a larger setting - I've heard some with spankin new C6 cards that said 3072kb or 3mb was a good setting. Others have found a sweet spot at 256kb or 1024kb (1mb).
There are two ways of doing this - you can hack the init in the rootfs and adjust the setting manually, or be lazy like me and use SD Booster (from the Market). Adjusts the same settings, and they are applied immediately!
I would like to find a "sweet spot" - a good default if you will. Can folks test out 512kb and 1024kb, see if you have any more mini-resets within Android or any other slowness, etc... Obviously this isn't a cure-all for the slowness or the mini-resets, what we're looking to do is mitigate the effects. So let's focus on that, thanks!
Topic 4
Difficulty Moderate - Overclocking
Overclocking is obviously one relatively easy way to improve the speed of Android. In your startup.txt, add a line
Code:
acpuclock.oc_freq_khz=710400
for example to overclock to 710.4mhz. How did I find this value? I actually put in 714000, but if you look at dmesg near the beginning you'll see "ACPU running at ..." - that's what clock is the actual maximum. It goes in 19.2khz increments.
Feel free to experiment with how high your phone can go, just be warned that the higher you go the potential for failure goes up as well . Phone shouldn't blow up, but it might not work correctly or at all. Rebooting and scaling it back will fix it.
Here's the full *example* startup.txt:
Code:
set ramsize 0x10000000
set ramaddr 0x10000000
set mtype 2292
set KERNEL zImage
set initrd initrd.gz
set cmdline "lcd.density=240 msmvkeyb_toggle=off gsensor_axis=2,1,3 pm.sleep_mode=1 physkeyboard=rhod400 acpuclock.oc_freq_khz=710400"
boot
You can put the command anywhere in the cmdline section, just make sure it's between the quotes and at least one space between each command.
Topic 5
Difficulty Advanced - How Android Manages Memory/apps
Ok, I'm going to take two approaches to this. The first, is the full explanation on how Android manages memory.
Please feel free to read the post I originally read that inspired me to start looking at this stuff - How to configure Android's *internal* taskkiller. It was very helpful for me to grasp how Android manages applications. This is the reason why application killers are not a good thing...
If you want to do it manually, Starfox suggests:
Code:
echo "1536,3072,8192,10240,12288,20480" > /sys/module/lowmemorykiller/parameters/minfree
To try to do these commands, adb is very useful. Once you get adb shell working, then you just need to "su" (provides 'super user' privileges (root)) and put in the echo command above ^^.
I had another user (thanks icevapor) suggest this script -
[Script] V6 SuperCharger! HTK & BulletProof Launchers! The ONLY Android MEMORY FIXER!
I tried it myself, and it works very well. This thread is a little overwhelming, but the jist of it is this:
Install Script Manager (on the Market)
Run the V6 SuperCharger script. I use "Aggressive 1 Settings" (#2) and then I use the OOM Grouping Fixes & "Hard to Kill" launcher (#17)
Point Script Manager to run /data/99SuperCharger.sh to run as root & on boot. This will ensure the tweaks are reapplied after a reboot.
Topic 6
Difficulty Advanced - Managing Apps that auto-start on boot
This is one of the most annoying things in Android. When you have no apps installed, it seems very fast. Then you install apps, and you never seem to get that original speed back... Now you can!
This is kind of difficult to do, I am still getting the hang of it... but here goes. All credit goes to hyc, his original post.
The basic idea here is you run a logcat (adb logcat is easiest here, or you can use GetLogs to pull logcat...) Look in this log for "for broadcast" and find apps that start on boot. For example,
Code:
Line 41: I/ActivityManager( 1394): Start proc nextapp.systempanel for broadcast nextapp.systempanel/.monitorservice.BootReceiver: pid=1752 uid=10060 gids={3003, 1015}
Notice there are two sides of the "for broadcast". The name of the package (nextapp.systempanel) and the name of the service, "nextapp.systempanel/.monitorservice.BootReceive". I made the mistake of disabling the app (the left side). Do not do this, you want to disable the right side!
So in the shell,
Code:
pm disable nextapp.systempanel/.monitorservice.BootReceive
This will be persistent across boots, it will go with your data.img.
Obviously this was just one example of an app to disable. So long as you disable the right side (after the 'for broadcast') you shouldn't disable anything that will cause a serious problem. The apps should still work, but for example if you disable Google Voice you won't get messages until you open the app. So think about that... You disable Titanium Backup schedules.BootReceiver, the schedules for Titanium Backup (if you have any) won't run. Stuff like that. Disable calendar, you won't get calendar events... Disable clock no alarms. Get it? Good. I have been rebooting several times, and I keep checking what is set to start on boot. I'm not quite happy with it yet, but there's some things I'm leery of disabling. Just be wary, if you do disable something and don't like it - just pm enable <whatever you disabled>.
Now experiment away! The one caveat is if you do break something with pm disable (and it's serious) you might get a failure to boot. It really depends on how bad you mess up. If you make a copy of your data.img before you start making these changes, you can revert to that data.img and start back there.
Alright guys. Going to use this thread as a way to brainstorm about ways to improve the speed. Read up what I've posted, let me know if I did anything wrong... Also let me know what you guys do to improve speed!
Don't care about what build you're running, this thread isn't about what build is fastest - this is a how do I make every build faster thread.
I also realize I posted this in the Rhodium section - I want to see if there's any RAPH-specific tweaks that others should be made aware of!
Slightly off topic post
I do realize all of us are looking for ways to improve over all performance but what about a means to restore these settings or even possibly a means to run a script to apply the setting(s)? Perhaps something like XDA_UC for winomo but for Android. Or should there be something like this available already and I'm just the last person getting to the party (or not)?
R^7Z said:
I do realize all of us are looking for ways to improve over all performance but what about a means to restore these settings or even possibly a means to run a script to apply the setting(s)? Perhaps something like XDA_UC for winomo but for Android. Or should there be something like this available already and I'm just the last person getting to the party (or not)?
Click to expand...
Click to collapse
I guess you didn't read the first post... I wanted to do all this without apps.
You can find an app to tweak almost all of these things. If you read the article, there's an app to adjust the values for minfree. As for the pm disable stuff, there's an app out there but hyc said the one he found was a paid-for only app. One of those task killer apps that with the paid version has a startup manager - he didn't mention which one, but I agree with him... I'd rather just do it myself.
So the two 'advanced' topics can easily be handled with an app. I don't want to do it with apps, if you do more power to you.
Not really looking for an app but I guess my post mentioned XDA_UC. Either case, I am just looking for a way to add commands without having to redo the command for each re-run start over of XDAndroid; like the froyo.user.conf file?
I usually remove the androidapps and media folders for the initial start. Seems to really boot much faster for both of my RAPHs (100 and 110)
R^7Z said:
Not really looking for an app but I guess my post mentioned XDA_UC. Either case, I am just looking for a way to add commands without having to redo the command for each re-run start over of XDAndroid; like the froyo.user.conf file?
I usually remove the androidapps and media folders for the initial start. Seems to really boot much faster for both of my RAPHs (100 and 110)
Click to expand...
Click to collapse
...Do you put the folders back in afterwards?
The pm disable stuff is persistent, as I said. The minfree stuff, in lieu of an app I would think either putting the echo command in froyo.user.conf, or I think you would be able to make the change directly to the init.rc (or init.cfg/init.froyo.rc for our port/FRX builds). Definitely easier to just put the echo command in the user.conf file.
Correct! Either that or I compress/zip the folders (again only for the initial start/boot) and uncompress after the boot. Quite obviously, the latter would require more space but you wouldn't require a reboot, less you wanted use of the androidapps folder(drag-n-drop app/XDAndroid supported method).
That PM stuff makes my head swirl; bad enough I stare at numbers each day for about 8 hours
R^7Z said:
That PM stuff makes my head swirl; bad enough I stare at numbers each day for about 8 hours
Click to expand...
Click to collapse
Yea, it took me a while to sort it out. I'm definitely doing it correctly now, but it took a few 'oh crap' issues before I got it right. I also think I can trim it more, but I want to dedicate more time to testing it. The first batch I romped thru, I knew I didn't want things like Pandora starting at boot. You might want to take a look at it, and just look for the stuff that sticks out at first. Don't mess with it if you don't know what it does, and you'll be safe.
The issue that the pm stuff solves is having a lot of apps - a lot of these apps are designed to start on boot, whether you want them to or not. This gives power users true control over the startup of apps... It definitely helped my phone out. All of the 'tweaks' combined have helped tremendously in fact. I have been on a mission the last few days, and I've definitely narrowed down some things that really seem to make a difference on my device. There is a lot of fluff & BS around how to make a phone faster/run better, I wanted to have a thread where all the facts were laid out, without any fluff (hopefully).
cpu freq of 710400 is working well on my raph800 so far, havent noticed too much change in setting minfree but i usually keep as much programs killed as possible.
About to issue the following pm disable commands
Code:
pm disable com.android.voicedialer/.VoiceDialerReceiver
pm disable com.pandora.android/.api.bluetooth.AutoStartReceiver
pm disable com.paxmodept.palringo.android.main/com.palringo.android.integration.AndroidTaskScheduler$Receiver
pm disable com.rechild.advancedtaskkiller/.AutoStartReceiver
pm disable com.google.android.apps.maps/com.google.googlenav.friend.android.ServiceReceiver
runs fine as hell yo.
We should test out: http://forum.xda-developers.com/showthread.php?t=991276
I use it on my epic4g... I'll have to stick it on my wifes tp2.
icevapor said:
We should test out: http://forum.xda-developers.com/showthread.php?t=991276
I use it on my epic4g... I'll have to stick it on my wifes tp2.
Click to expand...
Click to collapse
Hrm. There's some interesting topics there that I haven't addressed.
Not sure that script as-is should be applied to our phones, but most of it sounds pretty good.
Wow. I am impressed with that script. Kinda wish I had found that earlier to be honest... I can pretty much remove all the minfree discussion from my post in lieu of this script .
I ran it, and everything seems fine. I already had values that were pretty similar to what he had, so I haven't really noticed a huge difference in the other things the script did, but time will tell. I'm also curious if it gets reapplied correctly on boot.
Thanks for the link tho, assuming I can get it to work well (which so far it seems to work just fine) I will integrate it into the first post and probably remove all the blather on minfree. I'll keep the links up in case people want to read it, but having this script definitely circumvents any need to understand it yourself .
Well, it seemed to work... but I need to sort out how to get it persistent across reboots.
Alrighty, got it all sorted using Script Manager.
I've updated the first post with the details on how to use this script. Thanks again icevapor!
not sure if its placebo effect (haven't been testing it long yet) but i set the following settings and it felt even faster on RAPH800 (note: only deviations from defaults are listed)
froyo.user.conf -> compcache -> cc_disksize=86
froyo.user.conf -> compcache -> cc_memlimit=58
froyo.user.conf -> custom_shells -> echo "1536,3072,8192,12288,16384,24576" > /sys/module/lowmemorykiller/parameters/minfree
startup.txt -> acpuclock.oc_freq_khz=710400
Hi,
sorry for the noob question but...how can I check if an application is set to auto/background sync? And how I can enable/disable it for a single application?
Thanks
automatic_jack said:
Hi,
sorry for the noob question but...how can I check if an application is set to auto/background sync? And how I can enable/disable it for a single application?
Thanks
Click to expand...
Click to collapse
It's all app-specific. In Google Voice for example, you hit menu, more, settings, sync & notifications - this app has two options, "background data" and "synchronize inbox". To properly sync the inbox, bg data must be enabled.
Every app is different, and not all apps have these options - or even similar options. Just poke around the apps you have in question and see what settings are available.
arrrghhh said:
It's all app-specific. In Google Voice for example, you hit menu, more, settings, sync & notifications - this app has two options, "background data" and "synchronize inbox". To properly sync the inbox, bg data must be enabled.
Every app is different, and not all apps have these options - or even similar options. Just poke around the apps you have in question and see what settings are available.
Click to expand...
Click to collapse
ah, ok...thanks for the reply
Squirrels said:
froyo.user.conf -> custom_shells -> echo "1536,3072,8192,12288,16384,24576" > /sys/module/lowmemorykiller/parameters/minfree
Click to expand...
Click to collapse
Do you have compcache enabled or disabled?
This may seem slightly askew from the current conversation but hear me out.
So far, with what builds I've made for myself, I have been able to "strip" the entire build down to just bare essentials just by removing apps from the /system/app or /data folder BEFORE installing a build.
Non-essentials for me would be:
Car Home
Google Search (same as built in search anyway)
Music (I tend to use a different player for this)
Talk
Voice Dialer
and any pre-installed apps that may come with the build.
LauncherPro plus is my launcher of choice, with eye candy enabled.
Of course this is a slightly different platform (HTC Kaiser), but should work the same way for HaReT or XAndroid builds as well. Also, some of the commands entered could be done with Terminal Emulator, giving you a POSIX terminal with "su" already enabled.
Just my $.02
Hi all,
Launcher2 and ADW are both open source so I can use them...but, who is faster?
Thanks
automatic_jack said:
Hi all,
Launcher2 and ADW are both open source so I can use them...but, who is faster?
Thanks
Click to expand...
Click to collapse
I like ADW myself. Launcher2 doesn't seem so great...
I especially like a launcher that can rotate with the phone. Plus the other options ADW provides are very nice IMHO.
Try both, use what works best for you .
I AM NOT RESPONSIBLE FOR ANY NEGATIVE IMPACTS OR CONSEQUENCES ON YOUR PHONE IF YOU SO CHOOSE TO USE THESE TIPS.
I've created a couple threads on the ZTE U950 and LG G2, and one problem is the battery life. The battery cannot come out of these devices and thus we cannot combat this with a bulkier, beefier replacement for heavy usage. Charging constantly is something I try to avoid, so these are a few simple tips that can help optimize your battery life (and that APPLY to ANY PHONE):
TIPS
BATTERY
1a) Buy and download CPU Sleeper (root required). There are two versions, one for dual-cores, and the other for quad-cores. Essentially, when a phone is "sleeping", it is actually still running all its cores, helping drain battery faster. This app turns off all but one core when it is "sleeping" so that your battery is not drained nearly as fast.
BATTERY
1b) To take this step a bit further you can download a free app called Multicore CPU Control. In this app you can control your other cores. You can setup profiles to turn on or off cores, and setup each core with different governors. On my LG G2, I setup a profile to only have one core running at 960MHz (2.2GHz originally) after using the steps from below. If you plan to only run one core, then you do not need to buy CPU Sleeper.
NOTES ON 1b: Multicore CPU Control is the name when installed, it is called CPU Performance Control Free on the Google Play Store (either name will work on Google Play). The program needs to be turned on after each boot. When first setting up a profile save it and edit it in order to manipulate the other cores available. The app does not always apply a profile even if it has already been selected. To turn on a profile, click on the profile desired and go to the CPU Monitor tab to check if it has been applied. If not, repeat the process until it does (it usually takes me about 3 times at most).
BATTERY/RAM
2) Download Greenify (root required), a great free app! Sometimes a user does not have a ROM with a kill all button, so pesky apps just stay on without consent. This app allows a user to turn off any app that may want to run in your background, and even shows you which apps are currently running. Apps like Facebook, Talkatone, etc. can all be stopped even if your "task killer" supposedly took care of them.
BATTERY
3a) Wakelock Detector-Save Battery is a free app that checks for apps that continue to work while the phone is "asleep". While Greenify will display the most troublesome apps, this app will help discover any other apps that are running without consent.
BATTERY/RAM
3b) If Greenify does not show the apps discovered in Wakelock Detector-Save Battery, then download Disable Services (root required). This free app allows a user to disable an entire service, or just parts of a service that are bothersome. Click on a service/app to find out what other services accompany it. Read the accompanying services and discern whether or not the service is needed. A good place to start in this app is to check any service/app that has a blue number next to it.
EXAMPLE 3b: I use the Outlook app a lot, but sometimes it gets annoying with updates for insignificant email. I can open Wakelock Detector-Save Battery and click the Outlook app. I turn off "AppWidgetUpdateService" to disable Outlook email updates. Not all services have obvious names, so be careful on system apps if performing trial-and-error.
BATTERY/RAM
3) Buy and download BetterBatteryStats (CPU Spy Reborn/Plus is FREE and only shows CPU states). This app tells me what CPU States are used the most often and is what I download first before my next step. A user can also determine battery-draining apps and turn those off. If turning off those apps is not possible through Settings>Apps just Greenify them!
BATTERY
4) Underclocking. This is an amazing step for saving battery! If you have ran BetterBatteryStats for at least a day, this will come in handy and is highly recommended. You can use numerous programs like SetCPU or Voltage Control to set the clock of the CPU. The key is to find a point that will still be responsive, yet lower than the maximum.
EXAMPLE 4: For this example I will be using my ZTE U950 and Voltage Control. According to BetterBatteryStats, my most used clock was at 1.2GHz and 860MHz. I left my minimum clock at the lowest possible setting, while my maximum clock I changed to 860MHz. I ran this for a few days and saw a noticeable difference in battery life. Another important part to this if choosing the right I/O Scheduler and CPU Governor. I found the default I/O Schedule ("cfq") to perform the best, despite "noop" being good for sluggish memory. "Powersave" is a good Governor at stock CPU speeds, but it will not get a user the savings of power that a step like this will. I tested with this Governor with this step and got horrible reaction times and would often need to restart the phone. The best results I have are with "ondemand" and "interactive". I am currently using "interactive" with a maximum clock of 475MHz! I arrived at that number after checking my BetterBatteryStats while running at 860MHz and found that to be the next most used clock. Now my battery is lasting about twice as long as it normally did! My phone's response time is a bit slower at this low clock speed, but that can combated...
BATTERY/RAM/SPEED
4b) (IF YOU HAVE INIT.D SKIP TO STEP 4c) My LG G2 is underclocked to 960MHz, as noted in step 1b. I am saving quite a bit of battery, but the UI response can lag a lot at times. The use of boot scripts can be helpful to compensate for this. However, my LG G2 does not have init.d support. There are numerous threads that explain how to get init.d support for a lacking Android phone. The simplest method is to install an app from Google Play. I use one called Init.d-Installer just because it forces the phone to reboot once it has installed; others do not seem to do anything to inform a user if they have received init.d support
BATTERY/RAM/SPEED
4c) Download a script called V6 SuperCharger. The thread may seem daunting, but it is fairly easy to install. Download the newest PDF and change it to TXT. Ensure you have init.d support, BusyBox installed (also in the thread if needed), and SuperSU. Run the script in a free app like SManager with SU permissions and follow the instructions. This script gives the ability to enhance speed and power. I install this in order to ensure my UI stays responsive, and LG G2 runs almost at stock speeds (alongside all my other enhancements)!
BATTERY
5) Undervolting (root required/custom kernel required). This is also a great way to save battery. I decrease the voltage in steps of 25 and test from there. If I find no quirks, I leave it. If I find sluggishness or have random phone reboots, I increase by increments of 25 (or 12.5) until I find something stable.
Most phones will not allow undervolting without a custom kernel. To see whether a phone can undervolt or not download, Sytem Tuner. There is a free and paid (Pro) version of this app, but the free one should be sufficient for what we want to do. After installing, open the app and click on the Voltage settings tile on the left-lower side of the screen. All the phone's CPU MHz steps and the amount of voltage applied to each step can be viewed. At the bottom of the screen are buttons to increase or decrease voltage in 12.5 increments (which will apply to all steps). If the -12.5 button is clicked and the values of all the steps drop, then a phone can undervolt. Additionally, System Tuner allows a phone to manually apply undervolting to each step if wanted.
To test undervolting, just push the decrease button until the phone freezes up. There is no harm to your phone or CPU as neither are being overpowered (just the opposite), and a reboot after freezing will reset the phone to default voltage settings. A - 75MHz drop is normal for a phone while remaining stable; and in a lot of cases -100MHz is achievable.
NOTE: Tips #4 & #5 also can be applied to GPUs.
NOTE 2: One thing that should be mentioned is to be careful about putting more than one app that controls CPU clocks. They can read differently and trump the other when used in combination. Instead, install and use one at a time to get more accurate readings. The same should apply to undervolting apps.
BATTERY/RAM
6) A user can change the Dalvik cache a bit to see if that helps optimize RAM, and possibly battery. I did quite a few tests for these to see how they performed. I think the only reason I noticed any changes immediately is because of how far underclocked my CPU is. Anyways, the best results I was able to get with my ZTE U950 was as follows:
124m - dalvik.vm.heapsize (2nd one, not 1st)
8m - dalvik.vm.heapstartsize
For other phones, these are the items to trial-and-error with:
davilk.vm.heapsize (may be more than one at different values)
davilk.vm.heapstartsize
davilk.vm.heapgrowthlimit (may be more than one at different values)
A user can change these settings by downloading an app like Build.Prop from Google Play. I did notice my battery seemed to drain slower with these changed. The RAM was the best optimized for the self-made tests I performed and was nearly the best in all the tests I had ran. A user may or may not notice any differences unless they multitask a lot.
BATTERY/RAM/SPEED
7) All other well-known methods apply as well:
A. Battery Saver apps/settings
B. Battery Calibration apps
C. Refrain from the use of widgets
D. Automatic Brightness apps/settings
E. Small Screen Times before Screen Sleep
F. Turn Off WiFi and/or Data when not needed
G. Task Killers apps/settings