[[Speed Improvements]] Brainstorming & Testing Thread!!

**arrrghhh** · #1 (**permalink**) 08-14-2011, 08:19 PM

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.

**arrrghhh** · #2 (**permalink**) 08-14-2011, 08:19 PM

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.

**arrrghhh** · #3 (**permalink**) 08-14-2011, 08:19 PM

I've noticed Starfox's test kernel with that turbo mode enabled actually creates quite a boon. It's RHOD-only, so I didn't include it in the first post...

nerys · #4 (**permalink**) 08-15-2011, 01:21 AM

acpuclock.oc_freq_khz=710400

is that something that gets added to the cmdline section or an entire line of its own?

**arrrghhh** · #5 (**permalink**) 08-15-2011, 01:23 AM

Quote:

Originally Posted by nerys

acpuclock.oc_freq_khz=710400

is that something that gets added to the cmdline section or an entire line of its own?

cmdline section, I need to expand on that section...

Edit - updated that section. Thanks for the reminder

.

nerys · #6 (**permalink**) 08-15-2011, 01:35 AM

I guessed that and tried it. did not blow up on me

once I let it load IT DOES seem quite a bit spunkier now. the gui is not much faster (but not intolerable) but apps LOAD quite a bit faster now at least they seem to so I assume its working. Now to go hunt for an auto killer since it seems to run an awful lot of background apps that I just don't need running in the background. (like gv and slacker etc..)

**arrrghhh** · #7 (**permalink**) 08-15-2011, 01:41 AM

Quote:

Originally Posted by nerys

I guessed that and tried it. did not blow up on me

once I let it load IT DOES seem quite a bit spunkier now. the gui is not much faster (but not intolerable) but apps LOAD quite a bit faster now at least they seem to so I assume its working. Now to go hunt for an auto killer since it seems to run an awful lot of background apps that I just don't need running in the background. (like gv and slacker etc..)

That's what the PM commands are for. If you go thru it (it's a pain, I know...) it'll disable these apps from starting on boot automatically (I had a ton when I started!) The problem with task killer apps is they don't solve that problem.

The other part of the problem is freeing up memory appropriately, which is hopefully addressed in the minfree stuff. I'd be curious of there's better values, I am going to run them for a while and see if changing them does make a difference.

It's not nearly as pretty, but using ADW, disabling all animations in Android and ADW have made things really, really snappy.

nerys · #8 (**permalink**) 08-15-2011, 01:55 AM

maybe you did explain it clearly and I am unable to understand (lack of linux command line knowledge??)

but how do I know "WHAT" to type after pm ? ie where did you get the info? seems to be this logcat thing - where do I get that how do I read it?

there are some apps that just don't make sense (for me) to run in the background. for example if ebay is running in the background I am ok with that since it performs a function I desire. but I can not think of a reason why slacker should be in the background on boot or ever. same with quite a few other apps.

I want then to run when I run them but when they are backgrounded I want them dead

how do I do this?

**arrrghhh** · #9 (**permalink**) 08-15-2011, 10:30 AM

Quote:

Originally Posted by nerys

maybe you did explain it clearly and I am unable to understand (lack of linux command line knowledge??)

but how do I know "WHAT" to type after pm ? ie where did you get the info? seems to be this logcat thing - where do I get that how do I read it?

there are some apps that just don't make sense (for me) to run in the background. for example if ebay is running in the background I am ok with that since it performs a function I desire. but I can not think of a reason why slacker should be in the background on boot or ever. same with quite a few other apps.

I want then to run when I run them but when they are backgrounded I want them dead

how do I do this?

Well that's what this thread is for, to discuss how to cut down on apps that start on boot, and how to manage memory in Android.

If you read the links, I provide one to the FAQ that jumps directly to the ADB section. This in turn has a link titled 'logs' that explains how you pull logs.

The commands can be entered in a local console on the phone (ConnectBot, Terminal Emulator, whatever) or thru adb. I find thru adb to be much easier, once you get it setup of course. I guess I need to flesh out a how-to a little more, gimmie time I threw this together kinda quickly and on a whim. Reading the links I provided & searching is always a good practice, but I will try to flesh out the explanations...

nerys · #10 (**permalink**) 08-15-2011, 10:35 AM

now are the processes I see running in say estaskmanager "different" from what your talking about here? or the same?

if the same the solution is really easy. I got this program called auto killer memory optimizer. its basically a front end to "adjust" the built in functionality of android to handle automated task closure to preserve operating memory.

ie safe

for the most part (I don't mess with the first half just the background stuff)

I set it all to 75mb and that keeps pretty much anything not running "active" out of memory and REALLY seems to improve performance. though how much of that is from the OC and how much from this I don't know but it does help.

I will await the howto and I appreciate you doing it too

I make a lot of how to's in my arena's (rocketry and photography) and I know how much of a pain them can be to do