Given how few people actually know how this part of the system works, and how many people -think- they know how it works, I would take any feedback about unexpected behavior with a huge grain of salt. Unless you can get exact steps from someone: "the app was like this, I did this, then this, and now the app is like that" then I don't see any way to determine if they are reporting something that actually makes sense.
I mean, look at all of the developers who get complaints about "your app won't stop" or "your app starts running after I make it stop," when the app is actually behaving in a perfectly expected, desired, and ordinary way, and there is nothing wrong, nor anything that would cause the user's device to behave poorly in any way. Given that, what are the chances that someone who is reporting that a task killer app is starting other apps is just as confused? (We'll just lightly mention here the irony that some amount of this confusion is being caused by these task killer apps, such as how they are presenting the state of the system to the user in a misleading way.) There is no guarantee that after you call the restartPackage() function that the package won't just start right back up for some reason, such as a broadcast. In fact, what you are doing could very well allow other applications to start running. For example, there are are too many applications trying to run background services, the system will start killing them and not allowing all of them to run at the same time. If the user uses the task killer to stop the package of one of those services, that will free up memory for another service to then start running again. Or it will leave enough memory that some application that gets run occasionally in the background can now have its empty process kept around to be reused if it is launched again. Specific answers to your questions: On Wed, Dec 9, 2009 at 2:25 PM, justinh <[email protected]> wrote: > 1) Is it possible that some carrier build out there has changed the > functionality of this method to *actually* restart the package after > it's process is killed? > They shouldn't, since this is the method used to implement the user's "Force Stop" button in Manage Applications and elsewhere. I can't say that we have a good test for this API, though, so I wouldn't make guarantees. > 2) I haven't tested with a SenseUI phone - I'm thinking there might be > a situation where my app is killing a process that is shared by their > SenseUI business or something, which is then relaunched on TIME_TICK > or TIMEZONE_CHANGED or something. (similar behavior to myFaves on the > G1). For example, their Facebook UI might share com.android.mms? Can > anyone confirm this? > There are numerous reasons why processes may later get started after something is killed, as outlined above. It's really not something you can easily predict, nor is it something that was ever intended to be visible to users. Fwiw, the Running Services UI in Android 2.0 and later is a much more focused UI on just the things that can most typically impact the user experience. (The main other way background processes can impact their experience is by spinning the CPU or using power in other ways, and they should thus get the blame for a resulting low battery in the battery usage UI.) -- Dianne Hackborn Android framework engineer [email protected] Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups "Android Developers" 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-developers?hl=en
