Photo by Christian Wiediger on Unsplash
If you’ve ever built a desktop chat app, you already know the usual setup. You spin up a server in the middle. When someone sends a message, it goes to the server first, and the server pushes it over to the other person.
There’s a catch though. Normal network requests only go one way — client to server. Servers can’t just randomly shove messages at clients whenever they feel like it.
Desktop apps solve this with WebSockets. At startup the client opens a connection and tries to keep it alive forever. The server can then push events down that open pipe (we call these server-sent events).
Even that has a massive problem. The app that opened the WebSocket has to stay running the entire time. If the process dies, or the OS decides to kill it for memory or battery reasons, the connection vanishes and messages stop arriving.
The Android problem
Android lives on phones. Phones have tiny batteries, limited CPU, and they spend most of their life in someone’s pocket. Battery life is sacred. So Android is extremely aggressive about killing background processes the moment you leave an app.
That philosophy is great for battery, but it completely breaks the “keep a WebSocket open forever” model. A chat app that wants real-time messages, a news app that wants push alerts, or a doorbell app that needs to tell you someone is at the door — none of them can just sit there running in the background 24/7. The OS will murder them.
How Android actually solves it
Android was designed from day one as a mobile operating system, so the platform team could force a better pattern on everyone.
There’s one special system service called Firebase Cloud Messaging (FCM), usually running inside Google Play Services. That single service stays alive all the time and keeps a persistent connection open to Google’s servers.
Any app that wants to receive messages registers with FCM. When the user leaves the app, Android freely kills it. The FCM service keeps running.
When your own server needs to wake the app up, it doesn’t talk to the app directly. It sends a tiny “ping” (a data or notification message) to FCM. FCM delivers that ping almost instantly to the device. Android then starts a short-lived background component that the app registered, and that component can do whatever it needs — fetch the real data, decrypt it, show a notification, etc.
WhatsApp as a real example
Here’s the full flow for a typical WhatsApp message:
- You open the app and send a message.
- The message is encrypted and sent to WhatsApp’s servers.
- WhatsApp checks whether the recipient currently has an active connection.
- If not, WhatsApp sends a very small, almost empty FCM message (often just a wake-up signal, for privacy reasons).
- The phone receives the FCM ping, the OS wakes the device if needed, and starts WhatsApp’s background handler.
- That handler talks to WhatsApp’s servers, downloads the actual encrypted message, decrypts it, and displays the notification.
That’s it. The full app never has to stay running.
Why this is brilliant
For a chat app that gets dozens of messages a day, the constant wake-ups still use some battery. But think about a banking app that only needs to notify you a few times a month when a transaction happens. Or a package-tracking app. Or a smart-home camera. Keeping those full apps alive in the background just so they can listen for rare events would be pure waste.
Android’s design lets the OS stay ruthless about killing apps while still giving every app a reliable way to receive important messages. One always-on system service does the heavy lifting for everyone. Apps only wake up when there’s actually something to do, do the minimum work, and go back to sleep.
It’s a classic mobile-first trade-off that desktop OSes never really had to invent, and it works surprisingly well.
I hope this cleared up a bit of the magic behind those little notification banners that pop up on your phone. Let me know what you think in the comments.