JoeProcopio
Android Enthusiast
automatic task killer, advanced task killer, or something else?
-
After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.
what's the best app killer?
- Thread starter JoeProcopio
- Start date
JoeProcopio
Android Enthusiast
i have read through the truth post and have uninstalled all of my killers...we'll see how things go. I have found, as many others have, that turning off my gps bluetooth and wifi when not using helped tremendously. I have gotten a day on a full charge...my day consists of 2 x 2 hour commutes, with streaming, browsing, and other tasks while i sit on the train to work. wonder how the weekend will be since I won't use the phone nearly as much.
shrink57
Android Expert
I did the same earlier today. Now I am actually getting all my email notifications (before it was hit or miss) and despite giving all my apps a good workout no slowdowns so far. I am keeping my fingers crossed...
skwerm
Well-Known Member
nice, this gives me hope. i'll play around with my apps and see if i notice a difference
holly needs help please
Lurker
Sorry for the double post
holly needs help please
Lurker
Question about automatic task killer:
I have the droid eris and I'm really hoping to get some answers here because Verizon tech support has been useless. I feel that I need a killer because without it my battery life is just god awful. However, with auto killer half the time when screen goes to sleep the whole screen will turn off and have to re load. Which is such a hassle. Then I switched to advanced task killer and it seems I have intense key board lag. Is there a way to change options on auto so this won't happen or is my phone just glitching.
I'm uninstalling it to see if this is the source of my glitch. Because I also don't receive emails which I've read may be from task killer. But then the problem of battery life comes up again. And before you ask, yes WiFi is off etc.
Any help is greatly appreciated.
I have the droid eris and I'm really hoping to get some answers here because Verizon tech support has been useless. I feel that I need a killer because without it my battery life is just god awful. However, with auto killer half the time when screen goes to sleep the whole screen will turn off and have to re load. Which is such a hassle. Then I switched to advanced task killer and it seems I have intense key board lag. Is there a way to change options on auto so this won't happen or is my phone just glitching.
I'm uninstalling it to see if this is the source of my glitch. Because I also don't receive emails which I've read may be from task killer. But then the problem of battery life comes up again. And before you ask, yes WiFi is off etc.
Any help is greatly appreciated.
holly needs help please
Lurker
And task MANAGER is better than killer? Because killer blocks my emails where it doesn't refresh unless I do it manually, though settings say otherwise.
Also as of now i have no task apps. But I am still observing intense keyboard lag. Any ideas?
Also as of now i have no task apps. But I am still observing intense keyboard lag. Any ideas?
JoeProcopio
Android Enthusiast
well, without app killer, unplugged since 7:30am, regular usage...phone is still at 60%...a few calls, a bunch of texts, browsing, wifi connected, GPS turned on for about 30 minutes...but NO STREAMING AUDIO...when I commute to work, I stream Howard Stern using Cherry rPlayer, and that uses 40% of my battery by the time I get to work...I leave the house @ 6am, get to work around 10 to 8...so almost 2 hours...and streaming the whole time...
i have found that just turning off gps, wifi, bluetooth, and keeping the brightness down all the way on the display have helped tremendously....load up the power widget and put it on one of the outer home screens, and keep managing it...your battery will love it.
I still plan on getting a backup battery and a charger from Verizon but just managing the power better and charging the phone every chance you get seems to be working fine.
i have found that just turning off gps, wifi, bluetooth, and keeping the brightness down all the way on the display have helped tremendously....load up the power widget and put it on one of the outer home screens, and keep managing it...your battery will love it.
I still plan on getting a backup battery and a charger from Verizon but just managing the power better and charging the phone every chance you get seems to be working fine.
willemferguson
Lurker
The situation is not as simple as the above arguments may lead someone to believe.
As far as CPU power consumption is concerned, keep in mind the CPU is always running, even if idle. In an idle state it just executes a loop, waiting for the next event to happen. The power to the CPU is not turned off unless the machine is in a SLEEP mode. The ideal system is a CPU that is entirely interrupt driven, switching completely off when not in need, but I do not know of such a CPU. It needs to be clocked and driven with power in order to monitor interrupts coming from the keyboard, screen, network interface, timers, software etc. An application that does not require CPU attention does therefore NOT necessarily consume extra power. The first misconception therefore is that more software in memory uses more CPU power.
One needs to distinguish between memory space usage and memory access. In an oversimplified way one may say that the former does not require additional battery power, while the latter does. Memory space usage cannot affect power consumption since whatever the information written into memory does not mean the machine is actually accessing that information. If a task is inactive (maybe because the front end of a Notepad application has been minimised or closed down) there may be a significant amount of code and data stored in memory, but if the NotePad does not actively access that information, then it lies essentially dormant. Therefore the number of apps in memory CANNOT affect battery power by itself, since the information in memory does not use battery power by itself. Memory chips require a fixed amount of electricity to hold information, even if the information is junk. The amount of electricity needed scales directly with the total amount of memory in the system. If your Android system has 8 Gbytes of RAM, then the memory uses the same amount of electricity, whether the 8Gb is full of junk or filled with software. This is especially true for dynamic memory which is the typical fast-access memory used in computers and hand-held devices. The second misconception therefore is that more software in memory uses more electricity.
Having said that, there are three exceptions to these two basic statements:
1) When memory is being accessed. Reading information from memory requires additional electricity because of the additional circuitry that needs to be activated to do this. If a background application accesses memory all the time, then it actually consumes electricity, even though it is running in the backgound. However, an app should NOT access memory if it has been relegated to the background because it is not required any more. Memory chips heat because of CPU accesses to that RAM, not because the RAM stores information.
2) Background processes can monitor external devices such as the Internet link. For instance, if GMail is constantly checking for incoming email, then it accesses the Internet hardware, writes some of the results to memory, and continues to perform duties even while GMail is only running in the background. This uses up electricity.
3) Some software, e.g. a Bluetooth interface, uses physical hardware that is "normally" not switched on. The user needs to switch it on or off, therefore the onscreen tools provided by Android to do exactly that. Software in the background that used WiFi, Bluetooth, GPS (e.g. geotagging of photographs) therefore can use a considerable amount of electricity if this ancillary hardware is used and the results written to memory. Background apps that use these hardware therefore use electricity.
The above I hope shows that background tasks can (and do) often use additional electricity, even if they are only running in the background, supposedly in an "inactive" state. In order to conserve battery power, kill all software that makes use of the LAN/Internet interface, the GPS facility and any hardware that is not needed at a particular moment. Software that writes to memory (or to disk) on a regular basis should also be killed if their services are not required.
Given the superlative design behind the Unix/Linux OS in terms of efficient multitasking and the handling of of background processes, we might expect that the management of power may be close to optimised. However, if one runs a geotagging process as part of a camera that is running in the background, then we cannot blame the OS for consuming more battery power because of GPS accesses. The user did not kill the camera software and the OS thinks the user still needs the geotagging facilities.
To sum up, it is good to know which applications use battery power. Android provides excellent monitoring facilities to see which apps are the culprits. I would use software such as ATK to see that these pieces of software are killed when not required, afterwards killing ATK itself as well. I hope this offers some extra perspectives and a compromise position between the above two extreme positions.
As far as CPU power consumption is concerned, keep in mind the CPU is always running, even if idle. In an idle state it just executes a loop, waiting for the next event to happen. The power to the CPU is not turned off unless the machine is in a SLEEP mode. The ideal system is a CPU that is entirely interrupt driven, switching completely off when not in need, but I do not know of such a CPU. It needs to be clocked and driven with power in order to monitor interrupts coming from the keyboard, screen, network interface, timers, software etc. An application that does not require CPU attention does therefore NOT necessarily consume extra power. The first misconception therefore is that more software in memory uses more CPU power.
One needs to distinguish between memory space usage and memory access. In an oversimplified way one may say that the former does not require additional battery power, while the latter does. Memory space usage cannot affect power consumption since whatever the information written into memory does not mean the machine is actually accessing that information. If a task is inactive (maybe because the front end of a Notepad application has been minimised or closed down) there may be a significant amount of code and data stored in memory, but if the NotePad does not actively access that information, then it lies essentially dormant. Therefore the number of apps in memory CANNOT affect battery power by itself, since the information in memory does not use battery power by itself. Memory chips require a fixed amount of electricity to hold information, even if the information is junk. The amount of electricity needed scales directly with the total amount of memory in the system. If your Android system has 8 Gbytes of RAM, then the memory uses the same amount of electricity, whether the 8Gb is full of junk or filled with software. This is especially true for dynamic memory which is the typical fast-access memory used in computers and hand-held devices. The second misconception therefore is that more software in memory uses more electricity.
Having said that, there are three exceptions to these two basic statements:
1) When memory is being accessed. Reading information from memory requires additional electricity because of the additional circuitry that needs to be activated to do this. If a background application accesses memory all the time, then it actually consumes electricity, even though it is running in the backgound. However, an app should NOT access memory if it has been relegated to the background because it is not required any more. Memory chips heat because of CPU accesses to that RAM, not because the RAM stores information.
2) Background processes can monitor external devices such as the Internet link. For instance, if GMail is constantly checking for incoming email, then it accesses the Internet hardware, writes some of the results to memory, and continues to perform duties even while GMail is only running in the background. This uses up electricity.
3) Some software, e.g. a Bluetooth interface, uses physical hardware that is "normally" not switched on. The user needs to switch it on or off, therefore the onscreen tools provided by Android to do exactly that. Software in the background that used WiFi, Bluetooth, GPS (e.g. geotagging of photographs) therefore can use a considerable amount of electricity if this ancillary hardware is used and the results written to memory. Background apps that use these hardware therefore use electricity.
The above I hope shows that background tasks can (and do) often use additional electricity, even if they are only running in the background, supposedly in an "inactive" state. In order to conserve battery power, kill all software that makes use of the LAN/Internet interface, the GPS facility and any hardware that is not needed at a particular moment. Software that writes to memory (or to disk) on a regular basis should also be killed if their services are not required.
Given the superlative design behind the Unix/Linux OS in terms of efficient multitasking and the handling of of background processes, we might expect that the management of power may be close to optimised. However, if one runs a geotagging process as part of a camera that is running in the background, then we cannot blame the OS for consuming more battery power because of GPS accesses. The user did not kill the camera software and the OS thinks the user still needs the geotagging facilities.
To sum up, it is good to know which applications use battery power. Android provides excellent monitoring facilities to see which apps are the culprits. I would use software such as ATK to see that these pieces of software are killed when not required, afterwards killing ATK itself as well. I hope this offers some extra perspectives and a compromise position between the above two extreme positions.