In today's mobile ecosystem Android instant delivery of information is a critical function. Users expect to receive messages about new emails, orders or news immediately, even if the application is minimized or the phone is locked. This mechanism is provided by a complex interaction architecture between the developer server, Google cloud gateways and the device operating system. Understanding exactly how push notifications reach your screen allows you to better manage your smartphone's power consumption and configure critical alerts.
The main problem that this technology solves is the need for constant communication without constantly turning on the radio module. If each application itself constantly polled the server for new data, the smartphone's battery would be drained within a couple of hours. Therefore, Google has implemented a centralized system that maintains one persistent connection for all installed apps. This is the fundamental operating principle of Firebase Cloud Messaging (FCM), which replaced the outdated GCM protocol.
It is worth noting that there are alternatives to the standard solution from Google on the market, especially relevant for regions where Google services are limited. Large manufacturers, such as Huawei or Xiaomi, are developing their own notification delivery services that work on similar principles, but use their own servers. However, on a global scale, it is the Google ecosystem that dictates the standards for how applications should “wake up” the device to show information to the user.
Message delivery architecture via FCM
The notification delivery process begins not on the phone, but on the remote application server. The developer generates a data packet containing the header, message body and technical delivery parameters. This packet is sent not directly to the user's phone, but to servers Google Firebase. This middleware is necessary for routing and managing message queues if a device is temporarily unavailable.
The FCM server identifies the target device using a unique registration token. This token is generated when the application is first installed and is associated with a specific instance of the app on a specific smartphone. If the token changes (for example, after reinstalling the application), the old value becomes invalid and messages using it will not be delivered. This is an important mechanism securitythat prevents unauthorized persons from receiving data.
After receiving the packet, the Google server sends a signal to the device through a permanent encrypted connection. This connection is supported by a system service Google Play Servicesthat runs in the background regardless of the state of specific applications. It is thanks to this communication channel that the phone can remain in sleep mode most of the time, saving battery power, and “wake up” only when real data arrives.
⚠️ Attention: If Google Play services are removed or disabled on the device, standard push notifications will not work. In such cases, applications are forced to use their own background services, which dramatically increases battery consumption.
Message types: Notifications and Data
Technically, the FCM protocol supports two fundamentally different types of incoming packets, which are processed by the operating system differently. Understanding this difference is crucial for developers and useful for advanced users trying to diagnose delivery problems.
The first type is Notification messages (notification messages). They are intended to be displayed directly to the user. When such a packet arrives on the device, the system service itself generates a visual notification in the curtain, using the title and text from the packet. The application may not even start, which makes this type of message very lightweight and fast.
The second type is Data messages (messages with data). These packages do not automatically generate a visual notification. They are delivered directly to the application code, which must decide for itself what to do with the information received. The application can show a notification, update content in the background, or simply save data to the database. This method gives flexibility, but requires that the application is active or can be launched by the system.
- 📩 Notification message: Processed by the system, works even if the application is closed, the behavior logic cannot be customized.
- 💾 Data message: Processed by the application, allows complex code to be executed in the background, requires active logic in the app code.
- 🔄 Hybrid message: A combination of both types, containing data for display, and a payload for processing.
The choice of message type affects how the phone behaves in power saving mode. System notifications have higher priority for delivery, while background data may be deferred by the system until the user is active unless it is marked as urgent.
Impact of Doze Mode and Battery Optimization
Starting with version Android 6.0 Marshmallow, the system has implemented aggressive power-saving mechanisms known as mode Doze. When the phone is lying still and the screen is turned off for a certain period of time, the system limits the network activity of applications. In this state, normal background processes are suspended and network connections are closed.
However, the channel for high priority push notifications remains open even in Doze mode. This exception is made specifically to ensure the delivery of critical messages (calls, instant messengers). If a message is marked as high priority, it is able to "wake up" the device from deep sleep, turn on the screen and show the notification immediately.
Problems arise with low priority messages or those that are sent too frequently. The system can classify them as spam or overload and delay delivery until the user unlocks the phone and takes it out of Doze mode. This is a common reason why some news or promotional mailings arrive in batches only after the screen is turned on.
If important notifications from a particular application arrive with a delay, add it to the list of exceptions for power saving mode in the battery settings.
| Message priority | Behavior in Doze mode | Impact on the battery | Use example |
|---|---|---|---|
| High | Immediate delivery | High (wake up the device) | Incoming call, urgent message |
| Normal | Delivery delayed | Low (waiting for service window) | News, content updates |
| Background data | Blocking before activity | Minimum | Analytics synchronization |
Notification channels and settings management
In modern versions Android (starting from 8.0 Oreo) notification management has become much more granular thanks to the introduction of Notification Channels (notification channels). Previously, the user could only completely turn notifications on or off for the entire application. Now developers are required to distribute notifications into categories.
Each channel has its own settings: sound, vibration, importance, and the ability to display on the lock screen. For example, a messenger may have a separate channel for “Private Messages” (with sound and vibration) and a separate channel for “Promotions” (without sound and hidden). The user can turn off advertising without stopping receiving important messages from friends.
To access these settings, you must go to Settings → Applications → [Select application] → Notifications. Here you will see a complete list of channels created by the developer. It is important to understand that the user cannot delete a channel, you can only change its parameters or completely prohibit the display of notifications from this channel.
☑️ Checking channel settings
⚠️ Attention: If you do not see settings for a specific type of notification, the application may not have sent any messages yet in this channel. Channels are created dynamically the first time they are sent.
Registration tokens and data security
The security foundation of the entire push notification system is the registration token mechanism. A token is a long, unique string that acts as an address for delivering messages to a specific application on a specific device. Without knowing this token, the server cannot send data.
The process of obtaining a token occurs when the application is first launched. The application requests a token from Google Play Services, which generates it and returns it to the application. The application must then send this token to its developer server. If this step is skipped or done incorrectly, notifications will not work because the server does not know where to send the packets.
Tokens are not eternal: they can be revoked by Google's security system, changed when updating the application version, or reset by the user when clearing data. Good programming practice suggests that the application should be able to handle the situation of an invalid token and request a new one automatically.
From a privacy perspective, The token itself does not contain the user's personal data, but it is tied to the device. If an attacker intercepts the token, he can theoretically send fake notifications on behalf of the service, although he will not be able to decrypt the contents of the encrypted channel without the server keys.
What happens when you reset your phone?
If you completely reset the device (Factory Reset), all registration tokens are canceled. Applications will have to register again and receive new tokens, which may take some time after the initial setup.
Diagnosing delivery problems
If you are faced with a situation where notifications have stopped coming, the problem may be located anywhere in the chain: from the developer’s server to the settings of your router. The first step is to check the basic connectivity of the device with Google servers.
A common cause of failures is an unstable Internet connection or the use of VPN services that can block ports used by the FCM protocol. It is also worth making sure that the date and time on the device are set correctly, since time desynchronization disrupts the operation of SSL certificates necessary for a secure connection.
For in-depth diagnostics, advanced users can use system logs. Through a connection via ADB (Android Debug Bridge), you can track the moments of token registration and attempts to receive messages. The command for monitoring Google service logs is as follows:
adb logcat | grep -i "Firebase" | grep -i "Message"You should look in the logs for messages about registration errors or packets being rejected by the server. If the logs show that a message was received but is not displayed, the problem lies in the settings of notification channels or third-party blocking applications.
90% of problems with notification delivery are solved by checking the Internet connection, disabling the VPN and rechecking the channel settings in the application menu.
Why do notifications arrive with a delay?
Delays are most often caused by the Doze power saving mode, which delays delivery of low priority messages until the next "maintenance window". Also, the reason may be overload of the sender's servers or a poor network signal.
Is it possible to completely disable push notifications?
Yes, you can disable them globally in the system settings or for each application separately. However, system notifications about critical errors or security updates may ignore some user locks.
Do notifications affect traffic consumption?
The notification packets themselves are very small (several kilobytes) and consume a negligible amount of traffic. The main expense occurs only if you click on a notification and download heavy content (photos, videos).
What to do if notification icons disappear?
Check your launcher (desktop) settings. Some shells (for example, MIUI or OneUI) have separate permissions for displaying “Badge notifications”, which could be accidentally disabled.