Database Users

FAQ: Why You Shouldn’t Be Using a Task Killer with Android (geekfor.me)

Here's an article posted at http://geekfor.me that is by far the best explanation I've ever seen on this issue:
flipz: said:
FAQ: Why You Shouldn’t Be Using a Task Killer with Android
I see this come up over and over again. People saying that a task is running in the background and they think it is killing their battery or hogging all of their memory. So their natural reaction is to download a program made to kill tasks. Here’s the thing… you are likely doing more harm than good by killing tasks that aren’t ready to end. I was the same way when I first got my CDMA Hero. There were tons of things running that I didn’t want so I just kept killing them. After a few weeks I realized that if I stopped using a task killer (and totally uninstalled it in fact) my phone actually began to run better! The applications would close themselves and things just seemed to be running better. I get that there may be short term benefits from clearing a task, but you should still take the time to read through this.
Here is some information directly from Android’s developer page. I have put the important parts in bold. This is quite a lengthy read but honestly I think it’s important. If you want the full read then you can check out the dev page here. If you just want the quick TL;DNR version then scroll to the bottom.
Google: said:
By default, every application runs in its own Linux process. Android starts the process when any of the application's code needs to be executed, and shuts down the process when it's no longer needed and system resources are required by other applications.
A content provider is active only while it's responding to a request from a ContentResolver. And a broadcast receiver is active only while it's responding to a broadcast message. So there's no need to explicitly shut down these components.
Activities, on the other hand, provide the user interface. They're in a long-running conversation with the user and may remain active, even when idle, as long as the conversation continues. Similarly, services may also remain running for a long time. So Android has methods to shut down activities and services in an orderly way:
An activity can be shut down by calling its finish() method. One activity can shut down another activity (one it started with startActivityForResult()) by calling finishActivity().
A service can be stopped by calling its stopSelf() method, or by calling Context.stopService().
Components might also be shut down by the system when they are no longer being used or when Android must reclaim memory for more active components.
If the user leaves a task for a long time, the system clears the task of all activities except the root activity. When the user returns to the task again, it's as the user left it, except that only the initial activity is present. The idea is that, after a time, users will likely have abandoned what they were doing before and are returning to the task to begin something new.
Click to expand...
Click to collapse
Google: said:
Activity lifecycle
An activity has essentially three states:
It is active or running when it is in the foreground of the screen (at the top of the activity stack for the current task). This is the activity that is the focus for the user's actions.
It is paused if it has lost focus but is still visible to the user. That is, another activity lies on top of it and that activity either is transparent or doesn't cover the full screen, so some of the paused activity can show through. A paused activity is completely alive (it maintains all state and member information and remains attached to the window manager), but can be killed by the system in extreme low memory situations.
It is stopped if it is completely obscured by another activity. It still retains all state and member information. However, it is no longer visible to the user so its window is hidden and it will often be killed by the system when memory is needed elsewhere.
If an activity is paused or stopped, the system can drop it from memory either by asking it to finish (calling its finish() method), or simply killing its process. When it is displayed again to the user, it must be completely restarted and restored to its previous state.
The foreground lifetime of an activity happens between a call to onResume() until a corresponding call to onPause(). During this time, the activity is in front of all other activities on screen and is interacting with the user. An activity can frequently transition between the resumed and paused states - for example, onPause() is called when the device goes to sleep or when a new activity is started, onResume() is called when an activity result or a new intent is delivered. Therefore, the code in these two methods should be fairly lightweight.
Click to expand...
Click to collapse
The following diagram illustrates these loops and the paths an activity may take between states. The colored ovals are major states the activity can be in. The square rectangles represent the callback methods you can implement to perform operations when the activity transitions between states.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
So… the TL;DNR Version:
Android is hard coded to automatically kill a task when more memory is needed.
Android is hard coded to automatically kill a task when it's done doing what it needs to do.
Android is hard coded to automatically kill a task when you haven't returned to it in a long time.
Most services (while possibly running in the background) use very little memory when not actively doing something.
A content provider is only doing something when there is a notification for it to give. Otherwise it uses very little memory.
Killing a process when it isn't ready only causes it to have to reload itself and start from scratch when it's needed again.
Because a task is likely running in the background for a reason, killing it will only cause it to re-spawn as soon as the activity that was using it looks for it again. And it will just have to start over again.
Killing certain processes can have undesirable side effects. Not receiving text messages, alarms not going off, and force closes just to name a few.
The only true way to prevent something from running at all on your phone would be to uninstall the .apk.
Most applications will exit themselves if you get out of it by hitting "back" until it closes rather than hitting the "home" button. But even with hitting home, Android will eventually kill it once it's been in the background for a while.
Questions? Concerns? Feel that I’m wrong? Comment below and let’s discuss!
Addendum:
One thing that I forgot to even address here is that memory works a bit differently in linux than it does in Windows. In general the way memory works is you really only need as much as you plan on using. So if your combined running programs use 100mb of memory, 150mb is more than enough. There is no need to clear what's running in memory before you hit that 150mb cap. Now in Windows it seems that the system performs a bit better when you have less stuff in memory, even if it's not full. No doubt those who have been on computers for a while will remember there used to be programs that could clear your memory in Windows also.
Linux however isn't generally affected by this. While I admit that I don't know the architecture and reason for this& linux will run the same regardless of if you have 20mb free memory or 200mb. And as I outlined above, Android will automatically start to kill applications if you do get low on memory! Stealing a quote from Chris Johnston, Buffers and cache in RAM being cleared is silly. Imagine a professor, who rather than writing all the way across the chalkboard, finishes a sentence and immediately erases and starts writing in the upper left corner AGAIN and AGAIN and AGAIN OR imagine you like a song. You record it to the beginning of a cassette tape. When you want a new song, do you re-record over the first song or record after it?"
I have also seen people incorrectly assume that the more memory in use, the faster their battery will die. This would actually be more attributed to the amount of processor cycles (CPU %) going on and not the amount of memory being taken up by a certain program. However, that does lead to a good point! When can a task manager be a good thing?? To help you determine what IS slowing down your phone; what may actually be draining your battery faster. That is actually what helped us discover that there appears to be a bug still left over from 1.5 that is causing slow downs on our CDMA Hero's even today. While an item using up memory isn't going to hurt things, an item chewing through your CPU absolutely will. Now I still don't suggest using a task killer to kill a program that is using up your processor (unless of course it is a zombie process that is going crazy, but you should probably just reboot in that case). But it can help you see what's going on with your phone.
I hope this has helped someone. With all of that said& I always encourage experimenting. It is your phone, and you can do with it what you please. If you swear that a task killer makes your phone amazing, then by all means use it! Thanks for reading.​
Click to expand...
Click to collapse
Another great resource:
A video from Google's Android Team:
Androidology - Part 2 of 3 - Application Lifecycle
http://www.youtube.com/watch?v=ITfRuRkf2TM​
And finally:
Check out the application "Task Manager". You'll notice dozens of processes running that you didn't even know were running. Here's my phone right now:
Look at the CPU usage column (the rightmost column) and notice that almost everything is at 0%. (The exception is TaskManager which is constantly polling since it's the active app. Menu -> Quit stops it.)
This is the best visualization that killing "running" apps will do nothing, since they're not really doing anything anyway. I have all these apps open yet they're all using 0% CPU. And I have "only" 47 MB free.
From monitoring this over the weeks, I've had as many as 60+ processes listed, and as few as 10. I've had as high as 200+ MB free and as low as 30 MB.
And my phone ran just the same. ​
Get rid of all your task killers for a week (and get WatchDog instead) and see how your phone feels.
Hope this helps clear up any confusion.
.

Paul is always great for good information. Everyone should look over his comment's to learn new things
Got a question though, with certain apps like Music and SIPagent there's not a way to close them. I can only pause music and there's no way to exit SIPagent without using a task killer. Shouldn't I use a task killer on these two applications?

ap3604 said:
Paul is always great for good information. Everyone should look over his comment's to learn new things
Got a question though, with certain apps like Music and SIPagent there's not a way to close them. I can only pause music and there's no way to exit SIPagent without using a task killer. Shouldn't I use a task killer on these two applications?
Click to expand...
Click to collapse
that's a good question; some apps doesn't have that quit button, like the Skyfire browser, so if i were to use the browser and close it, will still be running in the background? shouldn't i have to kill that app somehow?
anyway, will remove task killers now and give it a shot

Great thread as always, Paul, but which "Task Manager" are you talking about?
http://www.appbrain.com/search?q=task+manager
There are quite a few
I don't use a task manager, but I *have* used SeePU++'s task kill feature a couple times.
I think I found it:
http://www.appbrain.com/app/com.houmiak.taskmanager
And if you guys don't believe Paul:

jblazea50 said:
that's a good question; some apps doesn't have that quit button, like the Skyfire browser, so if i were to use the browser and close it, will still be running in the background? shouldn't i have to kill that app somehow?
anyway, will remove task killers now and give it a shot
Click to expand...
Click to collapse
They all work the same way as described in the post. You don't have to quite Skyfire, the Music app, SIPagent, or anything at all. Read through the post again, the Android OS will stop those when it needs memory.
For example, if Music is playing, it asks the Android system to consider it foreground, so it will never get forced to quit. But when music is paused it just runs as a normal app. When Android needs the memory, it force quits it immediately.
Same with Skyfire, it will remain loaded in the background if no other process needs the memory. This way if you leave and go back to it quickly it will be there, and won't have to reload. When something else needs the memory Android closes Skyfire. If you force it to close all the time, you only force it to load more often when you need it again, wasting time and battery life.

So how do I get more ram?

muncheese said:
So how do I get more ram?
Click to expand...
Click to collapse
You don't. Applications will be closed automatically by the OS when you need more RAM.

Clarkster said:
They all work the same way as described in the post. You don't have to quite Skyfire, the Music app, SIPagent, or anything at all. Read through the post again, the Android OS will stop those when it needs memory.
For example, if Music is playing, it asks the Android system to consider it foreground, so it will never get forced to quit. But when music is paused it just runs as a normal app. When Android needs the memory, it force quits it immediately.
Same with Skyfire, it will remain loaded in the background if no other process needs the memory. This way if you leave and go back to it quickly it will be there, and won't have to reload. When something else needs the memory Android closes Skyfire. If you force it to close all the time, you only force it to load more often when you need it again, wasting time and battery life.
Click to expand...
Click to collapse
thanks for the explanation; i already removed the task killers from my phone and will see how it goes

muncheese said:
So how do I get more ram?
Click to expand...
Click to collapse
You're in luck my friend!
Here you go:
http://www.downloadmoreram.com/index.html
Your phone will FLY!

Paul22000 said:
You're in luck my friend!
Here you go:
http://www.downloadmoreram.com/index.html
Your phone will FLY!
Click to expand...
Click to collapse
Awesome, I left a little on the server for you guys.

Re: FAQ: Why You Shouldn’t Be Using a Task Killer with Android (geekfor.me)
I have a problem with the way android does this multitasking because when I send opera or skyfire to the background, I want it to stay there no matter what. Most of the time It's still there when I switch back to it in a few moments. But sometimes the OS has decided to close it, even though I only switched away a few moments ago to read a quick email, and my webpage is completely gone. This is a major problem for me. It's especially maddening when you then see that the OS closed opera or sky fire to pre load a bunch of apps that I haven't used in a month. Like sms backup. That's an app that I need once a month to back up my texts. So I DON'T want to uninstall it.
-------------------------------------
Sent via the XDA Tapatalk App

I agree with your post but there are a few reasons to have an app that allows you to control your apps and yes, kill them from time to time. The main one is some apps need to run in the background to work properly and it can be a quicker way to kill them when you are done with them. One I use like this is trapster. Trapster uses a lot of battery. In order to kill it I have to switch to it and drill a menu. I dont kill it because of memory concerns, I kill it because of battery usage which is not a fault, it needs to run in the background to work properly. Rather than do that though I just click one icon and kill all with my tool of choice, systempanel. I'll get back to that.
Systempanel gives you a lot of information about what your apps are doing both in real time and can log. CPU cycles used, data, etc. With it you can easily locate that app that is killing your battery or just get real data about your processes and their consumption. Just a few days ago my battery took a 10% dump in an hour and I had not even been using the phone. Only took a minute with systempanel to figure out an app I had called quick settings had been smoking crack and gone bat**** on me. One uninstall/reinstall later, all good. Try that with atk. I set up so that all my frequently used apps are excluded from a kill all as well as lower level processes. This means in the odd case like after running trapster when I kill all I'm only killing apps that would have likely been completely shut down and need to fully restart anyways and I probably wasnt going to use them regardless because they are not frequently used apps. In other words I lose somewhere between very little and nothing but save the hassle of drilling menus to kill an app I want to stop. Im pretty high on this app, you can read more here http://androidforums.com/android-ap...task-killer-people-who-hate-task-killers.html

Re: FAQ: Why You Shouldn’t Be Using a Task Killer with Android (geekfor.me)
I understand all that, but I DON'T run anything but stock apps plus opera. So I DON'T have any unique situations of certain apps needing to be running for things to work properly. If you saw my system panel list you would see how downright simple my phone setup is, yet something like opera can't even stay open because the OS killed it. It's a horrible multitasking mechanism.

I was responding to a different post Roger, sorry for the confusion. Yours and several others came in before I was done typing.
I have had that one a couple times myself. I have been keeping my eye out for a good startup manager. Something that will allow me to stop amazon and others alltogether as well as manage when apps can startup. Something along the lines of only when the phone has been asleep for a set amount of time and so on. Might be a guy could make it so that the problem is reduced that way although it doesnt attack the problem directly.

Re: FAQ: Why You Shouldn’t Be Using a Task Killer with Android (geekfor.me)
Oh sorry I got confused.
Well anyway I don't have it in me to make a long detailed post, but I'm finding that android's multitasking is seriously flawed on a fundamental level. In fact it does the exact opposite of what I'm trying to do in many instances.
One quick example, load up a few webpages in the default browser, maybe an article or 2 and have the pages fully load so they are there to read. Great, now minimize the browser and go to the homescreen and then back to the browser. Your pages are still there, good.
Now I lost my data connection cause I'm commuting on the the train to work in a tunnel. If I open up any other app the OS closes the browser. When I reopen the browser all my loaded pages are still there in memory to read, but the browser immediately tries to refresh the pages, which won't work cause no data connection, and now my cached page disappears. Horrible. I purposely loaded those pages to read offline. The ass kicker is that all the while this happened because the OS decided to pre load a bunch of apps during this time which were not running previously and caused this browser to close. Apps I've not used in weeks, yet the app I WANT suffers.
I have more extreme examples but don't have the energy to post them now. But Google has closed out this item on their suggestion/bug forum.

RogerPodacter said:
Oh sorry I got confused.
Well anyway I don't have it in me to make a long detailed post, but I'm finding that android's multitasking is seriously flawed on a fundamental level. In fact it does the exact opposite of what I'm trying to do in many instances.
One quick example, load up a few webpages in the default browser, maybe an article or 2 and have the pages fully load so they are there to read. Great, now minimize the browser and go to the homescreen and then back to the browser. Your pages are still there, good.
Now I lost my data connection cause I'm commuting on the the train to work in a tunnel. If I open up any other app the OS closes the browser. When I reopen the browser all my loaded pages are still there in memory to read, but the browser immediately tries to refresh the pages, which won't work cause no data connection, and now my cached page disappears. Horrible. I purposely loaded those pages to read offline. The ass kicker is that all the while this happened because the OS decided to pre load a bunch of apps during this time which were not running previously and caused this browser to close. Apps I've not used in weeks, yet the app I WANT suffers.
I have more extreme examples but don't have the energy to post them now. But Google has closed out this item on their suggestion/bug forum.
Click to expand...
Click to collapse
You could easily download taskpanel, and add apps you do not need to the "auto kill list". I didn't know stock (which you said you were on a while ago) was so horrible when it came to memory, your problems don't even exist on my phone. I'm curious, if you installed Cyanogen would your problems away. If my browser closed on me after having too many apps open, I would be irritated as well.
I can have about 50-60 applications idle, or whatever, and the browser would never close. I don't use Opera, or Skyfire, though.

Paul22000 said:
Here's an article posted at http://geekfor.me that is by far the best explanation I've ever seen...
Click to expand...
Click to collapse
Nice find, I got this article since a couple of weeks in my signature, in another forum and killed my taskkiller since then

I use a Task Manager that separates system tasks from app tasks. Anything I use on a regular basis, or even at all, including widgets I use and such, I add to the ignore list. I use it to kill background apps that try to run when they don't need to run. Why don't they need to run? Because I don't need stocks and twitter apps running because I don't use them and it won't let me uninstall them. Next best thing to do is to put them on an auto kill list, though it isn't quite aggressive enough. I really don't want to root just to uninstall the massive amount of bloat that comes from Telstra.

Paul22000 said:
You're in luck my friend!
Here you go:
http://www.downloadmoreram.com/index.html
Your phone will FLY!
Click to expand...
Click to collapse
O.M.G.!!!!! This totally worked for me. This link should be stickied. Easy to use and simple.
muncheese said:
Awesome, I left a little on the server for you guys.
Click to expand...
Click to collapse
There can never be too much.
Now, a question. How about a program that polls for a signal, like google maps? Will it not look for things like my location? Please educate me, I want to believe.

wow great info and its really starting to help out after a few days. Think i got a pretty good question though. I understand the killing of apps and all of that now but what do yall think of a startup manager and picking and choosing before or while the system is booting (ive been using startup manager i found in the market). Just wanted to see what everyone thought. thanks, veritas

Tips to Configure Trask Manager / Process List

Greetings,
There are many task managers out in the market with various features. Because of Battery consumption issue and Ram management, without even knowing the impact we all (including myself) just kill tasks or programmes running in the system.
We should not forget its not Windows this is android. And its suppose to run better.
So far, for me this killing task has worked well by extending battery life from 10 hours to 3 days.
This thread is dedicated to discuss all these process so all the users know what they are doing. No matter what application used.
@ Developers/ Experts please share your technical knowledge on this.

Dont kill these tasks otherwise your timescape widget will not update
Com.sonyericsson.adroid.mediascape.pluginmanager
Com.sonyericsson.adroid.timescape.pluginmanager
Com.sonyericsson.adroid.contentmanager.service.timescape
Timescape
And these tasks I have eliminated from kill list as my phone start to become non responsive.
Com.google.android.providers.settings
Com.andorid.packageinstaller
Settings
Com.google.android.apps.uploader

i kill package installer without any side effects. what about sns provider and service account provider? What do those do anyone know? also is it safe to kill com.sonyericsson.learningclient

Chuteboxe39 said:
i kill package installer without any side effects. what about sns provider and service account provider? What do those do anyone know? also is it safe to kill com.sonyericsson.learningclient
Click to expand...
Click to collapse
I have kill all the SNS providers no problem.
I have no idea about com.sonyericsson.learningclient. right now its on my nonkill list.

And what about SemcIME and Wiper App? Do you kill them or not?

Zenghelis said:
And what about SemcIME and Wiper App? Do you kill them or not?
Click to expand...
Click to collapse
SemcIME is related to sim card reading as my guess. dont kill this. I remember at times when i kill this i was unable to make calls unlill phone restart.
Wiper App add to non kill list. I have no idea what it dose. but im sure it helped me to extend my battery from the day I stopped killing it.

How about this article:
geekfor.me/faq/you-shouldnt-be-using-a-task-killer-with-android/
I, as an Android-newbie, found it very informative. I'm not using any task killer at all, and can extend my X10's battery life up to 3 days.
The TL;DR version:
* Android is hard coded to automatically kill a task when more memory is needed.
* Android is hard coded to automatically kill a task when it’s done doing what it needs to do.
* Android is hard coded to automatically kill a task when you haven’t returned to it in a long time.
* Most services (while possibly running in the background) use very little memory when not actively doing something.
* A content provider is only doing something when there is a notification for it to give. Otherwise it uses very little memory.
* Killing a process when it isn’t ready only causes it to have to reload itself and start from scratch when it’s needed again.
* Because a task is likely running in the background for a reason, killing it will only cause it to re-spawn as soon as the activity that was using it looks for it again. And it will just have to start over again.
* Killing certain processes can have undesirable side effects. Not receiving text messages, alarms not going off, and force closes just to name a few.
* The only true way to prevent something from running at all on your phone would be to uninstall the .apk.
* Most applications will exit themselves if you get out of it by hitting “back” until it closes rather than hitting the “home” button. But even with hitting home, Android will eventually kill it once it’s been in the background for a while.
Click to expand...
Click to collapse
I wouldn't go and kill any unfamiliar processes: Android handles processes in a far better way than Windows does.
I agree with the writer of the above article: try to figure out which apps/processes are consuming too much of your battery (i.e. CPU cycles, not necessarily RAM). Most of your problems could be caused by bad-programmed apps...
Which brings us to the following question: could it be that SE has put some bad-written programmes on the X10 themselves? I guess so

What is with certain background processes?

I noticed certain background processes like 'Email' and 'Gallery' kept coming back.
Even after I killed them with 'Advanced Task Killer', they kept popping back up and I want to know how to stop them? I don't want them to run automatically unless I need them.
Why is 'Gallery' kept popping up? I haven't checked any pictures lately.

Good question bro. This should be put to Google's Android forum.
Sent from my GT-I9100 using XDA Premium App

MrRoberts69 said:
I noticed certain background processes like 'Email' and 'Gallery' kept coming back.
Even after I killed them with 'Advanced Task Killer', they kept popping back up and I want to know how to stop them? I don't want them to run automatically unless I need them.
Why is 'Gallery' kept popping up? I haven't checked any pictures lately.
Click to expand...
Click to collapse
Out of interest, why are you bothered about it?

MrRoberts69 said:
I noticed certain background processes like 'Email' and 'Gallery' kept coming back.
Even after I killed them with 'Advanced Task Killer', they kept popping back up and I want to know how to stop them? I don't want them to run automatically unless I need them.
Why is 'Gallery' kept popping up? I haven't checked any pictures lately.
Click to expand...
Click to collapse
Please spend some time to read up on how linux works, specifically how memory is used, and then you will understand how Android works and why these applications keep "coming back".
I cringe everytime I read people talking about taskkiller applications.

kitch9 said:
Out of interest, why are you bothered about it?
Click to expand...
Click to collapse
I like to know how things tick and there is a REASON why the 'Gallery' kept popping back up.

MrRoberts69 said:
I like to know how things tick and there is a REASON why the 'Gallery' kept popping back up.
Click to expand...
Click to collapse
Because this is how android OS works. It loads processes for faster use when needed. There is nothing you can do to stop it, its based on android and its process management method, etc. These apps should be frozen in an idle state using zero resources. Use system panel to confirm gallery is not using any CPU.

They should make the system clever by having it learn what each person uses/doesn't use and only load the processes accordingly . I just find it irritating that it loads stuff that I am never going to use... I don't care that it doesn't use resouces, I just find untidy

I agree, i dont like things to start without me using them first neither! This is just stupid. Also some things should never been shown to users in my opinion. If something is in the kernel and not for me to mess with it should be hidden.
ps. as a user i dont want to spend reading tons of pages on how the OS works in detail, it should be easy to use and dont make the user confused. this is one aspect i hope Android improves in the future.

vampyren said:
I agree, i dont like things to start without me using them first neither! This is just stupid. Also some things should never been shown to users in my opinion. If something is in the kernel and not for me to mess with it should be hidden.
ps. as a user i dont want to spend reading tons of pages on how the OS works in detail, it should be easy to use and dont make the user confused. this is one aspect i hope Android improves in the future.
Click to expand...
Click to collapse
Buy an iphone
Sent from my GT-I9100 using XDA App

First of all starting some processes also start others in anticipation of their use. What is happening is that apps you are using are calling for those to start for quicker launch and there are dependencies that are not immediately obvious that will sometimes start a seemingly unrelated process. Memory management on android is very good and typically with task killers you often work against the built in memory management. I'm going to do a cut an paste here with a few basics....
By default, every application runs in its own Linux process. Android starts the process when any of the application's code needs to be executed, and shuts down the process when it's no longer needed and system resources are required by other applications.
A content provider is active only while it's responding to a request from a ContentResolver. And a broadcast receiver is active only while it's responding to a broadcast message. So there's no need to explicitly shut down these components.
Activities, on the other hand, provide the user interface. They're in a long-running conversation with the user and may remain active, even when idle, as long as the conversation continues. Similarly, services may also remain running for a long time. So Android has methods to shut down activities and services in an orderly way:
An activity can be shut down by calling its finish() method. One activity can shut down another activity (one it started with startActivityForResult()) by calling finishActivity().
A service can be stopped by calling its stopSelf() method, or by calling Context.stopService().
Components might also be shut down by the system when they are no longer being used or when Android must reclaim memory for more active components.
If the user leaves a task for a long time, the system clears the task of all activities except the root activity. When the user returns to the task again, it's as the user left it, except that only the initial activity is present. The idea is that, after a time, users will likely have abandoned what they were doing before and are returning to the task to begin something new.
An activity has essentially three states:
It is active or running when it is in the foreground of the screen (at the top of the activity stack for the current task). This is the activity that is the focus for the user's actions.
It is paused if it has lost focus but is still visible to the user. That is, another activity lies on top of it and that activity either is transparent or doesn't cover the full screen, so some of the paused activity can show through. A paused activity is completely alive (it maintains all state and member information and remains attached to the window manager), but can be killed by the system in extreme low memory situations.
It is stopped if it is completely obscured by another activity. It still retains all state and member information. However, it is no longer visible to the user so its window is hidden and it will often be killed by the system when memory is needed elsewhere.
If an activity is paused or stopped, the system can drop it from memory either by asking it to finish (calling its finish() method), or simply killing its process. When it is displayed again to the user, it must be completely restarted and restored to its previous state.
The foreground lifetime of an activity happens between a call to onResume() until a corresponding call to onPause(). During this time, the activity is in front of all other activities on screen and is interacting with the user. An activity can frequently transition between the resumed and paused states - for example, onPause() is called when the device goes to sleep or when a new activity is started, onResume() is called when an activity result or a new intent is delivered. Therefore, the code in these two methods should be fairly lightweight.
A few conclusions.....
Android is hard coded to automatically kill a task when more memory is needed.
Android is hard coded to automatically kill a task when it's done doing what it needs to do.
Android is hard coded to automatically kill a task when you haven't returned to it in a long time.
Most services (while possibly running in the background) use very little memory when not actively doing something.
A content provider is only doing something when there is a notification for it to give. Otherwise it uses very little memory.
Killing a process when it isn't ready only causes it to have to reload itself and start from scratch when it's needed again.
Because a task is likely running in the background for a reason, killing it will only cause it to re-spawn as soon as the activity that was using it looks for it again. And it will just have to start over again.
Killing certain processes can have undesirable side effects. Not receiving text messages, alarms not going off, and force closes just to name a few.
The only true way to prevent something from running at all on your phone would be to uninstall the .apk.
Most applications will exit themselves if you get out of it by hitting "back" until it closes rather than hitting the "home" button. But even with hitting home, Android will eventually kill it once it's been in the background for a while.

krabman, thanks mate now your post really helped me a lot to understand these processes

[TUTE][TIPS] Android RAM Management

Android RAM Management
What's this thread about?
This is a brief account of some useful aspects of android memory management and what could be done to make it better or to suit our needs. This is arranged in two parts; A) RAM Management Lesson. B) RAM Management Tips. Whoever is familiar with the Android RAM management concepts can skip to the second part (2nd post). [highlight]Please read and understand carefully before applying anything to the phone. I'm not responsible for any unwanted effects thereby. Credits belong to respective authors of any MOD/APP discussed here.[/highlight]
A) RAM Management Lesson
Android uses a different way of handling processes. Instead of killing every process after its activity ended, processes are kept until the system needs more memory. The idea is to give speed improvements if you start that activity again. But how/when does Android kill a process if it needs more memory and and which process to kill first?
This is managed by the LMK (Low Memory Killer) driver of Android. You may already know that every app/process in Android is assigned an oom_adj value, which indicates the likelihood of it being killed when an out of memory (OOM) situation occurs. More higher it's value, the higher likelihood of it getting killed. Valid range is -17 to +15. (if in the -17 range means it won't get killed). According to that, there are six groups (OOM groups), into which apps/processes are categorised:
1. Foreground app
2. Visible app
3. Secondary server
4. Hidden app
5. Content provider
6. Empty app
Basically these could be described as..
FOREGROUND_APP:
// This is the process running the current foreground app. We'd really
// rather not kill it!
VISIBLE_APP:
// This is a process only hosting activities that are visible to the
// user, so we'd prefer they don't disappear.
SECONDARY_SERVER:
// This is a process holding a secondary server -- killing it will not
// have much of an impact as far as the user is concerned.
HIDDEN_APP:
// This is a process only hosting activities that are not visible,
// so it can be killed without any disruption.
CONTENT_PROVIDER:
// This is a process with a content provider that does not have any clients
// attached to it. If it did have any clients, its adjustment would be the
// one for the highest-priority of those processes.
EMPTY_APP:
// This is a process without anything currently running in it. Definitely
// the first to go!
Click to expand...
Click to collapse
These groups are defined by oom_adj value limits, and apps would fall into one of those groups according to the oom_adj value assigned to that particular app. "Foreground apps" usually have an oom_adj value of 0 or less (so they are the least killable; i.e High priority). "Empty apps" have a higher oom_adj (they are killed early; i.e Low priority). Also, oom_adj value changes according to the state of the user app; it's 0 when the app is active in the foreground and assigned a higher value when the app goes to the background.
Why their "killability" differ? Apps belonging to these different groups (that have different oom_adj's), start to get killed at different levels of free RAM. These triggering RAM limits are defined by the LMK minfree values. Above 6 categories correspond with 6 RAM limits which are set in the LMK minfree. Eg: Stock Android 4.3 in our SP comes with the minfree values of 58,68,78,88,98,118. (these are in MB; see below how to check it). Practically what it means is, Empty apps will get killed when ram goes below 118mb, Content providers when it goes below 98mb, Hidden apps when it goes below 88mb and so on.. lastly starts killing Foreground apps when ram goes below 58mb. You may notice that this last value (58mb) is not desirable when using memory intensive apps like heavy games. The app might shutdown while we interact with it. It won't be a surprise if RealRacing3 would shutdown in the middle of a race with these minfree settings!
[Highlight]Notes:[/highlight]
1. In our SP (and newer kernels), oom_[highlight]score[/highlight]_adj is used instead of old oom_adj. (oom_score_adj valid range is -1000 to 1000). But oom_adj is also maintained for compatibility I think.
2. It is said that there are many OOM process categories that are assigned different oom_adj priorities by the ActivityManagerService, but eventually all of those would be considered under above six slots/groups (according to oom_limits), for the purpose of killing by the LMK minfree triggers. Therefore, those six are the importatnt ones for normal users like us.
[highlight]Now, to the practically important part...[/highlight]
# We can check the minfree values (also change them) and see the OOM groupings of apps/processes with this Memory Manager app easily.
a) LMK Minfrees:................... ......................................b) OOM groupings:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
....
If we click on an app in the list and select 'more info', we can see it's oom_adj value. In my case, System UI has -12 (foreground), Home Launcher has 1 (visible group) etc..
# We can check these manually in a terminal too..
a) LMK Minfrees:
Give the following command (without quotes) in a terminal emulator or adb shell: "cat /sys/module/lowmemorykiller/parameters/minfree"
Code:
$ cat /sys/module/lowmemorykiller/parameters/minfree
[b]15000,17532,20065,22598,25131,30263[/b]
** These are in pages; 1 page=4K. Therefore, converting these in to MB results in.. 58,68,78,88,98,118. (e.g: 15000 x 4 /1024 = 58,5938)
b) OOM_adj value of an app:
*This is not much useful. But nice to know where to get these values from.
E.g. take home launcher. Find out it's PID (process ID) like this.. (command with output posted)
Code:
$ ps |grep [b]home[/b]
u0_a26 1653 721 471408 78076 ffffffff 00000000 S com.sonyericsson.home
It's pid is 1653. To see it's oom_adj value..
Code:
$ cat /proc/[b]1653[/b]/oom_adj
1
It's 1 (foreground). You might get 6 (hidden). So, your home is easily killed than my home . See below why..
At the same time we can see the new oom_score_adj..
Code:
$ cat /proc/[b]1653[/b]/oom_score_adj
58
* To convert old oom_adj value to newer oom_score_adj..
oom_score_adj = (oom_adj x 1000)/17 (truncate the decimals). So, (1x1000)/17=58.823
*There's another value (0-1000) of oom_score (cat /proc/1653/oom_score), which is THE actual indicator of how likely a process will get killed. It changes according to the tunable oom_score_adj and other factors..? something like that.. forget it!
[highlight]## The above mechanism could also be described according to what is mentioned in kernel source files[/highlight], as below. Can skip if it's boring ..
It's from 'drivers/misc/lowmemorykiller.c' of kernel sources (4.3; .266)
* The lowmemorykiller driver lets user-space specify a set of memory thresholds
* where processes with a range of oom_score_adj values will get killed. Specify
* the minimum oom_score_adj values in
* /sys/module/lowmemorykiller/parameters/adj and the number of free pages in
* /sys/module/lowmemorykiller/parameters/minfree. Both files take a comma
* separated list of numbers in ascending order.
*
* [highlight]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_score_adj value of 8 or higher when the free memory
* drops below 4096 pages and kill processes with a oom_score_adj value of 0 or
* higher when the free memory drops below 1024 pages.[/highlight]
*
* The driver considers memory used for caches to be free, but if a large
* percentage of the cached memory is locked this can be very inaccurate
* and processes may not get killed until the normal oom killer is triggered.
Click to expand...
Click to collapse
If we take our phone values, "cat /sys/module/lowmemorykiller/parameters/adj" command returns: "0,58,117,235,529,1000". These are in (new) oom_score_adj values. If we convert them to (old) oom_adj values, these become "0,1,2,4,9,15". (eg:117x17/1000=1.989=2; The last value becomes 17, but oom_adj range ends with 15, so we take 15). Now, with our minfrees of 58,68,78,88,98,118, what it means practically is to kill processes with a oom_adj value of 0 or higher when the free memory drops below 58mb and kill processes with a oom_adj value of 1 or higher when the free memory drops below 68mb and so on... Therefore, it's clear that the adj values "0,1,2,4,9,15" (or score_adj values "0,58,117,235,529,1000") define the limits of each of 6 OOM slot described above.
Another point to note is what mentioned above in the kernel source file "..driver considers memory used for caches to be free..", which is described below.
[highlight]What is "Free RAM"?[/highlight]
What's reported in many apps as "free ram" is actually not free/empty. Linux/Android always tries to utilise the whole ram in some way, so the ram is not wasted. Ram which is not used by active apps, is used for caching apps and for some buffers. These caches and buffers can release memory for apps when needed. We can see the ram usage in detail with this command.. "cat /proc/meminfo" [giving "watch cat /proc/meminfo" would refresh the output every 2 seconds].
Code:
$ cat /proc/meminfo
MemTotal: 859764 kB
[B]MemFree: 26380 kB
Buffers: 2008 kB
Cached: 136600 kB[/b]
SwapCached: 0 kB
Active: 557312 kB
Inactive: 70520 kB
...blah.. ..blah...
....
Reported "free ram" was ~150mb when this was taken. Out of that, most (135mb) is already cached. ["Free RAM"=MemFree+Cached]. Actual free is very little. So, increasing "free ram" makes the phone much snappier because most of that "free" part of the RAM is used for caching things.
-->> RAM Management Tips

B) Tips for better RAM management.
Following is an account of which i benefitted from, sharing for others who may not be aware of these. Your milage may vary... Desired "RAM Management" differs depending on whether expecting more multitasking or a snappy phone with lot of free RAM. Nowadays, phones with better specs generally won't show any lag even if tuned for multi-tasking , although "free RAM" stays little lower. I prefer towards more multi-tasking
1. Change the minfree values to suit your needs. [highlight](Need Root access)[/highlight].
LMK Minfree values can be changed on the fly. Use lower values if you want more multitasking. Higher values if need more "free ram" for gaming etc.. . I use 8,12,45,65,95,165 for more multitasking and for foreground apps to stay until ram becomes much lower. Asphalt8 never crashed with this! If we use values like 15,25,95,145,195,245 "free ram" would be more but background apps (e.g. Hidden apps) would shutdown earlier. However, make sure NOT to increase the first 2 slots too high, so that the Foreground and Visible apps would stay even if RAM goes lower.
How to set/change them:
a) You can set those values with the above Memory Manager app and press Apply. (and tick 'apply at boot' for those values to be applied at every boot).
** There are many preset values you can experiment with.
b) Or can do the manual way.. Give the following command in a terminal/ADB shell:
Code:
echo "2048,3072,11520,16640,24320,42240" > /sys/module/lowmemorykiller/parameters/minfree
(That's after "su" command to get root prompt). ** Need to 'echo' them in pages; not in MBs. See first post how to convert them.
Note: This won't survive reboot. You can run this command as a script with init.d every boot. (For init.d support, check this). The script would look like this:
Code:
#!/system/bin/sh
echo "2048,3072,11520,16640,24320,42240" > /sys/module/lowmemorykiller/parameters/minfree ;
c) Can use Minfree Manager app. To set the minfrees, press Apply after entering the values. If we press 'Apply at Boot', it saves a script under init.d. No hassle.
** There are many apps that can do these kind of changes. Eg: Auto Memory Manager, Ram Manager(Free/Pro)-with other options. The above described ones are very easy to use.
2. Use 'App Settings' xposed module to make any app "stay" in memory (make it "Resident"). [highlight](Need Root access)[/highlight]
It would definitely help multitasking by keeping the needed apps in the background without getting killed, even if RAM becomes low. It possibly works by reduces the app's oom_adj value. That's why you can see Opera Mini in the 'Foreground app' list in my screenshot above (1st post). It's oom_adj value is 0. You can do this for your home launcher and any app you wan't to stay un-killed in the background.
Caution: Making apps to stay in memory would make them stay without being killed, even when e.g. a heavy game is starving for RAM. Therefore, indiscriminate use of this option is not advised. I think it's better to..
(i) Apply only to the apps which have an 'Exit' button/menu, so we can shut it down when needed.
(ii) If no exit button, Add to the 'Greenify' list to be hibernated when the app is not needed. But it asks for confirmation before hibernating these kind of apps with 'High Priority' oom_adj status.
How-to:
1. Get Xposed installer from here. Install it. Install the Xposed framework through it. Refer to the respective thread for more details.
2. Then download the 'App Settings' module through Xposed installer..
3. Open 'App Settings'.. App list will load.
4. Select the app you wan't to tweak.. It will lead to a page as seen in the screenshot above.
5. Select 'Resident' and save (upper right corner button). Can change any other setting if needed.
3. Use zeppelinrox's jar patcher tools to patch services.jar. [highlight](Need Root access)[/highlight].
It changes Home Launcher priority and many other LMK related tweaks. This is why you see my home launcher is under visible apps (oom_adj 1). No launcher redraws even after asphalt8! See the particular thread for details. In summary, patching services.jar results in (quoted from the thread):
- This will SuperCharge Your Home Launcher and ADJ/OOM Priorities! You pick launcher strength!
- This lets you run up to 70 hidden apps instead of the default 15 (RAM permitting) without breaking the lowmemorykiller!
- This tries to bypass the 30 minute service inactivity limit by increasing it to 24 hours.
Click to expand...
Click to collapse
** From ICS up, Android doesn't read ADJ values from build.prop or local.prop - they are hardcoded into services.jar! That is the reason for needing to patch services.jar to change OOM priorities. More details in the respective threads.
How-to (quoted):
Get Jar patcher tools from the thread. I used 'Ultimatic_Jar_Patcher_Tools_RC7_TEST6_ALL_DEX_ALL_OSes_NO_FLASH.zip'. Extract it in the PC. Make sure ADB drivers installed.
How to run -=Ultimatic Jar Patcher Tools=-
1. Connect your Android to your PC with Android Debugging ENABLED and Mass Storage DISABLED so your device has access to your sdcard.
2. Windows: Run either the zip's *.bat or the attached *.exe
If running the exe, you can put a different ultimate jar power tools script version in the same folder and it will use that one otherwise it uses the embedded version!
If you have cygwin installed, you can even use the zip's *.sh file at the cygwin prompt.
Linux/Mac OSX: run the zip's *.sh file
Just be sure to read everything and answer Yes or No as is your preference.
Example: The script allows you to choose the level of your Launcher's Super Strength! (BulletProof, Die-Hard, or Hard To Kill)
Click to expand...
Click to collapse
** Always keep a cwm backup before attempting this; might not get it correct in the first attempt..
4. With the above jar patching, can use zeppelinrox's supercharger script. [highlight](Need Root access)[/highlight].
It can be used to change the minfrees and it re-groups the OOM categories. It also has tons of other cool tweaks. If we check "cat /sys/module/lowmemorykiller/parameters/adj" after applying the SuperCharger scripts to our phone, it returns.. "0,176,352,588,705,1000". Converting to oom_adj values (see 1st post) it becomes "0,3,6,10,12,15". Comparing with stock values (0,1,2,4,9,15), we can see that the above described six OOM slots are re-arranged, sort-of categorising more processes towards higher priority. Can test those settings by echoing those values (this won't survive reboot):
Code:
echo "0,176,352,588,705,1000" > /sys/module/lowmemorykiller/parameters/adj
** Not advisable to meddle with this if no clear idea about what is being done. Use the SuperCharger script instead. Checkout the respective thread for more info.
[For me, this OOM regrouping made some task killings more difficult and it didn't relese RAM readily when needed for heavy games..(may not be same for others ). So I'm not using it at the moment. I'm setting up minfrees as described previously.]
How-to (briefly):
1) Get the latest SuperCharger script from the thread.
2) Make sure requirements are met. Eg: Rooted, Busybox installed.
3) Run the script through 'Script Manager-Smanager' app (with root access granted).
4) Read the output of the screen and reply to the prompts accordingly.
** Keep a cwm backup before attempting this, just in case..
5. Override the "Hidden app limit" of Android. [highlight](Need Root access)[/highlight].
In addition to the LMK driver mechanism described above, this is another parameter that leads to killing of Hidden and Empty apps. Apps are killed when the number of those apps go beyond the specified limits. (Traditionally it was 15, so no more than 15 hidden apps would stay in the background even if there's plenty of RAM). There's a build.prop setting which can control this in our SP. (Btw, services.jar patching mentioned above makes that limit to 70). With the build.prop setting mentioned, we could make it to even 150 ! (This way, we can maximize multitasking and app killing is fully handed over to LMK minfrees, which we can control).
How-to:
Code:
ro.sys.fw.bg_apps_limit=70
Add this line to end of build.prop file (in /system) and leave another blank line below that, and save the file. Then reboot.
Tip: Build Prop Editor is an easy way to edit the build.prop.
** Always keep cwm backups before doing these kind of things.
How to test:
a) Install CatLog app (need root) [This is for reading Logcat]
b) Run it and enter "longer" (without quotes) in the filter bar. Might get a filtered output like this:
It means that the 24th Empty app had got killed, because of exceeding the hidden app limit. This is after services.jar patching making the Hidden app limit to 70. Before it was #17 if I remember correctly.
c) Check the same output after applying the build.prop setting. Should get a little increase. (When I made Hidden app limit to 100, output was #34th empty app gets killed. So, I wen't upto 150 until that kind of output disappeared ).
## Credits to @zeppelinrox for finding that build.prop setting. You can read what happened here in his thread.
How it works:
By @zeppelinrox
In Android 4.2 the max hidden apps are divided into 2 parts (In AMS smali the value is stored in "mProcessLimit")
Part of it goes towards hidden apps.
Part of it goes towards empty apps.
So what happens is it gets the max apps limit (v2)
It gets multiplied by 2 so "v2" is doubled in value.
Now... that is divided by 3 and that value is assigned to empty apps (v13)
Finally, empty apps (v13) is subtracted from v2 to give you hidden apps (v17)
So by default, there are MORE empty apps than hidden apps!
2/3 are empty
1/3 are hidden
So your original config was probably...
max hidden apps = 25
empty apps = 17 (25x2/3)
hidden apps = 8 (25-17)
So normally (without jar patching), if the limit is 70 it would break down like this...
max hidden apps = 70
empty apps = 46 (70x2/3)
hidden apps = 24 (70-46)
** Services.jar patching reverses this ratio (to give more allowance to Hidden apps than Empty apps. Then it results in:
max hidden apps = 70
empty apps = [highlight]23[/highlight] (70x3/9)
hidden apps = 47 (70-23)
Click to expand...
Click to collapse
That's why my 24th Empty app was getting killed with app limit of 70. You might get a totally different value if this build.prop setting is applied without services.jar patching. Appreciate your feedback
[highlight]** Please Note: I'm no dev. I wrote this according to what i understood by reading around in the net. I'd be more than glad if anyone points out any shortcomings/improvements. Thanks.[/highlight]
Credits/Sources
@zeppelinrox for his supercharger thread with overwhelming info, for finding out the build.prop setting in our SP, for explaining things and many more!
@androcheck for his thread
Took more info from here, here, here, and here.

[Highlight]An interesting observation...[/highlight]
Many of us refer to 'Settings>Apps>Running' to see how much free RAM is available at a particular moment. Generally we believed that it shows the correct value. But, some observations makes that value doubtful. E.g: This value doesn't tally with /proc/meminfo values. Furthermore, 'Free RAM' indicated by other apps at times are totally different.
(1).CoolTool - 121 MB
(2).meminfo (watch cat /proc/meminfo) - Looks compatible with cooltool value.
(3). Android says - 23MB!!??
**(all 3 values were updating realtime..)
Sometimes it goes the other way:
(gave time to settle down of course)
Any thoughts?? Does anyone experience like this or only me?

Just in case..

mrhnet said:
@androcheck for his thread...
Click to expand...
Click to collapse
Hi @mrhnet: I got pinged by your mention of my username. Thank you for this valuable thread! It's so important for xda having people around which actually explain and give knowledge to others! This is how a community should work! Great work! :good:
P.S.: Also thanks for giving me credit. That's not to be taken for granted. When I search the web for the unfortunate typo in my posting "on Android the current forefround application" I find a lot of resources which simply copied my words and often did not give any credit. So I appreciate this very much!

@androcheck
Thanks for the encouragement..

nice tutorial with full descriptions...great..:good:

This is wonderfull! I will add this to the tutorial Index this weekend

mrjraider said:
This is wonderfull! I will add this to the tutorial Index this weekend
Click to expand...
Click to collapse
Thanks. That's nice of you

thx u very much for the detailed explanation, gonna try ur recommended values later

great bro can be a sticky thread

mrhnet said:
Just in case..
Click to expand...
Click to collapse
Nice thread dude.
Now I'm glad that I had patience with your patching issues lol
However I don't think I have the patience to go into every tiny detail which is why I link to @androcheck 's thread in my original Supercharger OP (which is now post #3)
And you may find useful the new tool that I'm finally on the verge of releasing...
androcheck said:
Hi @mrhnet: I got pinged by your mention of my username. Thank you for this valuable thread! It's so important for xda having people around which actually explain and give knowledge to others! This is how a community should work! Great work! :good:
P.S.: Also thanks for giving me credit. That's not to be taken for granted. When I search the web for the unfortunate typo in my posting "on Android the current forefround application" I find a lot of resources which simply copied my words and often did not give any credit. So I appreciate this very much!
Click to expand...
Click to collapse
Yeah don't you hate that... personally I'm to lazy to copy other people's efforts and rather link to them while doing something new.
No sense in retreading a good tire

zeppelinrox said:
Yeah don't you hate that... personally I'm to lazy to copy other people's efforts and rather link to them while doing something new.
No sense in retreading a good tire
Click to expand...
Click to collapse
Thanks.
I didn't take any offense, if not I would have written it, someone else would have. In the end the knowledge has spread.

@zeppelinrox
I'm so glad about your comments on this thread. Thanks
Awaiting for your new works.. as always..

mrhnet said:
@zeppelinrox
I'm so glad about your comments on this thread. Thanks
Awaiting for your new works.. as always..
Click to expand...
Click to collapse
Soon.
It's done but gotta write up an OP
Edit: Done http://goo.gl/9H58pS

This is a great thread, you've explained everything very well. :good:
In my experience, RAM management works best if I set very low LMK values, like this. Anything higher means processes will get closed sooner.
Multitasking is good with this, not very good, though, because this is a Sony ROM, but still way better than higher values.
But be warned, using these values on stock 4.3 made it unstable for me, but it works on stock 4.1 without any problems.
Also, I've read on some sites that Sony will release Kitkat for the SP in June, and Kitkat has ZRAM enabled and also some other memory management-helping changes are made by Google. So I really hope it will be released for our device.
Edit (05.23): Well, it seems after a few days of testing, that these low values don't do anything good. The phone slows down a lot. So, this post might be considered pointless. Anyway, it was a good experiment.

I found one thing: in /proc/meminfo it shows more than 200 MB at Cached, but the launcher still redraws when i press Home in Chrome, and sometimes when going back from minfree manager (while chrome is running). So why doesn't the system utilize the Cached memory instead? I see that you, mrhnet, have 78 MB cached on one of the screenshots... Is this some sort of ram management bug in the stock 4.1 or what?

Lajbymester said:
I found one thing: in /proc/meminfo it shows more than 200 MB at Cached, but the launcher still redraws when i press Home in Chrome, and sometimes when going back from minfree manager (while chrome is running). So why doesn't the system utilize the Cached memory instead? I see that you, mrhnet, have 78 MB cached on one of the screenshots... Is this some sort of ram management bug in the stock 4.1 or what?
Click to expand...
Click to collapse
200mb cached means it's included in "free RAM". But it changes according to RAM demand/usage by apps. (Give "watch cat /proc/meminfo" command [without quotes] in a terminal to see; "watch" command runs what comes after that every 2 seconds). Maybe, by the time you switch from Chrome to terminal, Cached amount might have changed. (I think Chrome is a memory hog btw; haven't used it much).
If you really want to see what was in meminfo while chrome is on, I suggest to "record" meminfo values to a file real-time. Can do like this:
*Open terminal emulator
*go to /sdcard
Code:
cd sdcard
*append output of meminfo to a file every 2 seconds
Code:
watch cat /proc/meminfo >> memlog.txt
*leave terminal emulator in background and do whatever in chrome. Meminfo values should be recording in the background; terminal is not easily shutdown because it has a notification (apps having a notification saying that it's running has a high priority I think).
*then come back to terminal emulator and do a "ctrl+c" to break the recording (see terminal settings to know what's assigned as ctrl button)
*now you have a memlog.txt file in sdcard with meminfo output every 2 seconds (might look overwhelming ). If 2 seconds is too frequent, can adjust "watch" command accordingly (eg: watch -n 10 cat /proc/meminfo). Just give "watch" command to see it's usage.
You can go through that file leisurely to see how Cached etc have changed with time. Can filter with "grep" to avoid other gibberish.
Eg:
Code:
grep -w Cached: memlog.txt
This command outputs only the "Cached:" line in the file. [Remember: everything is case sensitive in Linux]. You can even write that output to another file for ease (can do for other values also):
Code:
grep -w Cached: memlog.txt >> Cached.txt
grep -w MemFree: memlog.txt >> MemFree.txt
grep -w Buffers: memlog.txt >> Buffers.txt
Then can go through these files leisurely to see min/max values. I think you can do lot of things with "grep". A Linux geek might even arrange these data to make a graph! @zeppelinrox is the man for this I think

Thanks for the very detailed reply
Actually I was doing the "cat /proc/meminfo" command on the computer using adb on the computer, so switching apps wouldn't interfere. ("watch cat /proc/meminfo" doesn't work for some reason, it doesn't output anything but the actual date). And while looking at Chrome with 2 heavy desktop websites, it was showing ~220 MB at Cached. It doesn't ever go below 180 MB...

Ok.
Dunno exactly what's wrong there.. Just remembered a part from kernel sources I've mentioned in OP:
The driver considers memory used for caches to be free, but if a large
* percentage of the cached memory is locked this can be very inaccurate...
Click to expand...
Click to collapse
Maybe part of Cached is "locked"?? Can do a reboot and see whether the situation persists (if not done already).

Sound Issues - Conflict Found but not Solved [Closed]

I'll leave this up but not really sure any of this is helpful to most people. Skip to the last post for the closest I got to a resolution. Basically, my phone was losing sound and mic ever since Live Caption was introduced to Device Personalization Services.
Does anyone have the OTA or Boot.img for 10.0.36? I would like to use the bootloader MSM tool for that release as that was probably the last stable ROM without sound and mic issues on my phone. I see the link is still up (but crossed out) in the 'unlock bootloader' thread but when I scan the boot.img with my antivirus, it tells me it "scanned two files, no threats found". Why would that boot.img be scanning as two files when all the other boots I have only scan as one? Sounds malicious to me. Can someone please please please hook me up with that boot? My phone has been down for over a month. The sound issues are what eventually forced me to try root on this one. I've been successfully rooted on 10.0.39 and 11.01.3 over and over again in the passed couple of weeks. However, after a fresh install, sound and mic is back and life is beautiful and then 2 minutes later, google does whatever it does in the background and I lose it again. I've been battling this since last summer but I think 10.0.36 is far enough back before google updates fracked my phone. Thank you.

For anyone following/interested, (seems like the TMO McLaren family is rather small) 10.0.36 didn't on it's own solve the issue either. It was a little bit lighter on the preinstalled apps though so I suppose that made it slightly easier to work with. I have the RoM stable with working audio and mic offline and it seems to be holding. I'm gonna drop in the SIM and let the Google have access to daggon internet again.
The main change that got this stable was making sure none of the Google apps had access to the "modify system settings" permission that is enabled by default for ALL of the Google apps. If even one of them has that permission it seems it will unlock the gate for it it's buddies. It's kinda hard to observe changes made through settings when the Google just keeps changing them back to whatever the heck it feels like in the background. I'm so disgusted with that company's overly intrusive practices right now. It already knows what route I take to work, what time I get off, what my appoints will be two weeks from now, my interests, who my friends and family are, what porn I like, and if I was constipated or not this morning...like leave me the heck alone and let me chose my own phone settings.
I know I could have just uninstalled/disabled most of the Gapps through ADB and/or checking some of the custom RoMs out there but I felt it was important to learn what was happening to be better prepared in the future and hopefully help someone else who may be having a seemingly rare conflict/issue between one or more Google apps and their device.
I'd be happy to answer any questions or provide more details in the event I'm not alone. I really think I just got unlucky and was sent a refurb replacement that went though some sloppy Quality Control after the previous owner returned it and I'm guessing possibly shouldn't have been released back into the wild.

Ok I'm not so sure the Google is to blame. There may be some kind of conflict with the Google causing my sound and mic to crash but after extensive reading through the threads, I'm convinced that the root of the problem may be with my Persist and no matter what I do, the problem comes back.
I have my persist backed up but the problem is, after I cracked the screen of my original 5G Mclaren, they sent me a refurb. It was maybe corrupted before I got it but the issue is what led me back here only to find out that a lot has changed in almost 10 years. I understand that the Persist partition is unique to my phone but is there no way to repair it?
I'm guessing if I go to a custom ROM, I would just bring my problem with me to that one? I'm pretty tenacious.... maybe if I had a good one I could compare the two for anything pertaining to sound? I could really use a hand here. I know it's not a hardware issue. I actually had this thing running nice offline for a whole day (sound and mic working perfectly). I did that by disallowing most google apps to modify system settings and changed the permissions on a couple and disabled the ones I don't use. Then I dropped in my Sim, connected to wi-fi...all was still good. Made a phone call to a friend and we could hear each other perfectly. Then I plugged in to PC to remove a minor amount of bloat and the darn thing rebooted with Android 11 installed...I was so mad.
I guess I could try again with the same approach and somehow stop the OTAs...even a nudge in the best direction to do that would be super appreciated.
Edit: for what it's worth, I went to 10.0.36 (on both partitions) when I made those adjustments that got it working. The same adjustments did not work when it updated me to 11 and there's tons more apps it seems. I did not use the reserve images fix to get OTAs so I was hoping I just wouldn't be updated but I was and felt completely defeated by the Google. I'd go back further if I could but I'm not exactly sure how I can do that at this point and keep the bootloader unlocked without a ton more research and only have so much time. I tried manually flashing all the images for 10.0.13 or .16 I believe from posted files and instructions way back in the threads...There were no errors in the process and I did it through fastbootd but that attempt would only boot into fastboot afterwards. At the end of the day I'm just an old Jarhead working outside on the railroad. I barely even touch computers anymore.

So here I am back on 10.0.36 again. Initial boot offline produced sounds again for about 2 minutes before they disappeared again.
Resetting system settings was a no go so I started with usual and uninstalled any apps that it would allow me to uninstall through settings.
To sum up all of the small changes and many reboots, I disabled all of the unhidden/non-system Google apps except for Play Services and GBoard but I did swap that out for Simple Keyboard (installed from internal storage). Before disabling them I revoked their rights to modify system settings as well as display over other apps.
I left T-Mobile enabled but denied it's rights to modify system apps.
I took all of the background data permissions away (probably isn't related to the sound issue but just didn't thing disabled apps should have that option checked anyway) from the Google apps. After rebooting most of those like Duo, Calender, Pay, Maps, etc but not the Google App itself all had the permissions for background data again, presumably because I did not deny Google Play Services access to change system settings. I can't be sure it was play services doing that though because I didn't turn that permission off for all apps (mostly system).
Android Auto is disabled. I denied Mic for the T-Mobile app. There's a couple other ones I disallowed to display over other apps and modify system settings and I also cleared cache for all of the apps I made changes to.
Sounds (system, ringtones, etc. are now holding fine and it's been over an hour. Mic was confirmed by installing a recorder app from storage.
I'm not sure about anything but this once again seems to suggest that my hardware (at least the actual speakers and mic) is fine and that maybe if I get on a custom rom with minimal Google interference, I have a shot at using this darn thing. Haven't read that section as extensively as the rest of the sections though because better understanding of stock is always better before jumping into the experimental. I do hope there's one I can use that doesn't bring my apparent conflict with the Google with it.
In the meantime, I guess I need to worry about a reboot that initiates Android 11 (if I take it off airplane mode) because to date, I haven't figured out what, if any changes, I can do in settings to get my sound and mic back if it updates to the newest OTA flavor.
I took one suggestion so far I saw in the thread about creating a payload_metadata.bin with no permissions....sounds plausible. There was an alternative suggestion through magisk but I'd have to open the internet flood gate again for that. So far I only let internet down long enough to let magisk install with the latest update because installing it as a zip through a booted TWRP (latest) doesn't install it fully until I let it have internet access and I left it open long enough to get a couple modules, one being the one that allows the editing of build props in case there's a suggested change I see that can be made to audio that is causing my conflict. That of course was long enough for the system to at least download Android 11 somewhere on my device.
I'm really not sure if there's a hardware difference with my device or something with the Persist (just a guess) that comes back no matter what fresh start with whatever stock RoM I choose to use with the Unbrick Tool but there's obviously something different about this device or I wouldn't be seemingly the only one with this issue.
I guess at this point I'll search for the best way to stop the OTA from installing and look into the best custom RoM option for myself because as tenacious as I am, I just don't have the luxury of the time it would take for the deeper understanding necessary to do this alone. I've done so much reading just for the reward of having a phone that can at least make a phone call lol.
Edit: Oh yeah XGoogle enrollment is disabled too.
EDIT: IF I REMOVE "ALLOW TO MODIFY SYSTEM SETTINGS" PERMISSION FROM TOO MANY OF THE GOOGLE APPS, NOT INCLUDING PLAY SERVICES, MY DEVICE WILL FACTORY RESET ITSELF. USING THE PHONE WITH SIM AND WIFI BUT WITHOUT EVER SIGNING INTO ANY GOOGLE SERVICES CAUSES A FACTORY RESET ALSO. THIS IS USUALLY INITIATED BY LETTING THE PHONE SIT IDLE FOR TOO LONG BUT MAKING A PHONE CALL SEEMS TO MAKE IT CRASH AROUND 5 MINUES FROM CONNECTION TO THE CALL.

Marines don't retreat but we do strategically withdraw and the Google has me surrounded on all sides with no aid from the allies at XDA.
The phone shut itself down and upon reboot I had no sound again and of course the Google apps were all patting each other on the back for all the permissions they changed back on their own....lol like my $900 gave me ownership to any part of this trash. Doesn't look like, during a quick browse, that any of the custom RoMs come without GApps or mention this MicroG stuff I saw a couple videos on. Are they any pay phone booths left?
Semper Fi

Ok I'm trying more things still lol. Again, I got this phone as refurb replacement to my original and the original worked great. It looks like I have two apps associated with Dolby.
They are:
com.dolby.daxervice (user app)
com.oneplus.sound.tuner (system app)
Neither one of those can be disabled (through settings I mean) and com.oneplus.sound.tuner doesn't even have any permissions requested and is greyed out from enabling any permissions. That doesn't seem right to me. In Sounds and Vibrations from the settings menu, Dolby Atmos does not specifically say it's for external devices but maybe...
Indeed, I just connected a set of earbuds and now it's been granted permissions and I have the option to deny or allow. Now it seems a little less likely my device's conflict with the Google originates there but I suppose that since I haven't tried earbuds or anything since using the unbrick tools and rooting, that my conflict persists but shouldn't. I'll clear cache and Dalvik once again and hope for the best. I could also try disabling/uninstalling those two through ADB Shell as another test option. I'm running out of ideas though there's also an equalizer app that gets used in place of com.oneplus.sound.tuner over in the 7T section. Dolby Atmos Equaliser 7T (HD1903) (no root needed) I could try that also. (Edit: This is not for Android 11). I really want to resolve this before trying a Custom RoM. Of course there's a chance one of those might fix my conflict or maybe I'd just bring it with me also and I'd feel more hopeless at that point.
Edit: I guess I should mention that I did let it update to Android 11. Strange how people early on in the threads couldn't get it and even going back to 10.0.36 my device was more than happy to reboot with 11 literally while I was still plugged in with ADB enabled after uninstalling some bloat I felt was very conservative. I'm still using the stock recovery and only booting into TWRP to use Dalvik. It was my bad assumption to think that stock recovery was doing that when clearing cache these days. Sure beats a clean install just to get temporary sound back and honestly it seems to hold a little longer than is has been when I do that.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}

I'm officially done with this. It looks like last year when Device Personalization Services was updated with Live Caption or whatever, it caused a conflict with my phone. Removing microphone permissions for Device Personalization Services in conjunction with uninstalling updates for the Google App (Velvet) and clearing cache will bring my sound back after a reboot in Android 11. Even with DON'T Auto Update Apps checked in the Playstore, the Playstore will update Google Apps the next time the Playstore updates itself. If the Playstore is already updated when I uninstall updates for the Google App, the Playstore, on next reboot, will just roll back it's own update so it can update the other Google Apps and then update itself again. (Sounds crazy but it happens over and over again) If I disable the Playstore, it won't auto update anymore but after an hour or so the phone will shut down on it's own at some point, take a really long time to reboot and when it does it has some default wallpaper, that's not even selectable in Customization, and then sound and mic is gone again. At that point, clearing cache for the the Google App (microphone permissions still removed for Device Personalization Services still denied) and rebooting again will bring sound and mic back once more. If I disable the Google App or change permissions the phone doesn't like, without ever signing into Google or the Playstore, the phone will most likely factory reset itself and I'm back to the beginning. I'm done. I'm gonna try Lineage or something and hope for the best. Though I didn't receive any direct help or guidance, I still appreciate everyone who posted for this device before me as it was still helpful nonetheless.