I believe the notifications used to be delivered by a very long-lived TCP connection, and there probably is no limit to those on Android.
The reason to use the google services is mostly touted as for battery savings, I believe.
The reason to use the google services is mostly touted as for battery savings, I believe.
Not true since Android Oreo. Long running background Service execution (without a foreground notification) has been dead for a while. Most of the useful system-wide config change updates (implicit Broadcasts) got killed as well. Basically, only Google (or GCM/Firebase Messaging) gets to do timely push notifications. You can try to roll your own MQTT server, but there’s a good chance the OS will kill your Service, in which case you would have to poll every 15 minutes with JobScheduler/WorkManager, with no guarantee that background task would even get run every 15 min.
Thus, it makes total sense to have one mechanism for push messages for the entire device. It's great to have degoogled alternatives here.
This is now impossible with background execution restraints set in Oreo. The OS clusters requests for background execution and does them with the same wake. Apps can only wake the device every 15 minutes at most (and requests to wake are not guaranteed).
Signature spoofing is similarly "impossible" there's no rule saying this stuff can't be changed by distributions that care about it. You already have to install a custom OS to get rid of gapps to begin with so aside from the maintenance burden for changes that will never get upstreamed this is really a nonissue.