[jayd16]

>The response time of my simple notification system was nearly instantaneous, but OK google, I'll play your game. I put together something that used FCM and it can take 15 or 20 MINUTES to get even a "high priority" message from FCM.

Letting your phone actually sleep is the battery saving feature. Also, you get throttled for high volume so check that as well.

If you think your messages are so important to have a constant socket open then make a foreground service. You're abusing a system that is really not suited to your needs.

[ajnin]

Some types of messages do require immediate attention of the user, or are of highest value if delivered immediately. Instant messaging apps have been using notifications for a long time and did not require a foreground service. Expecting instant delivery of that class of messages is not abusing the system.

[bchimp]

Even Apple, with its distaste for background processing, lets you declare an app with "VOIP" mode or something, where iOS manages the socket for you. You get access to simple server-based signaling, and as a bonus, you get to avoid the whole push-notification system.

Google just seems to have glommed everything into FCM. In the FCM console, push-notifications are really treated as a user-engagement/advertising thing. Throttling and spam prevention makes sense for that.

Maybe Android has something like the iOS VOIP mode that doesn't involve annoying the user with scary battery notifications, but I couldn't come up with anything at the time.

[jayd16]

While it's not really possible to do this in your own background service any more, GCM still supports this use case. This is the deprioritization the grand parent is talking about. If there's already a notification showing you won't get instant follow up responses. It's a compromise to be sure but if you want to break that compromise you have to make a foreground service.

[AstralStorm]

It was supposed to be possible, via standard notification mechanism and scheduler, new in 7.x. If Google starts flagging apps pinging network off the scheduler, everyone will get even more angry, as there will be a glut of foreground notifications just because they broke a use case.

[bchimp]

For my use case, the volume of messages was not an issue. This isn't a huge app that is pushing out tons of notifications. We're talking 10's or 100's a day, maybe.

In fact, it didn't matter at all once the initial notification was visible whether follow-on notifications were displayed. Possibly the fact that I was locally dropping the notifications (because the user didn't need them), the system counted those as "notification that weren't interacted with, so I'm going to slow you down at the server."?

I have no idea, and no way to find out, since FCM is pretty opaque at this point.