Process life cycle

1. Yes.
2. Yes. Service_Create is only called if the service was not running (dead). Service_Start is always called.

There is no way to find the current displayed notifications. However if you use the same ID then there will be no duplicate notifications.

Erel said:

1. Yes.
2. Yes. Service_Create is only called if the service was not running (dead). Service_Start is always called.

There is no way to find the current displayed notifications. However if you use the same ID then there will be no duplicate notifications.

Click to expand...

thanks,

the problem is that it will leave a notification and I have no way of clean it up (until the service reboot) - thats too bad

You can remove the notification in Service_Destory.

Erel said:

You can remove the notification in Service_Destory.

Click to expand...

As I said the service_destroy is not ben called, should it ?
can you check ?

Service_Destory is expected to be called in most cases. In some cases if the system is very low on resources Android may just kill the process.

it never get called for me, in the following two scenarios
1. I kill it using a task manager
2. it died due to phone issues (activity monitor restart all processes (maybe due to low memeory / CPU dont know)

is it possible I'm doing somethign wrong ?

I put log in it, and never saw it (after many many tests)
I put notification in it and never saw it
I restarted the service after 30 sec (and did not happened as much as I can see)

Nir

is it possible I'm doing something wrong ?

Click to expand...

I don't think so.

The real question is why do you need to remove the notification when the service is killed? The user doesn't need to know when your service is killed or created.

The user will press on the notification and your process will start if needed.

My app put in the notification connectivity infomration
the Wifi SSID + ip or mobile carrier name + IP
and the connected bluetooth device name

when the service get killed the notification might be incorrect so I want to remove it,
in most cases it is ok, since I'm listening to connectivity events and will be awaken when a change happen

so more or less it is ok, but still the edge case is that when the service awake it does not know if a notification exist or not and what it is, so it recreate it (which mean you get an additional vibrate / sound etc for no change what so ever)

I can mitigate it a bit be keeping the state in a file but since it it not 100% that the file got written before the app got killed, I willhave cases where the service started it look at the file decide that the notification is the same (which is not - the change just move to the exact place before the crush) and present wrong status
or decide to do the extra vibrate for not reason

nir

I agree that a solution based on a file is too problematic in this case.

Consider calling Service.StartForeground. It will prevent Android from killing your service (except of with a task manager).

thanks, I'm trying not to use it
BTW I'm lisenting to events using both Phone lib
and with adding manually to the manifest file ,for example

I get duplicate events - but not always,
can you explain the difference between the two (not important the actual action type, assume both are the same)

thanks

See this link for more information on intent filters:
Intent Filters - Intercepting SMS messages in the background

Erel said:

See this link for more information on intent filters:
Intent Filters - Intercepting SMS messages in the background

Click to expand...

thanks, exactly what I needed and thought !