*In fact Running Services shows dependencies between apps -- the gray boxes are the app processes that need to be running due to the services. Admittedly the UI is cruddy; this should be improved in Gingerbread.* * * *Going the other way (showing the services used by an app) is not very interesting I think for users. The only app that really matters for this is the foreground app... which, when you are in running services, is the settings app. :) It doesn't matter what services background apps use, they are all free to be killed at any time. As a developer, you can see all this information yourself with "adb shell dumpsys activity".* * * *As for startService -- honestly the discussion here is just more evidence that what was done in 2.0 is an improvement. The request being made (I need to run my service in the background forever with no way for it to ever be killed for memory, because I need to do something the user is aware of every now and then) is the exact kind of abuse that the change was addressing, which had been causing significant problems on devices as they got low on memory. Having services running like that is a tremendous problem: when memory gets low, a big chunk of it can be in those services, with no way to reclaim it, and the user typically totally unaware of what is going on. They aren't going to go to the running services UI. Only advanced users will be going into that; normal users just shouldn't care.* * * *Could the UI be improved? Most certainly. Things can always be improved. The current API was designed an an idea towards being able to pull those notifications out into a separate UI, if we start seeing more services wanting to use this facility (and device memory has been increasing to actually make it feasible on many devices now to be able to have more than one or two running). Such a change will probably be done at some point, though I don't know when.* * * * * On Wed, Aug 11, 2010 at 9:56 AM, Kostya Vasilyev <[email protected]> wrote:
> When you try to stop a service in the 2.0's new "running services" screen, > Android displays a message that includes the name of the application that > owns the service. At this point, the user can confirm or back out. > > > http://3.bp.blogspot.com/_8qPyDn7SSew/S3SXdcpPwqI/AAAAAAAAAK4/lLyzjcSOYZ8/s320/stopservice.png > > Appears in that very same blog post by Dianne Hackborn: > > > > http://android-developers.blogspot.com/2010/02/service-api-changes-starting-with.html > > -- Kostya > > 11.08.2010 20:45, Indicator Veritatis пишет: > > And while we are dreaming, I want a display of an annotated dependency >> tree of services and applications, so that I the user can tell which >> service is needed/used by which application. And I want the >> annotations to take me to the application's website for a fuller >> explanation of how and why it uses the service;) >> >> And I want the annotations to explain why Market and My Uploads keep >> getting started when I didn't ask for them! >> >> On Aug 11, 9:12 am, Alessandro Pellizzari<[email protected]> wrote: >> >> >>> On Wed, 11 Aug 2010 11:04:19 -0400, Mark Murphy wrote: >>> >>> >>>> I agree that it'd be nice for a user to be able to "bless" a service, >>>> such that it wouldn't need startForeground(), or perhaps so its icon >>>> just wouldn't show up even if startForeground() is called. However, I >>>> can't fault the current implementation's objectives. >>>> >>>> >>> I think a good addition to the next Android version could be a "gallery- >>> style" (horizontally scrollable) list of running services in the >>> notification area. >>> >>> This way, no matter how many services you have running, they take exactly >>> 1 row in the notification window, leaving space for "real" notifications. >>> >>> The problem with "blessing" (and a disappearing icon) is that in a couple >>> of weeks I will forget I blessed that service, and in 1 year time, I >>> could >>> end up having dozens of services in bg... :) >>> >>> Bye. >>> >>> >> >> > > > -- > Kostya Vasilev -- WiFi Manager + pretty widget -- > http://kmansoft.wordpress.com > > -- > 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]<android-developers%[email protected]> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- 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
