You do!!! Its not a graphical program, but it is available anyways. >From the TERMINAL, run the program "top". If you install busybox, you get a much better version of "top". This does NOT require root, however, to KILL a program (using the "kill" or "killall" commands), you DO need root.
If you install terminal on a device withOUT root, you WILL have write access to /data/data/com.android.term/, so you can install your busybox executable there. On Mar 26, 1:37 pm, Paper Coder <[email protected]> wrote: > Agreed! It would be nice to see something like Task Manager, where a user > could see which currently running apps/services are sucking up CPU time, and > also track it's CPU use over a period of time. And it would also be nice to > see a way to KILL the process that's sucking up the juice without having to > restart the phone or open up a bunch of smaller apps to force it out of the > queue. > > That would rock. > > As it is now, it's often a lengthy trial and error process to figure out > which app is slowing everything down. > > On Fri, Mar 27, 2009 at 12:33 AM, ShrinkRay <[email protected]> wrote: > > > Hey don't knock java... if background processes weren't allowed, then > > this wouldn't be an issue. > > > But that's one of the good things about Android isn't it... LOL. > > > Even a proper desktop or laptop computer struggles when a big > > background process (anti virus etc.) hits and sucks resources > > (network, memory, disk etc.), away from the foreground processes. > > It's difficult to expect a a much less capable device to fare any > > better. > > > The real problem is support and not getting an application returned in > > the first 24 hours... imagine the user who has added "big fat > > background process" as an application on their phone. I'd imagine the > > developer of "big fat background process" doesn't add a disclaimer > > "this application may affect the quality and performance of other > > applications". How is the user to know that when your application is > > exhibiting signs of stutter or poor performance/frame rate (assuming > > it is coded right) that the issue is the background process. > > > Maybe Google needs to add a permission to suspend/throttle background > > processing and the API needs to have a way to let the application > > suspend background processing in sections of their own code. For > > example a game might allow background processing on loading screens or > > end of level screens, but not in time critical sections of code. > > > Just a thought. > > > On Mar 26, 4:52 pm, Sundog <[email protected]> wrote: > > > So the EULA for Java needs to be extended: > > > > "You acknowledge that Software is not designed, licensed or intended > > > for use in the design, construction, operation or maintenance of any > > > nuclear facility or side-scrolling games." > > > > This is why I've always avoided Java until now. If you can't write > > > realtime code what good is it, especially for critically important > > > things like nuclear plants and games? ;) > > > > On Mar 26, 7:23 am, Incognito <[email protected]> wrote: > > > > > You will have the same problem in a computer if too many apps are > > running. The solution in a computer is to uninstall and dump those programs > > that hug too much memory. Same thing will happen in android. Those > > background processes that cannot play nice will get a bad reputation and be > > uninstalled. People must write their background processes so that they > > consume as little resources as possible or face an early death. The game > > will only stutter if there is excessive gc. > > > > > On Mar 26, 2009, at 9:13 AM, Stoyan Damov <[email protected]> > > wrote: > > > > > I don't see how opengl helps with the fact that the game's code runs > > > > on the *same* processor, as the one, doing the GC. > > > > You can have all your drawing occur on the GPU, but the game will > > > > *still* stutter, if a background process triggers GC, because the very > > > > drawGameScene() call will be postponed because of the GC. > > > > > On Thu, Mar 26, 2009 at 1:54 PM, Incognito <[email protected]> > > wrote: > > > > > Did you try opengl? > > > > > On Mar 26, 2009, at 5:18 AM, "[email protected]" < > > [email protected]> wrote: > > > > > because I don't think Android can handle smooth scrolling. Tried > > > > myself with all sorts of views, surface views, always a horrible > > > > flicker even with 20 - 30fps. > > > > > Looking at the market its the same story. Most games don't attempt > > > > side scrolling and the ones that do end up with very jerky scrolling, > > > > e.g. deBlob $3.99 ported from iPhone. Alien Blood Bath is a similar > > > > story. > > > > > I'm starting to think this is a technical limitation.If it is, this > > > > could mean our games never compete with other mobile platforms and > > > > could limit Android's ability to compete in the market. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
