0

In my app, I need to notify the user right after an event (i.e. geofence transition or arriving push message). By notifying I mean posting a system notification with vibration, sound and LED flashing,

Curently, I am posting a notification via android.app.NotificationManager directly from BroadcastReceiver - and it works. But if a device is inactive for a long time, I can observe some delay between sending a GCM message and notification sound/vibration (it can be even few minutes). If I give up waiting earlier and wake the device manually, I get the notification immediately after screen is on.

At first, Google's samples for GCM used the same pattern (posting notification from BR). However, they changed the samples in August and now notification is posted from the IntentService, with partial wake lock obtained before starting the serivce.

I assume that my code in BR will be executed even if the device is in sleep mode. The question is, if NotificatonManager can post notification and make sound/vibration in that state? After performing some tests of both implementations, I didn't notice any significant difference, but I want to be sure that it works this way.

In case of GCM, I know that there is an issue discused here, which may be the cause of delay too.

Edit:

It is clear for me that if device sleeps, it doesn't run any code at the application level. But on the kernel level, it can respond to some basic events (such as incoming phone call/sms), waking device up and generating broadcasts for BRs registered for this event.

For me, it would be logical that such an event holds its wakelock until all BR callbacks are completed (atomically) - probably that's why onReceive cannot perform long-running operations. I couldn't find any docs about it, so please correct me if you can prove that it's not true.

But, if the assumption above is correct, my broadcast should be received and executed immediately, because GCM has a wakelock. So the only delay between receiving GCM message and notifying user would be caused by NotificationManager. Thats my main question - is such delay possible (e.g. because of some async processing)?

Zbigniew Malinowski
  • 1,034
  • 1
  • 9
  • 22
  • `"I assume that my code in BR will be executed even if the device is in sleep mode."` I think this is an incorrect assumption. Your app will do nothing if the phone is sleeping. You must either wake it yourself, or wait for some other app to do so, and you can piggyback on their wakelock, which is probably why your notification is eventually going through after a few minutes. But that's not a good solution, because other apps might not hold a lock long enough for your receiver to complete its `onReceive` method. I think you need to set a repeating alarm with AlarmManager. – Tenfour04 Jan 30 '14 at 13:53
  • @Tenfour04: I've added some clarification to respond to your comment. – Zbigniew Malinowski Feb 04 '14 at 15:30
  • OK, yes, I would have had the same assumption that onReceive will return before the device sleeps again. Otherwise, you wouldn't even be able to ensure that it gets to the line where it requests a partial wakelock before starting a service. Maybe you have discovered a peculiarity of notifications, that they are embargoed until the host process has a wakelock or the phone is awake? – Tenfour04 Feb 04 '14 at 16:16

0 Answers0