If you are running a service that the user is aware of, you should use
Service.startForeground(). One of the things this does is tell the system
the user would not be happy if the service's process gets temporarily
One of the other things it does is make the user unhappy and write to
you
The JIT takes about 100K per process. It is pretty insignificant.
On Tue, Aug 10, 2010 at 7:11 PM, Eric F ericfrie...@gmail.com wrote:
I am running CM6 RC2 on my Droid, and one thing I think about is
whether or not the extra overhead per dalvik process of the JIT on the
limited RAM of the
On Wed, Aug 11, 2010 at 12:04 AM, Pent tas...@dinglisch.net wrote:
One of the other things it does is make the user unhappy and write to
you
because they have a permanent notification in their status bar.
So you are saying the user doesn't want to know who is playing sounds in the
background
So you are saying the user doesn't want to know who is playing sounds in the
background and have a clear way to get to the app to stop it?
A service doesn't need foreground to play noises in the background.
If it IS foreground, the notification doesn't help to 'get to it' or
stop it.
If my
Dianne, since Service.setForeground() has been deprecated, what should
we use to stop a service being killed?
In particular, how should you keep a service alive that needs to
listen and respond to phone state events?
And on phone state events, why is it that responding to an inbound
phone call
On Wed, Aug 11, 2010 at 4:36 AM, Pent tas...@dinglisch.net wrote:
So you are saying the user doesn't want to know who is playing sounds in the
background and have a clear way to get to the app to stop it?
A service doesn't need foreground to play noises in the background.
If it IS
On Wed, Aug 11, 2010 at 5:08 AM, William Ferguson
william.ferguson...@gmail.com wrote:
In particular, how should you keep a service alive that needs to
listen and respond to phone state events?
Don't use a service. Use a manifest-registered BroadcastReceiver
watching for
Ahh, thanks Marc. I have been using Intent.ACTION_NEW_OUTGOING_CALL to
determine if an outgoing call was being placed.
I wasn't aware of the TelephonyManager.ACTION_PHONE_STATE_CHANGED
Intent.
Won't it fire for both incoming and outgoing calls?
Seems strange the 2 Intents are not co-located.
But
On Wed, Aug 11, 2010 at 8:36 AM, William Ferguson
william.ferguson...@gmail.com wrote:
Ahh, thanks Marc. I have been using Intent.ACTION_NEW_OUTGOING_CALL to
determine if an outgoing call was being placed.
I wasn't aware of the TelephonyManager.ACTION_PHONE_STATE_CHANGED
Intent.
Won't it fire
My app needs a permanent background service for monitoring.
Why?
For numerous reasons, a primary one being I can't figure out when a
new
app launches within a reasonable time and resource usage otherwise.
We can't even change the icon dynamically to give it some
informational
use, as I
On Wed, Aug 11, 2010 at 10:43 AM, Pent tas...@dinglisch.net wrote:
For numerous reasons, a primary one being I can't figure out when a
new
app launches within a reasonable time and resource usage otherwise.
This should be a hint that what you're doing isn't really supported by
the platform.
skipped text before I start getting all religious
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
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
Why are you advising the use of a deprecated API that is now a NOP???
On Aug 10, 7:10 pm, Dianne Hackborn hack...@android.com wrote:
On Tue, Aug 10, 2010 at 5:41 PM, Streets Of Boston
flyingdutc...@gmail.comwrote:
I have no empirical evidence for it, but i did notice that non-
foreground
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
On Wed, Aug 11, 2010 at 11:35 AM, Indicator Veritatis mej1...@yahoo.comwrote:
Why are you advising the use of a deprecated API that is now a NOP???
She's not - she just left out the parameters to clarify.
There are two versions of startForeground, the old one with one boolean
parameter and a
On Wed, Aug 11, 2010 at 12:35 PM, Indicator Veritatis mej1...@yahoo.com wrote:
Why are you advising the use of a deprecated API that is now a NOP???
She advised the use of startForeground(). setForeground() is now a
no-op. These are not the same.
--
Mark Murphy (a Commons Guy)
setForeground() is depreciated
startForeground(int id, Notification notification) is the replacement,
new as of 2.0
http://android-developers.blogspot.com/2010/02/service-api-changes-starting-with.html
-- Kostya
11.08.2010 20:35, Indicator Veritatis пишет:
Why are you advising the use of
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.
Let's replace this:
On Wed, Aug 11, 2010 at 11:41 AM, TreKing treking...@gmail.com wrote:
On Wed, Aug 11, 2010 at 11:35 AM, Indicator Veritatis
mej1...@yahoo.comwrote:
Why are you advising the use of a deprecated API that is now a NOP???
She's not - she just left out the parameters to
*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
Does your service issue a call to request it'll be run in the
foreground? If so, look at this link:
http://android-developers.blogspot.com/2010/02/service-api-changes-starting-with.html
and look at the deprecated startForeground and stopForeground methods.
Froyo is much more aggressive in
On Tue, Aug 10, 2010 at 3:11 PM, Streets Of Boston
flyingdutc...@gmail.comwrote:
Froyo is much more aggressive in killing non-foreground services that
older Android versions.
It is? News to me! :)
For the original poster -- if by force close you mean the app error
dialog, the #1 thing to do
Its not a force close, it just gets stopped by the system.
On Tue, Aug 10, 2010 at 5:07 PM, Dianne Hackborn hack...@android.comwrote:
On Tue, Aug 10, 2010 at 3:11 PM, Streets Of Boston
flyingdutc...@gmail.com wrote:
Froyo is much more aggressive in killing non-foreground services that
:)
I have no empirical evidence for it, but i did notice that non-
foreground background services were being killed more aggresively. But
i could be mistaken.
On Aug 10, 8:07 pm, Dianne Hackborn hack...@android.com wrote:
On Tue, Aug 10, 2010 at 3:11 PM, Streets Of Boston
On Tue, Aug 10, 2010 at 5:41 PM, Streets Of Boston
flyingdutc...@gmail.comwrote:
I have no empirical evidence for it, but i did notice that non-
foreground background services were being killed more aggresively. But
i could be mistaken.
It could be more memory. Oh and also there is now a
I am running CM6 RC2 on my Droid, and one thing I think about is
whether or not the extra overhead per dalvik process of the JIT on the
limited RAM of the device (only 256M for an hdpi device). So even
though the rules about process killing may not have changed the device
could get into low memory
27 matches
Mail list logo
