A report last week, "Making the case for vertical UC: ROI, compliance and efficiency", restates the value of unified communications in regulated workplaces. One line item is often overlooked: emergency alerts that arrive on screens already in use. If the alert waits its turn, it fails. This article explains why interruption is non-negotiable and what it actually takes on Android hardware.
The difference between an alert and a notification
An alert is defined by its effect, not its intent. BS 8629:2019, the code of practice for evacuation alert systems, requires that an alert "shall override any other information being displayed". That single word, override, separates an alert from a notification. A notification is queued; an alert is immediate. If the screen is showing a safety briefing, a production dashboard or a live news feed, the alert must appear on top within seconds, regardless of what the screen was doing.
In practice, this means:
- The alert must be visible even if the screen is off or in standby.
- It must interrupt video, slideshows, web pages and full-screen applications.
- It must remain visible until acknowledged by a responsible person, not until a timer expires.
- It must work when the network is congested or down.
Why Android hardware makes interruption harder
Android was not designed for public signage. Consumer devices expect a single user who can tap the screen to dismiss a notification. Enterprise signage players typically run as a full-screen activity, but Android’s activity lifecycle does not guarantee that an activity will remain in the foreground. If the device receives a system update, a low-memory event or a scheduled reboot, the signage app can be pushed to the background. When that happens, a standard notification appears in the status bar, exactly where it will not be seen on a wall-mounted television.
To interrupt properly, the player must:
- Start from the background without user interaction.
- Draw over any existing content, including system UI.
- Prevent the user from dismissing it with the remote or touch.
- Survive a reboot if the power is restored before the alert is cleared.
The Android permission that enables interruption
Android provides one documented exemption for apps that need to start in the foreground from the background: the SYSTEM_ALERT_WINDOW permission. This permission allows an app to create a window that floats above all other apps, including the lock screen. It is the same mechanism used by screen recorders, chat bubbles and emergency call apps.
On a television, the permission is granted once at setup. The user taps a confirmation dialog, or a single ADB command is run during provisioning. After that, the app can launch its alert window at any time, even if the device is locked or the signage app is not running.
How interruption works in practice
| Requirement | Standard notification | True interruption |
|---|---|---|
| Visibility when screen is off | No | Yes |
| Visibility when another app is full-screen | No | Yes |
| Persists until acknowledged | No | Yes |
| Survives reboot | No | Yes |
| Works without network | No | Yes |
| Can be triggered by server | Yes | Yes |
A true interruption player runs as a foreground service. This service keeps the app process alive and provides a fallback mechanism: if the device refuses to start the alert window directly, the app posts a full-screen-intent notification. That notification is configured to launch the alert activity immediately, even if the screen is locked. The alert activity then takes over the display using SYSTEM_ALERT_WINDOW.
The trade-offs of interruption
Interruption is not free. The SYSTEM_ALERT_WINDOW permission is powerful, and Android treats it with suspicion. Some trade-offs:
- The permission must be granted manually or via ADB. It cannot be granted silently.
- Some device manufacturers add their own restrictions. For example, Samsung Knox devices require an additional policy to allow the permission.
- The alert window can be dismissed by the user if they have physical access to the device. In high-security environments, the device should be locked in a cabinet or mounted out of reach.
- The player must be designed to handle edge cases: low battery, thermal throttling, and system updates that revoke permissions.
What happens when interruption fails
If the alert does not interrupt, the consequences depend on the environment:
- In a hospital, a fire alert that queues behind a patient information screen could delay evacuation.
- In a factory, a gas leak alert that appears only after a slideshow ends could put workers at risk.
- In a school, a lockdown alert that is missed because the screen is off could leave pupils unprotected.
The common factor is that the alert is not seen when it is needed. The screen may show the alert eventually, but by then the damage is done.
How to test interruption before deployment
Before rolling out an interruption-capable player, test these scenarios:
- Trigger an alert while the screen is off. The alert should wake the screen and appear immediately.
- Trigger an alert while a video is playing. The video should pause, and the alert should appear on top.
- Trigger an alert while the device is locked. The alert should appear over the lock screen.
- Trigger an alert after a reboot. The player should start automatically, and the alert should appear.
- Trigger an alert with the network disconnected. The alert should appear using cached data.
If any of these tests fail, the player is not suitable for emergency alerts.
What to do next
If your current signage player queues alerts behind existing content, it does not meet the requirements for emergency alerts. To evaluate whether a player can interrupt properly:
- Ask the vendor to demonstrate interruption on a locked screen and during video playback.
- Check that the player uses the SYSTEM_ALERT_WINDOW permission and runs as a foreground service.
- Test the player on your own hardware, including edge cases like network outages and reboots.
- Confirm that the player is licensed per site, not per screen, to avoid unexpected costs.
Digital Signage is one product that meets these requirements. It is installed on the customer’s own server, licensed per site, and uses the SYSTEM_ALERT_WINDOW permission to interrupt screens instantly. There is no open demo; access is arranged with a person.
