4 ms·

> force kill applications so they can no longer process notifications I saw your article about push notifications on certain android phone manufacturers and fo

> force kill applications so they can no longer process notifications I saw your article about push notifications on certain android phone manufacturers and found it interesting -- something I hadn't seen before. Nice! But, if I'm not mistaken, the OP is focusing especially on android notifications raised by the app itself rather than push notifications. I'm not sure, but it seems like the problem he highlights involves compatibility-mode changes to the way apps run code while the app itself is also in the background. Or, it could be that the app developers are not using the officially recommended soup of background processing job scheduling classes the way Android says they should. Or, maybe that soup of classes isn't always as reliable as advertised.

p2t2p 8y ago
From what I know, Android app has to run a background service to listen for GSM notifications so if you kill it - no notifications for you. Am I being wrong, has it changed? My last android dev experience is about 5 years old.
- HillaryBriss 8y ago
  any app can raise a Notification i.e. a message box thingee that appears in the device's Notification Drawer. (this is different from a Push Notification.) and I think what the OP was talking about was this kind of Notification. i think he was saying that various apps that count on reliably running code in the background (e.g. when the app itself is in the stopped state and not visible on screen) are no longer able to reliably run that code in the background because Android decided not to let them do that on demand in a reliable way (in order to save battery). but that backgrounded code is what had been placing notifications in the Notification Drawer (when, say, the app became aware that there was a new email in your inbox or when a Calendar appointment was now one hour away, etc). as for push notifications, nowadays, Firebase Cloud Messaging is recommended. your app derives a service from FirebaseMessagingService and marks that service as "exported" in the manifest. and, you don't have to explicitly start that service. and, though i could be wrong, I think that service does not actually run in the background all the time. i think what happens is that some generic Firebase service invokes your app's service when a push notification has arrived for it. your app's service then processes that message as desired, and, if I understand correctly, it shuts back down. i believe Firebase is basically managing your service so that it does not have to run in the background all the time.

p2t2p 8y ago

From what I know, Android app has to run a background service to listen for GSM notifications so if you kill it - no notifications for you. Am I being wrong, has it changed? My last android dev experience is about 5 years old.

HillaryBriss 8y ago
any app can raise a Notification i.e. a message box thingee that appears in the device's Notification Drawer. (this is different from a Push Notification.) and I think what the OP was talking about was this kind of Notification. i think he was saying that various apps that count on reliably running code in the background (e.g. when the app itself is in the stopped state and not visible on screen) are no longer able to reliably run that code in the background because Android decided not to let them do that on demand in a reliable way (in order to save battery). but that backgrounded code is what had been placing notifications in the Notification Drawer (when, say, the app became aware that there was a new email in your inbox or when a Calendar appointment was now one hour away, etc). as for push notifications, nowadays, Firebase Cloud Messaging is recommended. your app derives a service from FirebaseMessagingService and marks that service as "exported" in the manifest. and, you don't have to explicitly start that service. and, though i could be wrong, I think that service does not actually run in the background all the time. i think what happens is that some generic Firebase service invokes your app's service when a push notification has arrived for it. your app's service then processes that message as desired, and, if I understand correctly, it shuts back down. i believe Firebase is basically managing your service so that it does not have to run in the background all the time.