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.

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.

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.

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.