Discussion in 'Android Devices' started by jacko1, Aug 23, 2010.
is there a task killer that actually works in 2.2 rooted x
you don't need a task killer
but no there are none for 2.2
fair enough thanks for answering
EStrongs Task Manger does work with 2.2. However, like he said, really no need for one.
i tried that but does not work on browser and google maps
Advanced Task Killer Froyo by Rechild
When I tap and hold on browser., select kill., it appears to...then I open my browser., and my opened pages from before are still open.
There is however a Force Stop option you may select when you push and hold on browser., and it does force stop/close the browser.
By selecting force stop when you press and hold on an app in A.T.K. Froyo,
A.T.K. Froyo shortcuts you to the application info screen.
homezcreen/menu button, settings/ Applications/ Manage Applications/ and then tapping on desired app, also takes you to Application Info screen where you can force close or kill an application.
Advanced Task Killer Froyo is currently in beta and available for free on the market.
Auto Task Manager works.
what is the problem with task killers on froyo? are people unable to install them? or is it not killing the tasks? i had ATK installed before the upgrade and it is still working for me.
the API to end applications was removed in Android 2.2
i see. i was having an issue with trying to close an app. i though it kept opening by itself. but i guess it was just not closing properly. the weird thing is that it works for certain apps like the bloatware. not sure how that works?
This is not directed at any specific person.
"Task Killers" should be renamed to cater towards battery saving apps.
Remember the facebook app update that just hammered the bejesus out of your battery? That's the only reason I ever use "task killers" to help improve battery life especially when Im not around a charger.
Im not concerned about free MB's in memory, the droid x has plenty to run everything I throw at it.
Task killers should only be used to stop apps, so that one can allow the battery to last as long as possible.
Some apps call for gps.
Others like twitter, can update every 5 minutes. (I know the interval can be changed)
I think a good solution would be for app developers to implement a real quit button or a real exit button, where once you select it, the app actually closes, or force closes. And in addition to this feature, devs code their apps not to automatically relaunch unless the user enables or checkboxes the option to do so.
Had to get that out.
I think the devs of the task killer apps are scrambling to come out with upgrades or froyo versions of "task killers" to help save our battery life.
I think we will see a new era of task killing and managing apps hit the market because of froyo.
Personally, I'm the type of person to put stuff away when I'm done with it. That carries over to Android, and it bugs me when stuff is running unnecessarily (I know it's unnecessary since I can predict my behavior better than Android). Similarly, I like to start certain applications with a clean slate, like Browser or Epocrates.
What I did was add a shortcut to the "Manage Applications" activity in "Settings" on my homescreeen using Launcher Pro. It's not the best taskmanager, but at least it works in Froyo. I also reboot daily now.
That's because Google removed the API to kill task! The guy that wrote Advanced Task Killer was talking about how much money he made and mentions.
1. Killing task isn't needed in the newer versions of the OS
2. Google removed the API to kill task in 2.2
So not only did Google remove the ability but the creator of the most popular task killer admits it's not needed.
I believe the story is on Android central. He is talking about how the app store is a good source of income. He made a few $$ with it and list it all in the story.
Makes me want to get my "Pet my Kitty" app up ASAP if I could get the f'ing App inventor to work right with 2.2 drivers
Its obvious you don't know how the system works. And yeah they're probaly working hard to take your money for making you feel good because that's all these apps do. They remind me of the memory defraggers that were all the rage 10 years ago.
What app are you killing to save your battery?
Unless its a service and if it isn't in the front it is suspended, if you used the home key to switch from a running app then yes that app is running if it is finishing a task and then it is suspended. If they are suspended it isn't doing anything and thus not using your battery. If you don't want your apps updating set it to not update so often. You killing it does nothing it just reloads behind your back (usually with in minutes)
If you use the back button until you are out the app is suspended (that is your shut down/exit.) It is using nothing but memory and used memory doesn't take any more juice than unused memory.
Just Google why Task managers are bad and you will find tons of info on how the system works and why task killer are bad.
Just had to get that out.
One more time THEY ARE NOT RUNNING!! and you do know that most just come back with in a few minutes (if that long)
If you want to start with a clean slate then exit the browser the correct way. Don't use the Home key.
I find that people that insist on using these things even when they know they do nothing and are bad are one of these...
1. People that don't know how the system works
2. People that think the system should work like Windows
3. Control freaks.
I think Google should also remove the API that lets you see preloaded apps. Or maybe they should give people the option to have their phones run slower buy never keeping anything in memory.
I'm off to bed flame away
Just use autostarts to stop apps from loading. It's a much better solution.
Ok, I just opened Browser and Epocrates. On Browser I tried both using back as many times as necessary to get out (which can be >20, but eventually it goes to the homepage, loads it, then hides), and closing the window (ditto about the homepage). Given that I can later quickly reopen my dynamic iGoogle page and see outdated infromation I'm fairly sure it's still running. Epocrates stays on whatever you left it on and won't stop running even from back on the first screen. But, don't take my word that they're still running, take a look:
USER PID PPID VSIZE RSS WCHAN PC NAME
root 1 0 292 272 ffffffff 00000000 S /init
root 2 0 0 0 ffffffff 00000000 S kthreadd
root 3 2 0 0 ffffffff 00000000 S ksoftirqd/0
root 4 2 0 0 ffffffff 00000000 S watchdog/0
root 5 2 0 0 ffffffff 00000000 S events/0
root 6 2 0 0 ffffffff 00000000 S khelper
root 9 2 0 0 ffffffff 00000000 S async/mgr
root 12 2 0 0 ffffffff 00000000 S suspend
root 194 2 0 0 ffffffff 00000000 S sync_supers
root 196 2 0 0 ffffffff 00000000 S bdi-default
root 198 2 0 0 ffffffff 00000000 S kblockd/0
root 202 2 0 0 ffffffff 00000000 S omap_serial
root 210 2 0 0 ffffffff 00000000 S omap2_mcspi
root 213 2 0 0 ffffffff 00000000 S cpcap_irq/0
root 275 2 0 0 ffffffff 00000000 S ksuspend_usbd
root 280 2 0 0 ffffffff 00000000 S khubd
root 305 2 0 0 ffffffff 00000000 S kmmcd
root 312 2 0 0 ffffffff 00000000 S bluetooth
root 345 2 0 0 ffffffff 00000000 S khungtaskd
root 346 2 0 0 ffffffff 00000000 S kswapd0
root 348 2 0 0 ffffffff 00000000 S aio/0
root 349 2 0 0 ffffffff 00000000 S crypto/0
root 442 2 0 0 ffffffff 00000000 S kxtf9_wq
root 446 2 0 0 ffffffff 00000000 S omap_mdm_ctrl_w
root 481 2 0 0 ffffffff 00000000 S mtdblockd
root 509 2 0 0 ffffffff 00000000 S klink_driver_wq
root 524 2 0 0 ffffffff 00000000 S usb_mass_storag
root 532 2 0 0 ffffffff 00000000 S qtouch_obp_ts_w
root 541 2 0 0 ffffffff 00000000 S bu52014hfv_wq
root 544 2 0 0 ffffffff 00000000 S sfh7743_wq
root 574 2 0 0 ffffffff 00000000 S bridge_work-que
root 575 2 0 0 ffffffff 00000000 S bridge_recovery
root 581 2 0 0 ffffffff 00000000 S w1_bus_master1
root 590 2 0 0 ffffffff 00000000 S kstriped
root 592 2 0 0 ffffffff 00000000 S kondemand/0
root 611 2 0 0 ffffffff 00000000 S als_wq
root 625 2 0 0 ffffffff 00000000 S usbhid_resumer
root 628 2 0 0 ffffffff 00000000 S binder
root 643 2 0 0 ffffffff 00000000 S krfcommd
root 645 2 0 0 ffffffff 00000000 S dsi
root 682 2 0 0 ffffffff 00000000 S pvrflip/0
root 687 2 0 0 ffffffff 00000000 S mmcqd
root 1029 2 0 0 ffffffff 00000000 S mmcqd
root 1059 2 0 0 ffffffff 00000000 S kjournald
root 1067 2 0 0 ffffffff 00000000 S flush-179:32
root 1070 2 0 0 ffffffff 00000000 S kjournald
root 1080 2 0 0 ffffffff 00000000 S kjournald
root 1092 2 0 0 ffffffff 00000000 S kjournald
root 1102 2 0 0 ffffffff 00000000 S kjournald
shell 1116 1 3308 184 ffffffff 00000000 S /sbin/adbd
root 1118 1 1032 276 ffffffff 00000000 S /system/bin/ecckeyd
system 1119 1 712 288 ffffffff 00000000 S /system/bin/servicemanager
root 1120 1 3644 540 ffffffff 00000000 S /system/bin/vold
root 1121 1 3636 512 ffffffff 00000000 S /system/bin/netd
root 1122 1 572 252 ffffffff 00000000 S /system/bin/debuggerd
radio 1123 1 10752 716 ffffffff 00000000 S /system/bin/rild
root 1125 1 784 352 ffffffff 00000000 S /system/bin/usbd
mot_accy 1126 1 1256 496 ffffffff 00000000 S /system/bin/battd
root 1128 1 113076 19652 ffffffff 00000000 S zygote
media 1129 1 36000 2164 ffffffff 00000000 S /system/bin/mediaserver
bluetooth 1130 1 1172 364 ffffffff 00000000 S /system/bin/dbus-daemon
root 1131 1 724 344 ffffffff 00000000 S /system/bin/installd
keystore 1133 1 1524 384 ffffffff 00000000 S /system/bin/keystore
mot_tcmd 1134 1 14472 952 ffffffff 00000000 S /system/bin/tcmd
compass 1136 1 180 40 ffffffff 00000000 S /system/bin/akmd2
radio 1142 1 936 356 ffffffff 00000000 S /system/bin/ftmipcd
root 1143 1 1732 316 ffffffff 00000000 S /system/bin/mdm_panicd
mot_tpapi 1145 1 1084 348 ffffffff 00000000 S /system/bin/secclkd
root 1154 2 0 0 ffffffff 00000000 S smodule
root 1179 1 832 272 ffffffff 00000000 S /system/bin/smoduled
system 1232 1128 295872 65164 ffffffff 00000000 S system_server
app_17 1300 1128 162236 22212 ffffffff 00000000 S com.motorola.blur.providers.contacts
app_85 1349 1128 164964 25148 ffffffff 00000000 S com.swype.android.inputmethod
radio 1356 1128 172804 21108 ffffffff 00000000 S com.android.phone
app_17 1357 1128 216324 25392 ffffffff 00000000 S com.motorola.blur.service.main
app_43 1361 1128 169716 26076 ffffffff 00000000 S com.motorola.blur.service.blur
app_2 1362 1128 167356 17308 ffffffff 00000000 S com.motorola.blur.home
app_42 1369 1128 150064 18940 ffffffff 00000000 S com.motorola.batterymanager
app_27 1377 1128 152048 15656 ffffffff 00000000 S com.nuance.android.vsuite.vsuiteapp
app_106 1397 1128 174660 32784 ffffffff 00000000 S android.process.acore
app_7 1416 1128 183004 23524 ffffffff 00000000 S com.google.process.gapps
app_28 1434 1128 155048 16816 ffffffff 00000000 S com.android.music
app_16 1447 1128 159908 20740 ffffffff 00000000 S android.process.media
app_20 1468 1128 152024 16728 ffffffff 00000000 S com.google.android.apps.uploader
app_18 1480 1128 180752 29348 ffffffff 00000000 S com.google.android.gm
app_93 1490 1128 150264 16728 ffffffff 00000000 S org.hermit.dazzle
app_47 1503 1128 153416 16008 ffffffff 00000000 S com.motorola.homesync
app_68 1511 1128 153696 17252 ffffffff 00000000 S android.tts
app_21 1517 1128 149940 15744 ffffffff 00000000 S com.svox.pico
app_52 1524 1128 149056 15616 ffffffff 00000000 S com.motorola.vclipboard
app_2 1547 1128 158984 17288 ffffffff 00000000 S com.motorola.blur.contacts
root 1555 2 0 0 ffffffff 00000000 S flush-179:0
app_84 1556 1128 149960 15656 ffffffff 00000000 S com.motorola.globalunplug
app_79 1563 1128 155268 17240 ffffffff 00000000 S com.motorola.blur.alarmclock
app_76 1576 1128 154788 18416 ffffffff 00000000 S com.motorola.blur.conversations
app_34 1585 1128 162436 19472 ffffffff 00000000 S com.android.calendar
app_65 1596 1128 149024 15660 ffffffff 00000000 S com.motorola.android.AudioEffectSettings
app_62 1611 1128 150524 16160 ffffffff 00000000 S com.motorola.android.provisioning
system 1621 1128 152788 17300 ffffffff 00000000 S com.motorola.process.system
system 1627 1128 152688 15616 ffffffff 00000000 S com.motorola.blur.datamanager.app
app_56 1640 1128 171456 15708 ffffffff 00000000 S com.google.android.partnersetup
app_45 1646 1128 149364 15592 ffffffff 00000000 S com.motorola.android.dm.service
app_44 1652 1128 150764 17152 ffffffff 00000000 S com.fusionone.android.sync.service
app_42 1667 1128 149312 16096 ffffffff 00000000 S com.motorola.batterymanager:deviceStats
app_39 1673 1128 163376 18136 ffffffff 00000000 S com.google.android.apps.maps:FriendService
app_37 1680 1128 151068 16256 ffffffff 00000000 S com.motorola.usb
app_36 1686 1128 150512 16680 ffffffff 00000000 S com.motorola.vvm
app_29 1699 1128 149520 16616 ffffffff 00000000 S com.android.bluetooth
app_25 1710 1128 151024 16948 ffffffff 00000000 S com.motorola.android.syncml.service
app_2 1721 1128 148920 16080 ffffffff 00000000 S com.motorola.android.buacontactadapter
app_17 1728 1128 154604 17192 ffffffff 00000000 S com.motorola.blur.contacts.data
app_15 1730 1128 149480 16068 ffffffff 00000000 S com.motorola.videoplayer
app_5 1748 1128 149688 16024 ffffffff 00000000 S com.motorola.cmas
app_3 1756 1128 149388 17432 ffffffff 00000000 S com.motorola.android.datamanager
app_152 1762 1128 150656 16768 ffffffff 00000000 S de.anno.android.missedCall
app_98 1768 1128 150960 18848 ffffffff 00000000 S com.drclabs.android.wootchecker:woot_remote
app_105 1780 1128 169000 22808 ffffffff 00000000 S com.google.android.apps.googlevoice
app_153 1797 1128 149408 17524 ffffffff 00000000 S kenyu73.realsignal
app_137 1808 1128 159712 21372 ffffffff 00000000 S com.kugoweb.launcher.donut
app_175 1820 1128 164912 27720 ffffffff 00000000 S com.google.android.apps.genie.geniewidget
app_16 1831 1128 155896 17312 ffffffff 00000000 S com.motorola.photowidget
app_139 1838 1128 156228 18680 ffffffff 00000000 S com.roflharrison.agenda
app_154 1845 1128 157416 24536 ffffffff 00000000 S com.google.code.appsorganizer
app_4 1861 1128 167384 31076 ffffffff 00000000 S com.android.vending
app_99 1881 1128 155956 18036 ffffffff 00000000 S fm.last.android
app_99 1891 1128 152760 18176 ffffffff 00000000 S fm.last.android:player
app_99 1898 1128 151804 17756 ffffffff 00000000 S fm.last.android:scrobbler
app_2 1922 1128 176544 20860 ffffffff 00000000 S com.motorola.blur.friendfeed
app_2 2016 1128 152188 16004 ffffffff 00000000 S com.motorola.togglewidgets
app_172 2092 1128 213284 17492 ffffffff 00000000 S com.qo.android.moto
app_12 2127 1128 166716 20780 ffffffff 00000000 S android.process.acore
root 2146 2 0 0 ffffffff 00000000 S sdio_wq
root 2148 2 0 0 ffffffff 00000000 S tiwlan_wq
wifi 2156 1 1984 964 ffffffff 00000000 S /system/bin/wpa_supplicant
dhcp 2161 1 756 344 ffffffff 00000000 S /system/bin/dhcpcd
app_67 2320 1128 156376 16336 ffffffff 00000000 S com.motorola.blur.socialmessaging
app_2 2329 1128 152840 16168 ffffffff 00000000 S com.motorola.blur.home.newsstatus
app_171 2489 1128 148944 15996 ffffffff 00000000 S com.android.defcontainer
app_88 2500 1128 151520 16704 ffffffff 00000000 S com.motorola.cardock
app_147 2507 1128 151340 16944 ffffffff 00000000 S de.softxperience.android.noteeverything
app_100 2519 1128 156056 17796 ffffffff 00000000 S com.layar
app_155 2528 1128 152800 17036 ffffffff 00000000 S com.google.android.googlequicksearchbox
app_156 2578 1128 181360 33012 ffffffff 00000000 S pepid.android
app_54 2600 1128 149880 18352 ffffffff 00000000 S com.android.packageinstaller
app_127 2618 1128 148996 15908 ffffffff 00000000 S com.socialnmobile.buttonshortcuts
app_103 2629 1128 201556 37024 ffffffff 00000000 S com.epocrates
app_58 2658 1128 189308 35744 ffffffff 00000000 S com.android.browser
app_102 2795 1128 163960 26248 ffffffff 00000000 S org.connectbot
app_102 2810 2795 644 324 c006a098 afd0e86c S /system/bin/sh
app_102 2813 2810 856 432 c01b8cb4 afd0d97c S top
app_102 2818 2795 644 328 c006a098 afd0e86c S /system/bin/sh
app_102 2825 2818 828 352 00000000 afd0d95c R ps
So... yes... they're absolutely running. In fact, so is top from a prior shell session. Kill sig 9 to the PID does seem to work from su, but Android doesn't recognize the termination (keeps it listed as "Running" but switching to it is slow, indicating that it has to be relaunched).
So, assume the process isn't waking the CPU up and bringing it out of idle (an unlikely assumption, but I'll give it to you*). What must Android do when an application asks for more memory? Well, your disk cache is the first thing to go. What's a disk cache? It keeps files that you've recently accessed around in memory so if you access them again it'll be much faster and you can avoid using the SD card or NAND (Net result: faster and less battery consumption).
Once that's gone what's next? Well, your longest neglected activity that's currently running is next. So Android executes finish() on the activity, then it terminates. For a large application this could take a second or so. Killing an app when you have a moment ensures you don't need to do this when another application is doing something time sensitive. What do you think happens when a program asks malloc for 1 KB of memory for a quick array, but it takes 1000 ms rather than 1 ms? Your guess is as good as mine. Programmers shouldn't make assumptions that aren't always true, but few programmers have that level of attention to detail, especially in a high level language like Java... This is confounded since Java code isn't run on the bare metal, so you have little idea of when the VM is going to allocate memory.
So, what if you need ever more memory? Well, the next to go might be an application you're actively using. For simplicity's sake, say you have three applications: A, B, & C. A & B use 40% of the available memory, while C uses 25%. Say your usage pattern is A, B, C, A, B. Your used memory after A & B is 80%, so A gets killed to make room for C. After opening C you are at 65%, so B is killed to open A, and, lastly, C is killed to open B. This is an example of where Android's predicting scheme doesn't work well at all, and being able to manually kill C keeps you from unnecessary opening and closing in the background. BTW, just picture how this works if C is Gmail and A & B are programs you're reading information from to type an e-mail (hint: scrolling position is usually lost, documents are rarely reopened, and sometimes unsaved documents are lost).
* Linux power management is a fun topic, but off topic for now. I'm referring to race to idle in conjunction with tickless idle. Intel has a site that introduces the topic better than I can. Here is a presentation on what Android inherits from Linux regarding power management, and how OMAP SOCs differ from Intel CPUs. If you want it from the horse's mouth, though, the Android Developer's Guide touches upon why it's bad to load, kill, load, kill stuff. Honestly, though, it's a programming reference and not a description of how Android's memory management works behind the scenes, and rather basic overall (excellent for its purpose, which is to remind experienced programmers and educate new ones).
So, which am I? 1) is true, I'm still an incomplete noob when it comes to Android, Linux, Kernels, Memory Management, C++, Java, Embedded Systems, and most everything else I touched upon; inaccuracies are doubtlessly afoot (I learn through being told specifically how I'm being idiotic, so I'll be glad if someone points them out). 2) is false, I think it should run more like Linux, but I don't think Linux's memory management or other components are particularly good, just the best whole package that's readily available. 3) Guilty as charged. Isn't that the premise of being a tweaker? Small performance gains through knowledge and effort by switching from a generic automated method to a more tailored or manually controlled approach...
I hope I didn't disappoint!
you gotta post more
I am really struggling with how this is more than a hypothetical. What three (or 5 or 7) applications could be run simultaneously that would use that much memory?
Can you provide a practical example where something like this occurs on even first gen android phones, let alone the HW packages we are seeing now?
I'm gonna pull a ofthedamned and tell ya that you don't need task killers.
If you don't know who that is go check out the eris forums.
Swype is so much fun
Damn my eyes are burning and my brain hurts.
But I still think your a little confused.. But to clarify my point yes some things are running of course, its an OS and some stuff needs to run. People kill this stuff all the time with Task killers and that causes problems and most people only see the task from at task manager and think its all running when in fact most of it isn't.
I hate typing so here's some reading for you and anyone that cares.
Why you don’t need a task killer app with Android. AndroidSPIN | Your No.1 source for Everything Android.
Application Fundamentals | Android Developers
I was going to post more links but I want my post to be BIGGER than yours
Android is hard coded to automatically kill a task when more memory is needed.
Android is hard coded to automatically kill a task when it’s done doing what it needs to do.
Android is hard coded to automatically kill a task when you haven’t returned to it in a long time.
Most services (while possibly running in the background) use very little memory when not actively doing something.
A content provider is only doing something when there is a notification for it to give. Otherwise it uses very little memory.
Killing a process when it isn’t ready only causes it to have to reload itself and start from scratch when it’s needed again.
Because a task is likely running in the background for a reason, killing it will only cause it to re-spawn as soon as the activity that was using it looks for it again. And it will just have to start over again.
Killing certain processes can have undesirable side effects. Not receiving text messages, alarms not going off, and force closes just to name a few.
The only true way to prevent something from running at all on your phone would be to uninstall the .apk.
Most applications will exit themselves if you get out of it by hitting “back” until it closes rather than hitting the “home” button. But even with hitting home, Android will eventually kill it once it’s been in the background for a while.
Questions? Concerns? Feel that I’m wrong? Comment below and let’s discuss!
One thing that I forgot to even address here is that memory works a bit differently in linux than it does in Windows. In general the way memory works is you really only need as much as you plan on using. So if your combined running programs use 100mb of memory, 150mb is more than enough. There is no need to clear what’s running in memory before you hit that 150mb cap. Now in Windows it seems that the system performs a bit better when you have less stuff in memory, even if it’s not full. No doubt those who have been on [COLOR=#0000FF ! important][FONT="][COLOR=#0000FF ! important][FONT="]computers[/FONT][/FONT][/COLOR][/COLOR] for a while will remember there used to be programs that could clear your memory in Windows also.
Linux however isn’t generally affected by this. While I admit that I don’t know the architecture and reason for this… linux will run the same regardless of if you have 20mb free memory or 200mb. And as I outlined above, Android will automatically start to kill applications if you do get low on memory! Stealing a quote from Chris Johnston, “Buffers and cache in RAM being cleared is silly. Imagine a professor, who rather than writing all the way across the chalkboard, finishes a sentence and immediately erases and starts writing in the upper left corner AGAIN and AGAIN and AGAIN OR imagine you like a song. You record it to the beginning of a cassette tape. When you want a new song, do you re-record over the first song or record after it?”
I have also seen people incorrectly assume that the more memory in use, the faster their battery will die. This would actually be more attributed to the amount of processor cycles (CPU %) going on and not the amount of memory being taken up by a certain program. However, that does lead to a good point! When can a task manager be a good thing?? To help you determine what IS slowing down your phone; what may actually be draining your battery faster. That is actually what helped us discover that there appears to be a bug still left over from 1.5 that is causing slow downs on our CDMA Hero’s even today. While an item using up memory isn’t going to hurt things, an item chewing through your CPU absolutely will. Now I still don’t suggest using a task killer to kill a program that is using up your processor (unless of course it is a zombie process that is going crazy, but you should probably just reboot in that case). But it can help you see what’s going on with your phone.
I hope this has helped someone. With all of that said… I always encourage experimenting. It is your phone, and you can do with it what you please. If you swear that a task killer makes your phone amazing, then by all means use it! Thanks for reading.
FAQ: Why You Shouldn’t Be Using a Task Killer with Android
I see this come up over and over again. People saying that a task is running in the background and they think it is killing their battery or hogging all of their memory. So their natural reaction is to download a program made to kill tasks. Here’s the thing… you are likely doing more harm than good by killing tasks that aren’t ready to end. I was the same way when I first got my CDMA Hero. There were tons of things running that I didn’t want so I just kept killing them. After a few weeks I realized that if I stopped using a task killer (and totally uninstalled it in fact) my phone actually began to run better! The applications would close themselves and things just seemed to be running better. I get that there may be short term benefits from clearing a task, but you should still take the time to read through this.
Here is some information directly from Android’s developer page. I have put the important parts in bold. This is quite a lengthy read but honestly I think it’s important. If you want the full read then you can check out the dev page here. If you just want the quick TL;DNR version then scroll to the bottom.By default, every application runs in its own Linux process. Android starts the process when any of the application’s code needs to be executed, and shuts down the process when it’s no longer needed and system resources are required by other applications.
A content provider is active only while it’s responding to a request from a ContentResolver. And a broadcast receiver is active only while it’s responding to a broadcast message. So there’s no need to explicitly shut down these components.
Activities, on the other hand, provide the user interface. They’re in a long-running conversation with the user and may remain active, even when idle, as long as the conversation continues. Similarly, services may also remain running for a long time. So Android has methods to shut down activities and services in an orderly way:
An activity can be shut down by calling its finish() method. One activity can shut down another activity (one it started with startActivityForResult()) by calling finishActivity().
A service can be stopped by calling its stopSelf() method, or by calling Context.stopService().
Components might also be shut down by the system when they are no longer being used or when Android must reclaim memory for more active components.
If the user leaves a task for a long time, the system clears the task of all activities except the root activity. When the user returns to the task again, it’s as the user left it, except that only the initial activity is present. The idea is that, after a time, users will likely have abandoned what they were doing before and are returning to the task to begin something new.
An activity has essentially three states:
It is active or running when it is in the foreground of the screen (at the top of the activity stack for the current task). This is the activity that is the focus for the user’s actions.
It is paused if it has lost focus but is still visible to the user. That is, another activity lies on top of it and that activity either is transparent or doesn’t cover the full screen, so some of the paused activity can show through. A paused activity is completely alive (it maintains all state and member information and remains attached to the window manager), but can be killed by the system in extreme low memory situations.
It is stopped if it is completely obscured by another activity. It still retains all state and member information. However, it is no longer visible to the user so its window is hidden and it will often be killed by the system when memory is needed elsewhere.
If an activity is paused or stopped, the system can drop it from memory either by asking it to finish (calling its finish() method), or simply killing its process. When it is displayed again to the user, it must be completely restarted and restored to its previous state.
The foreground lifetime of an activity happens between a call to onResume() until a corresponding call to onPause(). During this time, the activity is in front of all other activities on screen and is interacting with the user. An activity can frequently transition between the resumed and paused states — for example, onPause() is called when the device goes to sleep or when a new activity is started, onResume() is called when an activity result or a new intent is delivered. Therefore, the code in these two methods should be fairly lightweight.
The following diagram illustrates these loops and the paths an activity may take between states. The colored ovals are major states the activity can be in. The square rectangles represent the callback methods you can implement to perform operations when the activity transitions between states.
This is only a fraction of articles that tell you they are bad, see how many you find that say they are good.
and No I didn't write this , obviously (I wish I could write that well) but I think its bigger than yours
And yes I agree you're a 3
I'd say no he can't because it is inaccurate, his description of the life cycle and what gets killed when is wrong.
could you keep your post a little shorter please.