Android fork cannot intercept request between (for example) Slack backend servers and Google backend servers.
To fork this service, you need your own push notification infrastructure and then persuade app developers to implement it as another option (next to Apple, Google, Firefox, Huawei and other existing ones).
There are push arbitrator services which make this easier, so perhaps having those on board might be a good path forward.
...oh, I just re-read the great-grandparent. I didn't realize the application's servers were talking to Google's servers, I thought the application was talking to Google's servers directly. That seems terribly convoluted, although I assume there's actually a sound reason for it.
The push servers (Google, Apple, etc.) effectively work as a message queue server - they aggregate and batch payloads and send them to the devices. The devices keep a single persistent HTTP connection for reception of all possible messages.
It's built like that due to efficiency - the devices need to minimize number of radio and CPU wakeups to keep running on battery. In early days of Android each app handled this by itself. This resulted in apps polling their servers on fixed interval (e.g. every 5 minutes, etc.) which caused a disastrous tragedy of the commons and horrible standby battery life.
This is why the approach was changed to mandatory push services - the long-lived TCP connection, push aggregation and radio management have significantly prolonged battery life.
To fork this service, you need your own push notification infrastructure and then persuade app developers to implement it as another option (next to Apple, Google, Firefox, Huawei and other existing ones).
There are push arbitrator services which make this easier, so perhaps having those on board might be a good path forward.