I thought I would post up a lil speed boost which is really simple amd involves going into developer options and changing the number of background prpcesses option to 0... Thats it. It was night and day my phone is super reactive and smooth as silk when opening and closing apps, even quicker than if theseapps were cached!
I dont know if this has been mentioned before but I thought I would share it with you all.
Also an aggressive app killer also helps, kernel tuners OOM once set to 1000 aggressive helps as well.
My phone is rooted running doomkernel06 and xperia revolution custom rom with no overclocks.
Many thanks
Alex
From my point of view, disabling background processes just slows down multitasking activities.
Just deactivated proccesses for a few minutes to try your theory, and I could notice a general slow down using the recent apps multitasker to switch to different apps. Phone had to constantly reload stuff from the internal memory, peobably due to the fact that disabling background processes just unloads everything else but the main process from ram. That's what I perceived, I have no insight of what that option really does.
[email protected] said:
I thought I would post up a lil speed boost which is really simple amd involves going into developer options and changing the number of background prpcesses option to 0... Thats it. It was night and day my phone is super reactive and smooth as silk when opening and closing apps, even quicker than if theseapps were cached!
I dont know if this has been mentioned before but I thought I would share it with you all.
Also an aggressive app killer also helps, kernel tuners OOM once set to 1000 aggressive helps as well.
My phone is rooted running doomkernel06 and xperia revolution custom rom with no overclocks.
Many thanks
Alex
Click to expand...
Click to collapse
flash monx rom and u dont have to do any of that crap. setting background to 0 essentially just like using an iphone because there is no multitasking capability.
Shedloads of RAM in this phone and someone has suggested crippling one of the standout features that is a boon not a hindrance.
Pathetic and illogical.
You do know your phone has four processor cores, right?
How could you possibly improve performance by letting only one run?
petkob said:
You do know your phone has four processor cores, right?
How could you possibly improve performance by letting only one run?
Click to expand...
Click to collapse
I don't think you understand.
No, scratch that. You definitely do not understand. The OP's (poor) advice is nothing to do with disabling CPU cores.
Sent from my C6603 using Tapatalk 2
kingvortex said:
I don't think you understand.
No, scratch that. You definitely do not understand. The OP's (poor) advice is nothing to do with disabling CPU cores.
Sent from my C6603 using Tapatalk 2
Click to expand...
Click to collapse
Lol Pray tell where you think the background processes run.
The OP isn't disabling the additional cores explicitly. He is disabling them by not allowing any processes to run on them. His idea would make more sense if he would allow for at least three BP.
petkob said:
Lol Pray tell where you think the background processes run.
The OP isn't disabling the additional cores explicitly. He is disabling them by not allowing any processes to run on them. His idea would make more sense if he would allow for at least three BP.
Click to expand...
Click to collapse
Aren't Android apps multithreaded?
petkob said:
Lol Pray tell where you think the background processes run.
The OP isn't disabling the additional cores explicitly. He is disabling them by not allowing any processes to run on them. His idea would make more sense if he would allow for at least three BP.
Click to expand...
Click to collapse
My understanding from reading up on processes and threading in the Android developer docs is this-
Background processes are not using CPU cycles. They are cached in RAM to facilitate quickly restarting the associated app in the state it was in when it was closed.
So, they aren't 'running' anywhere.
If you want to link me to somewhere that states otherwise, then go right ahead as it's a while since I looked into any of this and I'm always willing to learn
Sent from my C6603 using Tapatalk 2
DrKrFfXx said:
Aren't Android apps multithreaded?
Click to expand...
Click to collapse
I don't know how many of them are. For sure, at least the kernel is.
But with multiple cores most of the time you would prefer the threads belonging to the same task to run on the same core, so that the L1 cache isn't flushed on every thread switch. Having your cache contents intact as frequently as possible is only possible when you allow for the other processes to run on the extra cores.
---------- Post added at 03:08 PM ---------- Previous post was at 02:57 PM ----------
kingvortex said:
My understanding from reading up on processes and threading in the Android developer docs is this-
Background processes are not using CPU cycles. They are cached in RAM to facilitate quickly restarting the associated app in the state it was in when it was closed.
So, they aren't 'running' anywhere.
If you want to link me to somewhere that states otherwise, then go right ahead as it's a while since I looked into any of this and I'm always willing to learn
Sent from my C6603 using Tapatalk 2
Click to expand...
Click to collapse
What you say is certainly correct on one core systems. You don't have *real* multitasking there, because you only have one running process at all times. All the others processes sleep at that time. Fast switching between processes gives the illusion of parallel execution.
But the idea of having more than one core is that you can really have the ability to run more processes simultaneously, so with four cores you have the ability to have four tasks use CPU cycles at the same time.
So you're telling me that processes that are low priority and in the background are actively using CPU time?
Please link to documentation as this is interesting to me
Sent from my C6603 using Tapatalk 2
petkob said:
Lol Pray tell where you think the background processes run.
The OP isn't disabling the additional cores explicitly. He is disabling them by not allowing any processes to run on them. His idea would make more sense if he would allow for at least three BP.
Click to expand...
Click to collapse
kingvortex said:
So you're telling me that processes that are low priority and in the background are actively using CPU time?
Please link to documentation as this is interesting to me
Sent from my C6603 using Tapatalk 2
Click to expand...
Click to collapse
That for me would be a huge battery drainer. With no real use. Having backgrounded processes hibernating on RAM seems to be a better option.
kingvortex said:
So you're telling me that processes that are low priority and in the background are actively using CPU time?
Please link to documentation as this is interesting to me
Sent from my C6603 using Tapatalk 2
Click to expand...
Click to collapse
No, of course not. It would be stupid to waste CPU cycles if you don't need them.
What I'm saying is that they *could* actively use CPU time even in the background if they *actively* do something.
What do you think happens when when a program is waked for updating? Does it wait for the foreground process, or does it do its job right away?
petkob said:
No, of course not. It would be stupid to waste CPU cycles if you don't need them.
What I'm saying is that they *could* actively use CPU time even in the background if they *actively* do something.
What do you think happens when when a program is waked for updating? Does it wait for the foreground process, or does it do its job right away?
Click to expand...
Click to collapse
Surely if something is woken up, then it's priority increases and it's no longer classed as a background process.
Anyway, as I previously stated, I could be completely wrong in my understanding of how processes work now as I haven't looked into it for a long time, so instead of this to and fro-ing, why don't you link me to the docs that state this and I can read it for myself?
Sent from my C6603 using Tapatalk 2
DrKrFfXx said:
That for me would be a huge battery drainer. With no real use. Having backgrounded processes hibernating on RAM seems to be a better option.
Click to expand...
Click to collapse
Yet this is the default behaviour. There is no real sense in draining the battery from the point of view of the user, but there are tens of processes that wake up one after another, and you have at least 3-4 times longer battery life, if you deinstall the programs you don't use, and freeze the others with something like Greenify.
---------- Post added at 03:57 PM ---------- Previous post was at 03:50 PM ----------
kingvortex said:
Surely if something is woken up, then it's priority increases and it's no longer classed as a background process.
Anyway, as I previously stated, I could be completely wrong in my understanding of how processes work now as I haven't looked into it for a long time, so instead of this to and fro-ing, why don't you link me to the docs that state this and I can read it for myself?
Sent from my C6603 using Tapatalk 2
Click to expand...
Click to collapse
No, I don't have a link, sorry.
What I said, I took from my head. That is my understanding of how things work. For all I know, I could be as wrong as you are
But seriously, do you still say that on a multitasking OS on a multicore HW you can have only one running process at a time? Now I want a link
This is only my experience, I have basic knowledge of tye android system and i'm only going on what happened when I did it.
And from a computing background the multitasking on a phone is a myth to me. Every app takes up the full screen so from a practicality standpoint you may as well be only using one core.
Also my apps loaded much faster and smoother and ran smoother when they were used.
And correct me if i'm wrong but the four cores could still be utilised if the app was multithreaded?
It worked for me so I thought I would post, every persons different and phone manufacture, if iy works, it works if it doesnt it doesnt
[email protected] said:
This is only my experience, I have basic knowledge of tye android system and i'm only going on what happened when I did it.
And from a computing background the multitasking on a phone is a myth to me. Every app takes up the full screen so from a practicality standpoint you may as well be only using one core.
Also my apps loaded much faster and smoother and ran smoother when they were used.
And correct me if i'm wrong but the four cores could still be utilised if the app was multithreaded?
It worked for me so I thought I would post, every persons different and phone manufacture, if iy works, it works if it doesnt it doesnt
Click to expand...
Click to collapse
If multitasking on a phone was a myth, why wouldn't multithreading be a myth as well?
I am updating my maps, which are many hundreds of megabytes. Why wouldn't I be able to play games, or take a call at the same time? What does the screen have to do with this?
petkob said:
Yet this is the default behaviour. There is no real sense in draining the battery from the point of view of the user, but there are tens of processes that wake up one after another, and you have at least 3-4 times longer battery life, if you deinstall the programs you don't use, and freeze the others with something like Greenify.
---------- Post added at 03:57 PM ---------- Previous post was at 03:50 PM ----------
No, I don't have a link, sorry.
What I said, I took from my head. That is my understanding of how things work. For all I know, I could be as wrong as you are
But seriously, do you still say that on a multitasking OS on a multicore HW you can have only one running process at a time? Now I want a link
Click to expand...
Click to collapse
No, I'm not saying that. I'm saying that background processes are low priority and probably (almost definitely) not using CPU cycles.
Developer docs on processes - http://developer.android.com/guide/components/processes-and-threads.html
Also, a simple Google search will throw up plenty of stuff to read if you're interested
Sent from my C6603 using Tapatalk 2
kingvortex said:
No, I'm not saying that. I'm saying that background processes are low priority and probably (almost definitely) not using CPU cycles.
Developer docs on processes - http://developer.android.com/guide/components/processes-and-threads.html
Also, a simple Google search will throw up plenty of stuff to read if you're interested
Sent from my C6603 using Tapatalk 2
Click to expand...
Click to collapse
This is from your link (emphasis mine):
4. Background process
A process holding an activity that's not currently visible to the user (the activity's onStop() method has been called). These processes have no direct impact on the user experience, and the system can kill them at any time to reclaim memory for a foreground, visible, or service process. Usually there are many background processes running, so they are kept in an LRU (least recently used) list to ensure that the process with the activity that was most recently seen by the user is the last to be killed. If an activity implements its lifecycle methods correctly, and saves its current state, killing its process will not have a visible effect on the user experience, because when the user navigates back to the activity, the activity restores all of its visible state. See the Activities document for information about saving and restoring state.
Click to expand...
Click to collapse
So the definition of a background process is that it is not visible, definitely not that it is not running. What kind of sourcery would be able to run a process without using CPU cycles, srsly?
I think the definition of 'running' and 'background' is the issue here.
As an example, your question about maps updating while doing something else would probably mean that there is a service running in order to update maps. A service is different to a background process.
Background processes are loaded into RAM (running in a basic sense), but not using any CPU cycles. If they are called upon to start and use the CPU , then they are no longer truly background processes as it probably means a foreground or visible process is using it.
In any case, your statement that killing background processes disables CPU cores either directly or indirectly is still wrong
Edit - http://developer.android.com/training/basics/activity-lifecycle/stopping.html
You will have seen from the first link I provided that for a process to be put in the background, onStop( ) has been called. If you check out the flow chart in the above link, you will see that when the process is needed again, onStart( ) is used and causes the process to become visible (not background any more).
Sent from my C6603 using Tapatalk 2
Related
http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1
This is a 200 line patch that according to linux was according to Linus the most impressive result of code that is elegant - 200 lines long - and should be wound into the phone linux as well
---- edit - and here is why it isnt going to be of any use for us...
http://forum.xda-developers.com/showthread.php?t=822756&page=210
and the meat of it from bilboa1 :-
Originally Posted by giulio.alfano
Have you seen these? w_w_w.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1
Phoronix(and Linus) say that is a miraculous 200 lines patch to increase interactivty? Can you consider the inclusion, of course if group scheduling in android 2.6.32 kernel is compatible?
the process groups are created per tty, that wont work on android
you can create process groups by hand however but it doesn't make a lot of sense for android in that case. the goal is to have some intensive tasks into their own group, but theres no intensive tasks and we don't have issues like audio or video lagging
their tweak is especially good if you run a compilation in the background and want to browse the web while waiting without having slow downs.
on android if you browse the web you dont have other cpu heavy tasks in progress usually (like encoding a video or what not)
i hope that was clear enough
I've off works urlaub would bei awesome
Where are the developers, who can say, if it works?
Sent from my GT-I9000 using my Brain
Wouldnt get too excited,phoronix is like the sun of linux news
Sent from my GT-I9000 using XDA App
Already discussed - its useless on phone. Phone will be even slower.
Sent from my GT-I9000 using XDA App
dupel said:
Already discussed - its useless on phone. Phone will be even slower.
Sent from my GT-I9000 using XDA App
Click to expand...
Click to collapse
Lets save statements like these after it has been actually tested.
KhaaL said:
Lets save statements like these after it has been actually tested.
Click to expand...
Click to collapse
Not everything needs to be tested. If you make a program to draw a circle, it wont make a square, let alone cook eggs. (it's the case for this patch at the technical level, beyond the "wow" words from 1st post)
Note: there's other patches in 2.6.37 for responsiveness which are different from the one spoken about here which are actually likely to improve things. But probably not as drastic.
dupel said:
Already discussed - its useless on phone. Phone will be even slower.
Sent from my GT-I9000 using XDA App
Click to expand...
Click to collapse
Got any links to where I can find out what you know?
I was *hoping* that if it made desktops much more responsive under heavy loadings that it would help with the phone - its not like we have slow cpu's in these things Or is it cpu architecture that allows the improvments and the phones just are not compatible? or something else?
just wanting to know more and to hopefully get a dev who thinks its worth taking a look to see - 200 lines of code - *cof* (ducks behind armour) "how hard could it be?" *runs for cover*
i get this sinking feeling from the subtle - and not so subtle comments from you guys tho - that its just not really suited for how android works on a phone....
cbdrift said:
Got any links to where I can find out what you know?
I was *hoping* that if it made desktops much more responsive under heavy loadings that it would help with the phone - its not like we have slow cpu's in these things Or is it cpu architecture that allows the improvments and the phones just are not compatible? or something else?
just wanting to know more and to hopefully get a dev who thinks its worth taking a look to see - 200 lines of code - *cof* (ducks behind armour) "how hard could it be?" *runs for cover*
i get this sinking feeling from the subtle - and not so subtle comments from you guys tho - that its just not really suited for how android works on a phone....
Click to expand...
Click to collapse
Read last 5 pages in hardcore kernel topic.
knowing one and the other about linux, I have to disagree with those who say: it's gonna make your phone slower..
why? in linux, things constantly run in the background. and what this patch does, is give priority to foreground processes. True, there isn't MUCH in the background, so results may not be super, but the compile with 64 threads is just AN EXAMPLE of what it can do. That's the PERFECT situation to demonstrate. This doesn't mean that it sucks for everything else! It just means that it works
So stop *****ing and just test it before you start yapping that it's bad, doesn't work on phones etc... There is no right and wrong here, there is just: test it and see if it works!
i'd like to have a REAL technical discussion with these people here that are so-called experts... Because their arguments (excusez-le-mot) SUCK.
so please adapt your first post, because what they are saying is just guessing and not based on experiments nor experience, which renders it completely useless
Just my 2 cents
dupel said:
Already discussed - its useless on phone. Phone will be even slower.
Sent from my GT-I9000 using XDA App
Click to expand...
Click to collapse
discussion is worthless, you can't convince me with some "maybe this, possibly that", if you say it's useless: give hard numbers or (sorry, but...) stfu!
UPDATE:
i've been reading up on the lkml and i think there are some very interesting possibilities here...
What this program does, is put the tty-bound processes in a special cgroup. While this is done automatically, there is also a possibility to just do the same in userspace. (check Lennart from redhat's solution).
It basicly creates a different cgroup for foreground processes, he does it in the bash profile. But i think that with this in mind, we can create cgroup handler for our "most important" apps to make them more responsive!
I've been looking into hardcore's kernel and it already has cgroup support built in, so it's actually just a matter of using it properly
how? check lennart's comments further in the lkml thread because you have to look out to clean up cgroups when no more processes use it.
Anyway, when properly tuned, it should be even better than the kernel patch people talked about!
These type of changes would suit more underpowered devices like the Hero or G1 but imho I dont know why the galaxy S needs it, my IO after applying OCLF is 2300+ apps, any lag issues are not due to the current modded kernels available as they are really good..
Idk why people don't understand simple things
cgroups does not magically makes your apps more responsive. It makes groups of processes which are scheduled together at the same level instead of doing it per process.
So, the group of "make" processes during a make -j64 get all globally a lower share of resources (than if they weren't grouped), allowing the group "browser" process to get enough resources to be smooth.
Without, each make process (64 of them) would get an equal resource time, which would also be equal to the browser, which ends up not being very nice for the desktop.
Now on the phone.. do you have a make -j64 running [IN THE BACKGROUND]? nope. do you have an heavy process or group of processes running [IN THE BACKGROUND]? nope.
Your front task is always the one taking most resources. If you put it in a group you might even decrease it's performance and responsiveness.
It's a double edged sword. You see, when they schedule the make -j64 process group, your browser is smooth but the make -j 64 process group is *slower*.
So unless a group of processes on the phone are taking too much cpu (i know of none doing that unless they're on the foreground), it's useless
bilboa1 said:
Idk why people don't understand simple things
cgroups does not magically makes your apps more responsive. It makes groups of processes which are scheduled together at the same level instead of doing it per process.
So, the group of "make" processes during a make -j64 get all globally a lower share of resources (than if they weren't grouped), allowing the group "browser" process to get enough resources to be smooth.
Without, each make process (64 of them) would get an equal resource time, which would also be equal to the browser, which ends up not being very nice for the desktop.
Now on the phone.. do you have a make -j64 running [IN THE BACKGROUND]? nope. do you have an heavy process or group of processes running [IN THE BACKGROUND]? nope.
Your front task is always the one taking most resources. If you put it in a group you might even decrease it's performance and responsiveness.
It's a double edged sword. You see, when they schedule the make -j64 process group, your browser is smooth but the make -j 64 process group is *slower*.
So unless a group of processes on the phone are taking too much cpu (i know of none doing that unless they're on the foreground), it's useless
Click to expand...
Click to collapse
very true... that's why it still might be possible to group "your current task" and "all the rest". That (might) give you an advantage still...
and as said: i'm not saying it IS better, i'm saying it might be worth testing
hence the suggestion i put in post 11: make something that puts the application you start in foreground in a dedicated group and EVERYTHING else in another. When you background that process, move it to the "pool" group
it might just help!! (so... don't shoot the idea too soon )
I am reasonably new to the android community and so when I first got the device I looked up some of the most commonly downloaded applications to get an idea for what I should get. Advanced task killer was up there as one of the most popular so I went ahead and downloaded it.
I used it for about a month thinking "alright cool I don't have to search through the stock task manager to force close applications". However I came across several articles at that point stating that with newer smartphone's technology that a task killer was unnecessary and in fact detrimental. All of the articles stated that the phone ran better and smoother when allowed to manage it's applications on its own. While I hadn't really ran into many bugs (just a few glitches here and there) I still thought I might speed up the phone a little bit and decided to stop using it.
Here's the weird part, I start getting bugs AFTER I stop using the task killer! My menus ran slower, the keyboard was not as responsive, I even actually felt like the accuracy of my touches went down. I was patient with it though and gave it time but the problems persisted. After a week of staying off of it (in which I should point out I fully rebooted the phone several times) I decided to start again and boom.
Magically the problems went away, my menus are nice and smooth, keyboard response is perfect, and touches are right on point. I think these articles are getting a little too theoretical in their accusations against task managers. Personally I have mine only set on medium detection and safe auto kill. This basically means it autokills almost nothing and 1 touch kills all of the game/map apps that I told it not to ignore. With modest settings such as these I think that there is very little chance of it upsetting any sort of operative processes of the phone and I mean the bottom line here is the results!
I personally find that my phone runs much better with a task killer than without. So anyway just thought I would share my experience in case it may help anyone, I'd be interested in hearing others as well.
There is no need to use any Task Killer programs anymore, and using them is detrimental to the phone either way. This has been discussed time and time again on this forum and other phones' as well.
dLo GSR said:
There is no need to use any Task Killer programs anymore, and using them is detrimental to the phone either way. This has been discussed time and time again on this forum and other phones' as well.
Click to expand...
Click to collapse
I realize I may have typed a little more than your attention span would allow you too pay attention to so let me shorten this for you.
I got the task killer.
I then read about it being detrimental so I stopped.
I got more bugs/worse functionality of the phone thought it was weird but stuck to it.
After getting fed up after a while I tried using the manager again and everything became quick and smooth again.
Clear now? I'm just posting that this is my personal experience, and I thought it may be interesting to some because it seems contrary to what most are reporting.
tl;dr
Factory reset. If you're being honest and not missing something you have a rogue app or setting causing a problem. Start fresh and you'll see that using a task manager and killing apps yourself is not the way to go.
The only thing I keep mine for is for killing rogue apps. And that's not a very common occurrence if you're doing things right and not downloading ****ty apps from stupid devs.
bongd said:
tl;dr
Factory reset. If you're being honest and not missing something you have a rogue app or setting causing a problem. Start fresh and you'll see that using a task manager and killing apps yourself is not the way to go.
The only thing I keep mine for is for killing rogue apps. And that's not a very common occurrence if you're doing things right and not downloading ****ty apps from stupid devs.
Click to expand...
Click to collapse
haha well at least you admitted to it in the beginning, hopefully you caught the boiled down version then.
It's interesting that you mention the rogue app issue. I don't have any of the problems I usually hear about in the forums when that is the case, although I do use words with friends, which i realize is buggy but it plays against friends and family that have iphones as well.
I doubt that is the culprit though, the problems and slowdowns I was experiencing are mainly things i have seen people mention as problems with the phone in general.
JonEleven said:
haha well at least you admitted to it in the beginning, hopefully you caught the boiled down version then.
It's interesting that you mention the rogue app issue. I don't have any of the problems I usually hear about in the forums when that is the case, although I do use words with friends, which i realize is buggy but it plays against friends and family that have iphones as well.
I doubt that is the culprit though, the problems and slowdowns I was experiencing are mainly things i have seen people mention as problems with the phone in general.
Click to expand...
Click to collapse
Once you break the phone in and all the apps load and cache it should be smooth as butter. A brand spanking new refresh isn't always the quickest. I find that after a few hours usage (after a complete wipe) that things start really moving along.
In my task killer I have damn near every program excluded as well. And a nice thing about Froyo is that system apps and important things usually aren't killed anyway. I set my task killer this way as a buffer because I really don't want to kill anything in the background that doesn't need to be killed. Doing that can make it relaunch in the foreground thereby slowing things down when the program wasn't using any resources to begin with.
A lot of it is a matter of perception too - a lot of people get OCD about managing tasks manually and start killing things, falsely perceiving that speeds are picking up and that they're improving battery life. Fact of the matter is that it's other factors which are leading to success. Killing tasks is inherently flawed because you're waking up apps which aren't doing jack **** to begin with.
Today I purchased the full version of SystemPanel. The reason was simple. I wanted information. The product was exactly what I needed. An app that gives real time and historical information on: battery charge and discharge; CPU utilization; phone usage, the list goes on. After two hours I noticed that it showed CPU cycles from apps that should be idle... Pandora and Amazon App Store... so I opened Pandora and saw it was stuck in a search. I exited Pandora and suddenly the CPU dropped and rate of battery drain slowed. What makes this a great app is the historical view and the ability to see historical CPU usage at the individual application level and compare to the overall phones CPU, usage and battery level. The end result is solid information on where and when the juice goes. The help describes why they will never implement an Auto-Kill feature, i.e. does not save any juice and if an app is not behaving... don't kill it, fix the problem or uninstall! Hope this helps!
jjwatmyself said:
Today I purchased the full version of SystemPanel. The reason was simple. I wanted information. The product was exactly what I needed. An app that gives real time and historical information on: battery charge and discharge; CPU utilization; phone usage, the list goes on. After two hours I noticed that it showed CPU cycles from apps that should be idle... Pandora and Amazon App Store... so I opened Pandora and saw it was stuck in a search. I exited Pandora and suddenly the CPU dropped and rate of battery drain slowed. What makes this a great app is the historical view and the ability to see historical CPU usage at the individual application level and compare to the overall phones CPU, usage and battery level. The end result is solid information on where and when the juice goes. The help describes why they will never implement an Auto-Kill feature, i.e. does not save any juice and if an app is not behaving... don't kill it, fix the problem or uninstall! Hope this helps!
Click to expand...
Click to collapse
I've got this app purchased as well. I usually uninstall it unless I suspect that a program is running wild like how you've described.
bongd said:
I've got this app purchased as well. I usually uninstall it unless I suspect that a program is running wild like how you've described.
Click to expand...
Click to collapse
Seems that out of all of the apps out there, these guys dug in to do something of use. Now I can post screen shots of the Moto car dock charging problem that I have.
i don't think ATK is really detrimental...i've been using it and as long as you keep everything in check, it should run fine, just make sure the apps that are being killed are the ones you want killed.
I had ATK installed on my Atrix pretty much since day 1. Then i realised i was being an idiot to have it running in the background when i never really used it. Instead, i always just used the standard task manager, and added apps that i didn't see a point in having sit idle in the background to the auto-end list. Works quite well, and no annoying "Touch here to launch Advanced Task Killer" crap in the notification pane.
Unless there is a technical challenge it's best to kill tasks as sparingly as possible. End of discussion
I think you are missing the simple fact that killing tasks has no impact, positive or negative, on Android.
Sent from my MB860 using Tapatalk
elementaldragon said:
I had ATK installed on my Atrix pretty much since day 1. Then i realised i was being an idiot to have it running in the background when i never really used it. Instead, i always just used the standard task manager, and added apps that i didn't see a point in having sit idle in the background to the auto-end list. Works quite well, and no annoying "Touch here to launch Advanced Task Killer" crap in the notification pane.
Click to expand...
Click to collapse
Same here, using the stock one, the auto end list too free ram. I noticed many apps that I don't use very often load on startup and run in the background.
Sent from my MB860 using XDA App
slimslim said:
Same here, using the stock one, the auto end list too free ram. I noticed many apps that I don't use very often load on startup and run in the background.
Sent from my MB860 using XDA App
Click to expand...
Click to collapse
Free ram has no impact on performance or battery on Android. Killing a task should always be adhoc and not automatic.
Sent from my MB860 using Tapatalk
bongd said:
Unless there is a technical challenge it's best to kill tasks as sparingly as possible. End of discussion
Click to expand...
Click to collapse
Agreed!
Sent from my MB860 using Tapatalk
I have mine set to close only a few programs that eat battery in the background. Like the xda app.
Sent from my MB860 using XDA Premium App
jjwatmyself said:
Free ram has no impact on performance or battery on Android. Killing a task should always be adhoc and not automatic.
Sent from my MB860 using Tapatalk
Click to expand...
Click to collapse
Not entirely true, does impact the performance and is noticeable especially when I have less than 100 megs available. Even on my old winmo phone more free ram made a huge difference. Also has little impact on battery while apps running on background use cpu.
Sent from my MB860 using XDA App
I realize you're a douche, so bite me.
JonEleven said:
I realize I may have typed a little more than your attention span would allow you too pay attention to so let me shorten this for you.
I got the task killer.
I then read about it being detrimental so I stopped.
I got more bugs/worse functionality of the phone thought it was weird but stuck to it.
After getting fed up after a while I tried using the manager again and everything became quick and smooth again.
Clear now? I'm just posting that this is my personal experience, and I thought it may be interesting to some because it seems contrary to what most are reporting.
Click to expand...
Click to collapse
Sent from my MB860 using XDA App
dLo GSR said:
I realize you're a douche, so bite me.
Sent from my MB860 using XDA App
Click to expand...
Click to collapse
Haha no need to get hostile man, you just clearly had not read my post.
At least have the decency to put tl dr beforehand if you are going to do that, because your first response literally almost quoted something I had already written
And I have to agree with slimslim about the ram, I find it very noticeable when the level of free ram gets down to around 100
So do you guys use it and what does it exactly do? And also what does 3g turbocharger and kick ass kernel tweak do?
Basically everytime the memory drops below the thresholds set by v6, the system will start killing of apps running in the background which frees up memory that you most probably aren't using, Im currently on the aggressive settings so everytime my memory drops below 150mb the system starts killing apps. Its basically just tweaking the internal task killer to be slightly more aggressive. It also locks the launcher so the system cannot kill it if the memory drops too low.
The 3g tweaks, I think adjust or add some settings to the build.prop which supposedly make it faster although I haven't noticed much difference with that and the kernel tweaks I'm not too sure where the changes are made but again I don't see a great change from it. Definitely recommend v6 supercharger though.
Sent from my HTC Wildfire using xda premium
Scratch0805 said:
Basically everytime the memory drops below the thresholds set by v6, the system will start killing of apps running in the background which frees up memory that you most probably aren't using, Im currently on the aggressive settings so everytime my memory drops below 150mb the system starts killing apps.
Click to expand...
Click to collapse
Great. Let's take 150MiB of RAM and then don't do anything useful with it. Processes aren't supposed to be killed unless you actually run out of memory.
Scratch0805 said:
It also locks the launcher so the system cannot kill it if the memory drops too low.
Click to expand...
Click to collapse
That seems innocent, but it won't help you if the launcher has a memory leak. If the launcher kept getting killed, it was telling you that your low memory thresholds are too high. Under normal circumstances, the launcher won't get killed. But if it grows too much, it'll get killed and the OS won't crash.
When you force close an application through the application manager, it shows you a warning. There's a reason for that (exactly what it says). And since Android 2.2, the framework can take care of itself just fine. No need for any 3rd party task killers.
Lol..... Thought you'd have something to say on it, actually mate the way my phone is usually setup there is nothing running in the background to kill anyway, thanks to autostarts I only have apps running that I need and make sure that I close things properly after use, so it really doesn't matter which settings I use whether they be low such as 30mb before it starts killing the first lot of empty apps or high such as 150mb as my setup rarely drops below because there is only the bare minimum running in the first place.
Sent from my HTC Wildfire using xda premium
Allright, it's not that RAM would slowly wear and tear by using it but at least you're not buying that it's better for performance. And I just wonder how these apps are made, as a thought experiment to figure out the mindset of whoever wrote this task killer.
...So let's make an app which looks real cool and doesn't do anything useful in particular! Wait, no one would download that! Hmm... Oh, I know! Let's call it "V6 Supercharger"! Yeah, that sounds awesome! Now people will download it for sure! It's the coolest thing since sliced bread!
It's the same with those programs like "Registry Booster". How did that happen? Someone must've woke up one day, turned on his PC, started poking in the registry, saw lots of keys which aren't really strictly necessary but are there anyway and thought like "Hmm, what if I made a program which removes all these unneeded keys? MS-Windows would be ZOMG faster!!111eleventyone". Then made it look real slick with a custom skin and a speedometer showing progress and say at the end that the registry has been "boosted". And since this guy is such a nice fellow, he threw in some extra free toolbars into the mix as well. Users always appreciate having more toolbars to click on and agreements to ignore.
Ok, I'll stop ranting now. Enjoy your week
Try explaining that to the dev who created it here. Honestly, it would be better, because, I am pretty sure most members here are not as technically inclined as you.:
http://forum.xda-developers.com/showthread.php?t=991276
You're just setting him up so I can tear him apart... aren't you?
The poor bastard doesn't even know what it is... he thinks it's a task killer app... heh
No, I would like him to discuss all the technical aspects with you. Because, clearly, he's wasting his effort as a developer here educating non-technical people like me, and the majority here on the Wildfire Forums.
And before you accuse me of trying to set people up, I can assure you I have nothing against you / your script or anything. Rather, I have used your script, and came away impressed with it.
I know you you weren't doing anything like that... I'm always putting down these clowns that think that suffocating the phone is good... idiots lol
Like I say, what the hell good is phone if you can't make a call because of some crap hogging the ram?
Besides, I doubt very much he has any technical skills at all... like I said before, he doesn't even know what it is so he's not very techinical
dud3me said:
what does it exactly do?
Click to expand...
Click to collapse
It makes you feel good.
And I definitely noticed a 0.00001ms speed difference when opening apps.
Another liar
zeppelinrox said:
Another liar
Click to expand...
Click to collapse
Yeah lol. Most people in this forum are wannabe developers who know **** about developing but they like to act like they do. Apart from few people who actually know stuff and the others like me who acknowledge the fact that we don't know anything
Fact is, those who know they don't know learn more than those that think they know it all
Less than a year ago, I knew 0 about android.
And when I started the supercharger script, I knew nothing about linux scripting.
Just started off with a few commands and everytime I wanted to try something new or add something... I googled it up.
And I'm still figuring it out.
For example, I set my 256mb device to have 25mb free with the number I use in slot 3.
So whatever memory tool I use will show I have 25 or 30mb free... great - that's what I want
But when I was doing up the recent update and enhanced the Fast Engine Flush, I wanted to show before and after using the "free" command.
To my surprise, system tuner shows that I have 30mb free while the free command shows I have only 5mb free!
So what's that mean? Why that difference of 25mb?
It means that all that "free ram" is actually being used for cache.
And it's giving me speed
So to those that think it's great to have ram clogged with apps when the system is starving for space to use for cache...
BOOYA!
Really have trouble using your scripts and I think after enabling 3gturbotweak thing my 2g data isn't working haven't tried 3g.
I can't recall it affecting 2g... so I assume 2g used to work (I don't get 2g - it's unavailable)
But if you unturbocharge, the 2g/3g goes back to normal, no?
zeppelinrox said:
I can't recall it affecting 2g... so I assume 2g used to work (I don't get 2g - it's unavailable)
But if you unturbocharge, the 2g/3g goes back to normal, no?
Click to expand...
Click to collapse
Well I had to format system data and cache and wiped everything and now it's working again so I'm not completely sure if it was the turbocharge thing.
The idea that you can magically "supercharge" your OS by freeing up memory is fundamentally flawed.
what the hell good is phone if you can't make a call because of some crap hogging the ram
Click to expand...
Click to collapse
If this is really a problem on your phone, you're doing it wrong. I haven't done anything to free up ram and the amount of ram available on my wildfire is currently 108,48MiB. I start 10 random apps, Angry Birds, and Angry Birds Rio. 40,68MiB still free. I start Angry Birds Seasons and end up with 49,66MiB free and 9 apps died, including the first angry birds. Running out of ram is in general not a failure mode of Android and at no point was I unable to place a call. I close the 2 remaining open instances of Angry Birds the normal back-button way, 147,68MiB free.
I'm always putting down these clowns that think that suffocating the phone is good... idiots lol
Click to expand...
Click to collapse
I just wanted to quote that.
And when I started the supercharger script, I knew nothing about linux scripting.
Just started off with a few commands and everytime I wanted to try something new or add something... I googled it up.
Click to expand...
Click to collapse
That's exactly the impression I had. Now take it from someone who has run Linux both embedded and on his desktop for the past 12 years. Your app doesn't improve anything, and I'd be glad to be proven wrong because you would've actually made a discovery we can use to improve Android and Linux with. From your post I understand it you change vm kernel parameters such that the oom killer is invoked sooner. This is actually detrimental to the stability of the OS, the oom killer is only meant to be invoked as a _last_resort_. The Android framework has its own means to free up memory, including calling onLowMemory in any application and doing a gc run. This does not cause instability and is completely transparent to the user. I've only ever had to manually kill applications in a broken state and others for debugging purposes, which is why the Force Close button exists.
It means that all that "free ram" is actually being used for cache.
And it's giving me speed
Click to expand...
Click to collapse
If the output looks anything like this:
Code:
total used free shared buffers cached
Mem: 3456 3325 131 0 10 93
-/+ buffers/cache: 3221 235
Then you've just never bothered to look. You can clearly see in the second line it makes a calculation for you which is exactly what it says in the leftmost column. And of course completely disregard the fact that cached pages are invalidated on a write (marked dirty) and reads from an mtd are really fast already anyway.
So to those that think it's great to have ram clogged with apps when the system is starving for space to use for cache
Click to expand...
Click to collapse
This is not how it works! For starters, ram cannot be "clogged". A drain pipe can be clogged but ram is made of digital circuitry, not plumbing. And second, there is no resource starvation in the page cache. It's just an old optimisation to keep data pages in memory for longer to serve repeated reads and give them back whenever they're needed for something else. More apps in ram can actually mean less reads are necessary because the data is already there (especially if you tend to switch between recent apps). Since Android 3.0, application developers are encouraged to use Loaders which cause filesystem I/O to be performed on a background thread. And applications which actually use the available ram always trump applications designed to use as little ram possible in performance. Between a collection of loaded objects and a cached filesystem, the collection always wins. You have 256 to 512 MiB of RAM in a typical Android device. The average application is 18 to 30 MiB. It can manage. Especially when you consider the fact that the UI only shows 1 task at a time and pressing the back button usually destroys the activity you were in. The gc takes care of its remains.
Now here's something which will actually improve write speeds on /data: Open up settings, applications, manage applications. Sort by size. Remove the biggest apps you don't need and move the rest to SD if you can (you can use "pm setInstallLocation 2" as root to move non-froyo-aware apps to SD). I've been using the market a lot lately so I just removed aDosBox, Albert Heijn, PocketCloud, Pulse and moved Dolphin Browser to SD which meant 47.25MiB free on /data. On a 175MiB partition, 30% of it is about 52MiB so I'd try to keep the available space around 50MiB. If your phone is low on storage, doing this will perceivably improve performance.
dud3me said:
Well I had to format system data and cache and wiped everything and now it's working again so I'm not completely sure if it was the turbocharge thing.
Click to expand...
Click to collapse
Same thing happened to me, but every time i turned 3g on the phone rebooted and i got stuck in a bootloop, i had to use the ruu update to restore phone.
I would stay away from the network tweaks. It doesnt improve speed anyway.
Sent from my HTC Wildfire using xda premium
henkdv said:
The idea that you can magically "supercharge" your OS by freeing up memory is fundamentally flawed.If this is really a problem on your phone, you're doing it wrong. I haven't done anything to free up ram and the amount of ram available on my wildfire is currently 108,48MiB. I start 10 random apps, Angry Birds, and Angry Birds Rio. 40,68MiB still free. I start Angry Birds Seasons and end up with 49,66MiB free and 9 apps died, including the first angry birds. Running out of ram is in general not a failure mode of Android and at no point was I unable to place a call. I close the 2 remaining open instances of Angry Birds the normal back-button way, 147,68MiB free.
Click to expand...
Click to collapse
All that you said is very informative.
What are your minfrees?
Set them to something like 6, 12, 16, 18, 26, 30.
Run a bunch of apps...
See how great it runs then
Fact of the matter is, user's with 1GB ram devices notice a real improvement.
Not placebo.
Pressing the home or back button has an instant effect without hesitation - which indeed happens on stock roms.
Yes in theory I'm sure it all makes sense and I apologize for using layman's terms such as "clogging".
An android phone is not a Linux PC so I believe it's not a great idea to configure it like it is a Linux PC.
They have difference purposes.
Anyway, in theory, a bumble bee can't fly - but it does.
Hello...
A simple tip for today...
Do you run stock 4.0.3? Want to have some faster performances?
Try the tip of the day:
1. Open Settings>Developers Options>Force GPU Rendering(enable it)
2. Kill all the background apps(long press Home key and swipe all away)
3. Restart the phone.
You will surely notice a bump of improvement.
Recognizable improvements in: Facebook, Twiiter, Whats-app, XDA, Gmail etc...
Let me know if it worls!
Cheers!
Sent from my Nexus S using xda premium
we will see
HAKA said:
Hello...
2. Kill all the background apps(long press Home key and swipe all away)
Click to expand...
Click to collapse
this just hides the most recent apps. it does not kill any background process
praveenmarkandu said:
this just hides the most recent apps. it does not kill any background process
Click to expand...
Click to collapse
Besides, most (if not all) apps that appear there are cached and they are not actually running. Exceptions are some apps that insist on having useless services running all day (for example, facebook, eats around 7-8mb RAM while doing nothing). The more cached processes you actually have, the faster these apps will launch so it doesn't make much sense to go and kill them all.
Unix works the same way. Currently on my computer with 8GB RAM running only Chromium and Pidgin (an IM app) it says I am using 6573mb of RAM! Is that possible? Well, I actually use 570mb but the rest are all cache. Since unused RAM = wasted RAM, it caches disk files I use all the time for faster access. Nothing is lost and you gain some speed. I am pretty sure Windows does the same too, at Task Manager under the CPU/RAM graphs is a small box with RAM usage, I remember it saying 'Cache' there too, but it doesn't add it to the 'Used' RAM counter so you think it's really really empty.
What does enabling Force GPU rendering do to the battery life?
HAKA said:
2. Kill all the background apps(long press Home key and swipe all away)
3. Restart the phone.
Click to expand...
Click to collapse
Restarting the phone would clear all the background apps anyway
onthecouchagain said:
What does enabling Force GPU rendering do to the battery life?
Click to expand...
Click to collapse
Did not see a difference. But it's not smoother though...
Problem is you will break apps that aren't yet ready for hardware acceleration.
Facebook performs much better
Sent from my Nexus S using xda premium
maybe can make some unstable apps, maybe it's better to wait for all apps support ics and their "api"
sakisds said:
Besides, most (if not all) apps that appear there are cached and they are not actually running. Exceptions are some apps that insist on having useless services running all day (for example, facebook, eats around 7-8mb RAM while doing nothing). The more cached processes you actually have, the faster these apps will launch so it doesn't make much sense to go and kill them all.
Unix works the same way. Currently on my computer with 8GB RAM running only Chromium and Pidgin (an IM app) it says I am using 6573mb of RAM! Is that possible? Well, I actually use 570mb but the rest are all cache. Since unused RAM = wasted RAM, it caches disk files I use all the time for faster access. Nothing is lost and you gain some speed. I am pretty sure Windows does the same too, at Task Manager under the CPU/RAM graphs is a small box with RAM usage, I remember it saying 'Cache' there too, but it doesn't add it to the 'Used' RAM counter so you think it's really really empty.
Click to expand...
Click to collapse
I want what you say to be true, but there are some apps that aren't just cached but actually have background services running.
When you go an flick them off that apps list it doesn't just free up the ram from the cached activity but also the background services that were spawned from it. With some of the apps I launch it's noticeable if I clean up those old activities first.
try aosp+ by androiduser and flash eugene's icup kernel. you'll be surprised that speed is comparable to gb
Any difference you'll notice should be just placebo =]
Well this was a misleading thread. Whole bunch of nuthin.
The best way to speed up ics is to flash vhgomez's 1.2 or Crossbones rom, along with Eugene's Speedy3 kernel.
Braneless said:
Well this was a misleading thread. Whole bunch of nuthin.
The best way to speed up ics is to flash vhgomez's 1.2 or Crossbones rom, along with Eugene's Speedy3 kernel.
Click to expand...
Click to collapse
+1
Sent from my Nexus S 4G using XDA App. Developer of brickROM, and OP of XDA Thread of The Year 2011.
haha i dont know but not see much difference here
but thx
praveenmarkandu said:
this just hides the most recent apps. it does not kill any background process
Click to expand...
Click to collapse
Not true. Op is correct. Swiping them DOES kill the process.
Flashing a different kernel increases the speed alot. I'm using eugene's ICUP speedy 3 kernel and it's really fast!
obsanity said:
Not true. Op is correct. Swiping them DOES kill the process.
Click to expand...
Click to collapse
No, go away.
lvnatic said:
No, go away.
Click to expand...
Click to collapse
Umm OK. I'll just be in another thread
Just decided to use my Nexus 10 after about a day or two of inactivity, and I noticed it was real sluggish. Went over to Running apps, everything shown there is Restarting, and there is only about 77MB of RAM free.
I've had this happen a few times I believe.
Is this scenario avoidable in any way?
espionage724 said:
Just decided to use my Nexus 10 after about a day or two of inactivity, and I noticed it was real sluggish. Went over to Running apps, everything shown there is Restarting, and there is only about 77MB of RAM free.
I've had this happen a few times I believe.
Is this scenario avoidable in any way?
Click to expand...
Click to collapse
Free RAM isn't usually a problem: Android will cache things in memory to help them load faster, so normally seeing <100mb of free RAM isn't anything to be concerned about, and will not affect performance at all.
The sluggishness and "restarting" services sound like something bad, though.
First, make sure you aren't running any kind of automatic task manager/killer. Next, after restarting your device, keep an eye on that running services tab in Android settings: apps. See if any of them seem to be growing in RAM use disproportionately to the others. It may take a few hours to show up.
I suspect you have one bad app with a leak causing low memory to force the other services out of memory.
Even after caching and such this tablet should normally have 400-600MB of free RAM though. The low amounts definitely come from a memory leak. Right now the general consensus is that it cannot be avoided because it is a problem with the GPU driver. How much truth there is to this I dont know. I do know that I myself did not have performance issues or memory leaks when I was back on 4.2.1 running CM10.1, so I still feel like something in 4.2.2 introduced a memory leak.
EniGmA1987 said:
Even after caching and such this tablet should normally have 400-600MB of free RAM though. The low amounts definitely come from a memory leak.
Click to expand...
Click to collapse
It is normal and expected for free memory to dip lower than that during normal operation. It is simply inaccurate to tell people otherwise.
I would caution against claiming something is "definitely" anything with so little solid information.
It might be that there is a memory leak, but it is much more likely to be a user app than a kernel memory leak until there is hard data saying otherwise. As of now there is only one highly subjective user report.
During operation yes, but when you pick it up after days of the tablet idling with nothing running?
There is plenty of solid information if you have looked around the development threads with all the activity trying to pin down the memory leaks everyone is having, to say one doesnt exist just shows how little you have been getting around the threads.
ZanshinG1 said:
Free RAM isn't usually a problem: Android will cache things in memory to help them load faster, so normally seeing <100mb of free RAM isn't anything to be concerned about, and will not affect performance at all.
The sluggishness and "restarting" services sound like something bad, though.
First, make sure you aren't running any kind of automatic task manager/killer. Next, after restarting your device, keep an eye on that running services tab in Android settings: apps. See if any of them seem to be growing in RAM use disproportionately to the others. It may take a few hours to show up.
I suspect you have one bad app with a leak causing low memory to force the other services out of memory.
Click to expand...
Click to collapse
Nothing in Recent apps, I had all my usual apps installed. Most of the time when I'm doing nothing I have hundreds of MB of RAM available as free space.
No Task Killers either. Couldn't even open a game I had (would instantly go back to launcher, no FC message) or take a screenshot even.
Just my personal experience, but I have owned my N10 since December and frequently let mine idle for days and have never come across this issue yet. Memory on mine is usually above 600MB everytime I check it in the Apps setting, I don't think I've ever seen it go under 100 since I've owned it, and I do go in there a lot to force stop certain things that autostart. I am leaning more towards what ZanshinG1 said that its a rogue app installed thats eating it
EniGmA1987 said:
During operation yes, but when you pick it up after days of the tablet idling with nothing running?
There is plenty of solid information if you have looked around the development threads with all the activity trying to pin down the memory leaks everyone is having, to say one doesnt exist just shows how little you have been getting around the threads.
Click to expand...
Click to collapse
I suspect we have different standards for what qualifies as useful information. Let's just leave it at that.
---------- Post added at 07:08 PM ---------- Previous post was at 07:03 PM ----------
espionage724 said:
Nothing in Recent apps, I had all my usual apps installed. Most of the time when I'm doing nothing I have hundreds of MB of RAM available as free space.
No Task Killers either. Couldn't even open a game I had (would instantly go back to launcher, no FC message) or take a screenshot even.
Click to expand...
Click to collapse
Do you have any apps which use OpenGL ES running? Games and live wallpapers are the usual suspects.
ZanshinG1 said:
I suspect we have different standards for what qualifies as useful information. Let's just leave it at that.
---------- Post added at 07:08 PM ---------- Previous post was at 07:03 PM ----------
Do you have any apps which use OpenGL ES running? Games and live wallpapers are the usual suspects.
Click to expand...
Click to collapse
Nope, nothing was open at the time, and had a normal wallpaper (non-Live).
ZanshinG1 said:
I suspect we have different standards for what qualifies as useful information. Let's just leave it at that.
Click to expand...
Click to collapse
For the record surfaceflinger will eat about 100 megs per hour of video when you watch YouTube through chrome. I've duplicated this on stock, CM, mrrobinson AOKP, and raspbean. At about 600 megs the tablet will start misbehaving, closing apps, being sluggish, keyboard won't come up in chrome when you go to the address bar, etc. If you can stand to wait it will eventually reboot usually when idle in my case. Oddly enough the YouTube app doesn't produce the same results on the same video.
The usefulness is debatable. The facts are not.
Sent from my Nexus 4 using Tapatalk 2
Hopefully ROM dev's will add some newer AOSP commits to their ROMs too, such as:
Fix a minor leak in dvmCreateInlineSubsTable (commit to aosp)
minor leaks caused by failed initialization in JNI_CreateJavaVM (commit to aosp)
Fix a minor bug in dvmCreateInterpThread (commit to aosp)
Fix some leaks in VfyBasicBlock & BitVector (commit to aosp)
But it is probably a rogue app.
EniGmA1987 said:
But it is probably a rogue app.
Click to expand...
Click to collapse
Chrome?
So for s&gs I installed naked browser and I'm not seeing the climb like I did with chrome. After about 4 hours of YouTube it went up 4 megs instead of 400 megs. I just saw another user seem to confirm this too.
Sent from my Nexus 4 using Tapatalk 2
rxnelson said:
Chrome?
So for s&gs I installed naked browser and I'm not seeing the climb like I did with chrome. After about 4 hours of YouTube it went up 4 megs instead of 400 megs. I just saw another user seem to confirm this too.
Sent from my Nexus 4 using Tapatalk 2
Click to expand...
Click to collapse
I don't watch videos from Chrome, and it wasn't open at the time either (I may of opened it earlier before I noticed the memory leak, but I know I swiped it away from Recents when I was done with it). I didn't use the YouTube app either.
Had it occur again, although it wasn't "as" severe since I was able to load a game and take screenshots this time; performance was definitely slower though...
Running Apps:
Cached Apps:
Maybe run PS in terminal the next time and grab a screenshot. Then after reboot or return to normal do it again and compare usage?
Sent from my Nexus 4 using Tapatalk 2
I have my tablet reboot every night at 4am with Tasker-Secure Settings plugin. Maybe not a fix for the issue at hand, but enough to make this problem go away permanently and reliably.
Easy fix: don't use trash roms like aokp or cm
I personally use team eos and ktmanta and the system runs super smooth with no memory leaks what so ever. After 32 hours if I clean all apps I got 600 or 700 mb free.
lvnatic said:
Easy fix: don't use trash roms like aokp or cm
I personally use team eos and ktmanta and the system runs super smooth with no memory leaks what so ever. After 32 hours if I clean all apps I got 600 or 700 mb free.
Click to expand...
Click to collapse
Wow. Talk about trash talk.
I've never ahd this issue on AOKP or CM, have on PA... I did enjoy Eos when I used it but found RootBox had the features I needed. Then again... I reboot every few nights typically. My mom leaves her Nexus 7 on for weeks on end with no issue, but its not a 10.
lvnatic said:
Easy fix: don't use trash roms like aokp or cm
I personally use team eos and ktmanta and the system runs super smooth with no memory leaks what so ever. After 32 hours if I clean all apps I got 600 or 700 mb free.
Click to expand...
Click to collapse
I don't consider rasbeanjelly trash...
I think I've run into this bug once, after a couple days of usage, likely mostly inactive without charging. I noticed that everything I tried to do was really sluggish and once I saw all the apps restarting in the built-in task manager, I figured something was seriously borked, so I rebooted the tablet and it was back to normal. Given all the other stability problems others have reported with this tablet, I'm glad just a very occasional reboot like this is the worst of my problems. :victory: I'm running stock Android 4.2.2, with only a handful of apps installed, probably more default apps uninstalled than apps added.