PLEASE READ: Do NOT worry about Apps running in the Background

[Hostility6]

Hmmm....been wondering about this.

 

[dub8420]

So App killer apps are pointless to have on the phone, basically? is there any need for me to even have it installed?

 

[trainryche]

@Dream... background processes in the linux OS use almost no cpu or memory usually. As I am writing android apps on Ubuntu Linux, I am looking at the list of tasks running in the background, there are quite a few, and all barely use any memory or cpu. They will be task switched just like any app you run.

@Getaphixx -

1. Apps could possibly use battery life... (Why would I want to let that happen?)

Keep in mind Android phones can run mulitple apps at once. Because of this it is paramount that app developers use all possibilities to properly shut down their apps. One thing you have to remember, unlike any other phone you have used including iPhone, clicking on back, home, etc is NOT going to shut down the app. If you need to go back to the home screen, that app is still running most likely. There are ways a developer can "listen" for when a user does this and shut down their app to mimic how iPhone does it, for example. I am guessing most app developers don't do that tho. I've seen many apps with EXIT/QUIT options, and many without. This is sadly one of the few things I fear non-techie users are not going to understand or realize, especially coming over from iPhone. The home/back button doesn't exit an app if the developer doesn't program it that way. As you are seeing, many apps remain running. HOWEVER, what you should know is.. most apps are sort of suspended when this happens. While you can run multiple apps in the background, only services run continually in the background. All apps, while you can run several, only the FOREGROUND app is actually consuming resources, including cpu cycles and memory. What happens when you switch apps that are not services (services you can't see anyway as they do not have an user interface), they have several signals (hooks, intents, etc) sent to them to allow a developer to save the state of the application, release any resources not needed like DB connections, network, etc, so that while it is suspended, those resources are given back to Android for another app that becomes the foreground app, to use. However, this is both the greatest and worse feature of such an open system as Android. Because Java is the largest language choice right now and Android 2.0 is out, and more phones are coming, and tablets, etc.. you are going to see a plethora of java developers jump on this bandwagon. You are going to see a huge amount of apps hit the store. And you are going to find a LOT of those apps are inexperienced developers trying to mimic the iFart sensation to make millions and retire in 6 months, yet will completely ignore many of the requirements to be a good citizen in the android app world. So, many apps are NOT going to properly release resources, they wont save state, etc. So you will find more and more apps that are going to eat up memory and thus when you kill it using ATK, you'll see resources released and more memory for you to use.

Here is the thing to know tho.. Android is in control. Period. Android WILL KILL AN APPLICATION FOR YOU! In other words, if you start running out of memory, Android will send some signals to the app saying "Yo.. I really really need to use some of those resources you got tied up.. so I am shutting you down, completely. Here's your last chance to save any state..." and boom! Gone. Android thus will indeed handle memory as needed on the fly for you. Now.. what happens when you switch back to that app you left running but Android shut down? Well, it starts up again. If the app was built correctly, it will receive a bundle of info pertaining to state info that it should have saved when Android killed it. If done right, it will resume as if nothing happened. You will see a slightly longer delay than if it was still running, as it is now starting up a JVM again to run the app in, and the app may have to reload some state, screens, tiles, graphics, sounds, etc.


3. I don't use my phone for 45min.. And previously used App Killer to disable multiple items.. I come back.. I have things like Alarm Clock and others that have NO business being opened much less running... I kill them.. Jump from 65 to 104mb of memory..

This one does iritate me too.. I am not sure what controls alarm clock coming back to life. I suspect it is a SERVICE app with an interface tho. Service apps can run in the background.. so most likely the Alarm Clock app installed a service as well..that DOES run even when you shut down the alarm clock app. Every so often that service executes in the background and realizes alarm clock isn't running but it needs to, as the alarm clock app is the one that will make use of your ring tones that you selected in the alarm clock app to wake you up with, etc. That is my guess. I am not completely sure tho how this is done yet. I have only begun developing and got a lot to learn yet.


4. Please tell me how killing UNEEDED items is a waste...lol

It is indeed a waste. I am telling you now as a developer, albeit a new one, but one who has been doing java for over a decade and understands the basics of how all this works. Android WILL shut down apps (as I explained above in detail) when it needs to in order to reclaim resources so that the top app (foreground) might have resources to do something with. Even if the foreground app doesn't need them, Android will kill apps if need be as necessary. As I said above, even tho it actually shuts the app down, it goes thru steps to allow an app to cleanly shut down AND recover from the shutdown as if it was never shut down. The app developer just has to write the code correctly to handle this situation.

So, essentially, killing apps becuase you are afraid you are running out of memory is not needed. There is ONE possibility tho.. an app could run out of memory itself! It could load a very large dataset into memory and not have enough. I haven't found/read anything about how Android itself handles swapping memory to disk.. as I don't think you can set up swap memory to the SD card. It would be VERY nice if you could do this, it would allow more robust apps to at least use more memory than 128MB or 256MB the phone comes with. It would also see minor bumps in performance when it was time to swap some memory to the SD card to free up memory, or bring it back in. Windows, Linux, OSX, they all do this for you. I suspect the underlying linux OS handles this, but not quite sure if it does so or not.

Hope this wasn't too technical and helps some of you understand the killing app stuff in more detail.

this one should bump the top message, why is it that the misinformation at the top gets to stay at the top. IT ABSOLUTELY AFFECTS BATTERY LIFE. Never mind I HATE when apps that I dont want to use are running. I should determin what runs and what doesnt, and furthermore should be able to uninstall the #@$P that I dont want (ie Amazon .mp3)

 

[funken]

I'm gonna submit this to Mythbusters.

 

[LastLaugh]

Incorrect. My droid kept turning off and was extremely laggy and slow...I took it to the verizon store and they said I had to many apps running. Got an app killer and its been working perfectly ever since. Apps runnin in the background DO matter.

 

[bradpr]

awesome!

This has to be one of the biggest breakthroughs in technology! The Droid is the first computer that doesn't use power to operate.

To all of you developers on this thread who claim that a CPU doesn't use electricity (aka battery power) when executing cycles? When a program loads into memory, the bits that represent its code have to be read from long term storage into memory, and then the bits are interpreted into instructions and executed. While that program is in memory, the operating system has to manage the memory space where that program lives. Even if the program isn't doing anything, it consumes resources by simply existing in the machine's memory. I'm not a developer, but isn't it some kind of violation of physics to propose that the components in a machine can perform any of those activities without using power? All modern OS'es have the ability to dynamically manage resources and put idle applications on ice. One reason they do this is to conserve resources. But to assert that a machine can simply load processes and hold them in memory, even in an idle state, and consume zero additional power compared to what that processor would be doing if it weren't managing that process's handles, memory addresses, etc... does not make sense.

As many on this thread have pointed out, I, too have killed all processes on my droid and come back in 10 minutes to find numerous processes running that have no business running. I believe it is good housekeeping to stay aware of what programs are running on your device, question why each of those is running, and terminate the ones which shouldn't be running. You could pick up an app on the marketplace that sets up some background processing and gets stuck in a loop. Every bit of processor power an out of control app uses is power that you waste.

Its a bit like saying you'll put timers on all of your lights at home. By turning off automatically, they'll run more efficiently than they would if left on all the time, but its even more efficient to turn on the light when you need it and turn it off when you leave the room.

 

[sentient02970]

When a program loads into memory, the bits that represent its code have to be read from long term storage into memory, and then the bits are interpreted into instructions and executed. While that program is in memory, the operating system has to manage the memory space where that program lives. Even if the program isn't doing anything, it consumes resources by simply existing in the machine's memory. I'm not a developer, but isn't it some kind of violation of physics to propose that the components in a machine can perform any of those activities without using power?

Well actually, if the phone places all of that data to RAM then the memory circuits put all of those bits in a very specific mode that should simply stay there without needing power. It's when you read that bit or write a new one that's going to need current or power. Otherwise, the steady state can just sit without any power being used.

 

[bradpr]

Well actually, if the phone places all of that data to RAM then the memory circuits put all of those bits in a very specific mode that should simply stay there without needing power. It's when you read that bit or write a new one that's going to need current or power. Otherwise, the steady state can just sit without any power being used.

Interesting idea. You sound well informed. Can you point me to any Android developer's documentation that describes memory management in this OS? I'd like to better understand this technology, but I'm still skeptical that it works the way you describe.

Even if it did, power is used to read a set of instructions into memory. Then, the memory management processes have to query in-memory programs to determine their state. An idle program uses processing cycles to just sit there. You can see this on any desktop or laptop if you open 20 instances of a spreadsheet in Excel, Star Office, Open Office, or whatever you like and minimize them. You're not computing stuff, so they're idle, but memory and processor utilization are higher than they were before. If Google has perfected memory management to the point that idle programs make a NET ZERO impact to the machine, then that is revolutionary! If its true, I'll load up on GOOG stock. I just need more than a discussion forum post to believe it.

 

[RPMC]

So what we need is a means to identifiy and hold back ground services so that they don't eat up battery life when we are not near a charger. I suppose these services are started up by the OS on some schedule or other? Like checking in and downloading updates all the time, can't I freeze that till a more convenient time?

 

[sentient02970]

Actually you make a very good point. Whether you need consistent power or not depends on the TYPE of memory used. I went out and checked what the Moto Droid is using and it turns out it uses DRAM (Dynamic Random Access Memory). This type of circuit uses capacitors that hold the logic function or bit. But to hold it, it needs it's "bucket" full or empty (depending on the bit). To keep it full, a signal needs to be maintained called the "refresh" which will allow the capacitors to hold the charge despite leakage. It's a much smaller footprint of circuits than SRAM (Static Random Access Memory) which just uses logic flips as I was describing above. For a cellphone, DRAM seems a much wiser choice.

So yes, I would assume, given it's a DRAM architecture, that it needs refresh. How much, or how often depends on the size and build of the DRAM. In the case of Droid, I hope they went with a very efficient set of capacitors that don't require a lot of refresh.

 

[paranorm]

power consumption by ram

From what I understand about ram, it consumes the same amount of power to maintain it's state, no matter how much data it is storing. Writing to ram takes extra power, as does reading, but if you have 256 Mb of ram with no data being stored (all 0s), the power consumption is the same as when it is full (all 1s).

 

[dajakal]

So I haven't sifted through the 20 pages of this thread, but I thought that Android doesn't prevent a background app from doing things like hitting the network or CPU intensive tasks, both of which are the main battery killers. I mean, I can start PDAnet and go to the home screen, and it will still tether network traffic via USB. So if I say, forgot PDAnet was running, my phone could still be using a lot of battery via tethering...which is a bad example, because if it's connected to USB, it's charging. But the point is the same, right? Background services CAN be using your CPU/network/battery, and task killer apps can stop them.

 

[jimnutt]

So I haven't sifted through the 20 pages of this thread, but I thought that Android doesn't prevent a background app from doing things like hitting the network or CPU intensive tasks, both of which are the main battery killers. I mean, I can start PDAnet and go to the home screen, and it will still tether network traffic via USB. So if I say, forgot PDAnet was running, my phone could still be using a lot of battery via tethering...which is a bad example, because if it's connected to USB, it's charging. But the point is the same, right? Background services CAN be using your CPU/network/battery, and task killer apps can stop them.

That is correct. That's why it's important to know what your background apps are. However, well behaved apps shouldn't overwhelm your foreground apps or consume excessive resources beyond what's required to do their job. For example, if PDAnet is running in the background and consuming CPU while not connected to a computer, there's a problem with it. The best three tools you have are the battery status that shows what has been using your battery since you last unplugged and the "Manage applications" and "Running services" screens on the "Applications" page of settings. Those three will let you know what's consuming your resources and allow you to stop things that shouldn't be.

 

[sentient02970]

Moto Droid's memory should not be using power to retain data. It's using flash memory which is a non-volatile memory that will not wipe data when there is no power. I would expect that's the natural choice for PDAs and phones like this that depend on long battery charge life.

 

[Raeuber]

What about files and folders that are being created by apps and are not removed when the app is uninstalled? If I can find them, I will remove them manually, but what about the stuff that is not clear marked as part of that app? (i.e. not on the SDcard and labeled as such)?

This almost feels like the registry of windows, which retains stuff even after uninstall.
What a thought!!