Root task killer for 2.2

[pm1066]

K

 

[dbtklt36]

Anyone in this thread needs to understand one simple thing about the battery life. I am a commercial distributor of virtually every type of batteries there are, from cell/smart phones and laptops, to medical, to automotive or industrial. I see you coming! I love that many people are buying the crap that Google, phone manufacturers, app developers, and "service providers"(many of which are our clients) are selling in regards to Task killers/managers. As a salesman, my family is appreciative. As a consumer who actually uses my phone for business, rather than play, it sucks.

I am an expert in regards to batteries, so please understand this: ATK and other apps are effective in extending the life of your battery. Processes and applications running in the background DO affect the run-time of your device adversely. Your phone battery is designed to last roughly 2 years or a few hundred (300-400) cycles (charges) if cycled properly. The fact is, most ATK users on 2.1 were affected dramatically when the "froyo"/2.2 update took effect. Let me qualify this statement by saying those of us who use the phone for work time rather than "play-time" were more adversely affected. I, and many others, were getting 2-3 days of run-time on a single charge. Since the update, we are lucky to get 12-15 hours. That probably sounds OK to people that use their phones for gaming, etc.

Bottom Line - Processes and applications running all the time are doing so for multiple reasons. The primary reason is battery life. Roughly 71% of retail phone transactions in the U.S. can be attributed to poor battery performance, and do you think the entities I listed above don't understand this fact. Wether the consumer just says "screw it", why pay $50 for a battery when I can just "upgrade" my phone (and sign a new 2 yr $170/mo. contract) for the same cost, or the consumer is told the phone is "faulty" when it's just the battery. Who benefits from this? Not me as a consumer, Not you... (Just look at the group I listed) I pay about 1/6th of what a retail consumer would pay for an OEM Motorola battery... I may not like the fact that I'm being inconvenienced, but I can, and now do, keep a spare battery at all times.

When are you upgrading next and why?

P.S. - I use wireless daily and never vere from 3-G on the road. The same day I "upgraded" and restored, I went from 2-3 days of run-time to less than 1. All settings are the same, but even when apps are force closed, they re-start. I guess "Amazon MP3" is "needed" for tons of processes...even though I have NEVER opened it since I bought the phone w/ v2.01 and have never had a single MP3 on this phone... Force close Market and clear cache between 2-3 Mb of data in cache after about an hour in sleep...Neat trick! Hey, they are Geek Gods, who are we to question? When a device reaches cutoff voltage roughly 6 times faster, it's NOT just "opening processes and closing them as they are needed". Arizona beachfront condos for those who buy into our BS.

 

[Piiman]

no

That's better

 

[izomiac]

Sorry for the slow reply, I hope people didn't assume I couldn't back up my earlier assertions, I've just been kinda busy. For this post I'll hold back on references since that's merely a contest of Google-fu and doesn't increase the global fundus of knowledge.

(Honestly, I didn't bother looking since Android developers obviously don't care for Task Killers evidenced by their removal of that part of the API. I can understand their motivation in making software more predictable by disempowering the user, plus Verizon et. all would rather not pay for the support issues task managers cause, but I disagree with that action. Going above them would be looking at the source code, but I didn't think that'd be appropriate for this audience.)

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?

The average Android app uses 15 - 30 MB of memory. The system and services use probably half of the total (even with more RAM there's more persistently loaded bloatware). A web browser uses a lot more (Dolphin after a couple page loads is at 60 MB), and document viewers are generally written poorly enough that they load the whole document into memory (easy to check with 30 MB powerpoints). Five times sixty is three hundred, so I don't think this is really a hypothetical situation at all.

I'd say no he can't because it is inaccurate, his description of the life cycle and what gets killed when is wrong.

Ok, I suppose I need to clarify my terms. Android has invented new terminology to describe apps, even though that's just one level of abstract away from the standard Linux model. I've been using the term "Activity" to refer to an application that's actively doing something that the user (hopefully) told it to. Technically, an Activity should just be a GUI frontend to a service, but most developers don't use them this way (if they did there wouldn't be perceivable delays). So, I'm not talking about services that sit around taking up memory without doing anything (except wake up the CPU periodically, which hinders idle time and reduces battery life somewhat).

The more I read about Android Apps, the more I am reminded of BeOS replicants. Ten or fifteen years ago these were used to run one application's code in a shelf in another application. They had multiple entry points, but the main two were the initial constructor, and the constructor/destructor that took/returned a compressed BMessage that could be used to reinstantiate the application to where it was left. That way, you could drag and drop an application (e.g. I wrote a calendar for the desktop) around without losing your privates. This resemblance isn't a coincidence. Palm bought the BeOS so it certainly affected the mobile landscape. The pervasive multithreadedness is very similar to the Android Application model (BView == Activity, BHandler == Broadcast Reciever, BMessages ~= Content Provider, Servers ~= Services).

The issue with this is that reinstantiation is entirely done by the program, and it's hardly different than relaunching. Resource-wise, it's basically not different at all. In fact, you need to reopen any handles you had, so it could be even more intensive. For android, that means the auto-closing/reopening is fairly wasteful compared to manually opening and closing, since you do a lot more work. Juggling three balls is easier than juggling fifteen, with a heck of a lot less hand movement. Google made the decision to pretend that all applications run all the time from a user experience perspective, not an efficiency perspective. No clue if they're on to something, as I'm not a typical user so I find it annoying.

To prevent this from being the 20% point in this post, my remaining points will be of the bullet type.

• Tasks running in the background cannot use no resources. If they didn't, they wouldn't have an active process (or thread in another process) at all. Disregarding memory for the moment, they will still cause wakes, still have open handles, and they're another app for Android to keep track of (not free).
• The user has a pretty good idea of what needs to be run and when. I, for instance, went on a hike a couple days ago, so I used GlueTrail quite a bit that day. Today, I'm not in the woods so it's pretty safe for me to not be running GlueTrail despite opening it several times recently. Google's predictive algorithms are universally weak following a recent spike in unusual activity. Just because I Google'd something to death today doesn't mean I want it to bias my search results tomorrow.
• Unused memory is wasted memory. To make use of unused memory, Linux will use a disk cache to keep recently loaded files in memory, and reduce the cache size as memory is needed. This is below the level of Android. Using 100% of your memory for applications means that you can't take advantage of this cache, and the SD card/NAND gets used more heavily (slower and uses more power).
• Finer control over active applications means that I can keep the ones I want active at all times, so I can switch to them instantly. Without that control they'll occasionally be killed, so I have to get them back to where I had them (if they don't completely reinstantiate, which is true for most activities), and that causes a delay in my work flow. 1-2 seconds might not seem long at most times, but if you have your hand on a hot oven it can seem like an eternity (e.g. you're looking something up while your superior is staring at you).
• The number of applications in the task switcher is six. Never three, nor seven. That's why I like to run a task switcher that lists running Activities. If I'm using the application, then it is running, and if I'm not using it then I'd prefer it not to be.
• A lack of user control only works when programmers can be trusted to serve the owner well. (I say "owner", since it should be the user, but is often a corporate overlord.) Android developers, sadly, aren't uniformly skilled/motivated enough to do that. If a ten-year-old's first app behaves poorly, you may need to kill it. Froyo offers a task killer for this obvious reason. OTOH, it's not the best task manager possible, so I'd like to run a better one. (Who am I kidding with the kid remark? In modern times most commercial software developers wish to maximize profits, so they put in minimal effort (expense) into their applications.)
• It's interesting to see a report of real world effects from these theoretical concepts. Professional users seeing the greatest difference makes sense. They are generally less likely to use tools ineffectively, like killing every possible application on their phone when the screen turns off. They're also more likely to know what they don't need.

 

[marky2mark]

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.

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.

Too funny.....

I can say without question that my battery life improved noticeably by using ATK under 2.1. And nobody took my money, I was using the free version as most people do.

And of course everything you find on Google must be true right? I believe my own experience a lot more than some random info I find on Google.

In my experience battery life is noticeably worse with Froyo.

 

[rjoudrey]

Auto Task Manager works.

+1 Works great for me.

 

[rjoudrey]

Not to sound contrary but, lots of people are told that they are technically going to live but die the next day. I don't doubt that all the technical data represented here is not accurate but that not everything works as designed and user experience is everything. When I boot my phone and ATM does it's first kill about 24 apps are killed. the periodic 30 min kill generally get about 12. There fore 12 are gone for get from the get go. The only reason I use ATM is because every now and then my screens would get very laggy but now they are always nice and smooth.