Emergency digital signage is sold on speed, and speed is the wrong thing to check first. The number a supplier quotes is how long a message takes to leave the server. What decides whether anybody sees it is whether the screen gives up what it was already doing. Most of the disappointment in this category comes from treating those as one problem.
Why a notification is not an interruption
A notification waits. It sits in a tray, or it asks the current application to yield, and on a wall-mounted television with nobody standing at it a tray is where messages go to be missed. An interruption is a different mechanism: the alert draws its own window above whatever is running, including a completely unrelated application, holds for as long as it is set to, and hands the screen back.
On Android that difference is a specific permission rather than a matter of design. An app that wants to appear over another app needs "display over other apps", the permission Android calls SYSTEM_ALERT_WINDOW. Without it, an application in the background cannot promote itself to the foreground, and the operating system is entirely correct to stop it. That rule is what stops any app you install from covering your banking screen.
The consequence is worth stating plainly. A player with that permission takes the screen. A player without it queues behind whatever is playing and waits for a turn that never comes. Both look identical in the panel, because the message was sent in both cases. That is why the useful question to a supplier is not "how fast" but "what happens when the screen is already showing something else, and how do you know it worked".
The permission decides whether emergency digital signage works at all
Here is the failure that costs the most, because it does not look like a failure. A television that was never granted the overlay permission plays its own loop perfectly. Content updates arrive. Schedules change on time. Somebody walks past it every day and sees a working screen. Then an alert is sent, and that screen alone does not carry it.
Nothing about the daily operation of that screen reveals the problem. The playlist does not need the permission, so a fault that only affects emergencies stays invisible until an emergency.
The permission is granted once, at setup, either by hand in the device's settings or with a single adb command during provisioning. That is not difficult. What makes it a recurring problem is everything that can quietly undo it: a factory reset by a contractor, a firmware update on a consumer panel, a replacement unit installed by somebody who was not told about the setup step.
The practical answer is to treat overlay capability as a reported property of each screen rather than an assumption made at install. Each player can report whether it is actually capable of covering another app, which turns an invisible fault into a column you can sort by. Signvero flags this in the fleet view, which shows which screens cannot draw over another app, so the question is answered before an emergency asks it rather than during one.
A television that passes a demo can still fail on the wall
The second-order problem is that overlay capability is not a single yes or no. It varies by what the screen is showing at the time.
Applications that handle protected video use secure surfaces, and Android gives an app the ability to hide overlay windows above its own content. Either mechanism can suppress an alert or blank the video underneath it, and which applies depends on the model, the firmware and the app. A demo in a meeting room with the player showing its own playlist proves nothing about a screen in a lobby that somebody has left on a streaming service.
This is not a defect in any particular product. It is how the platform works, and no signage vendor can promise otherwise on hardware they did not build. What a supplier can reasonably be asked for is a way to find out before the panels are mounted.
The test that answers it takes an afternoon. Take one unit of the exact model and firmware you intend to buy, factory-fresh. Confirm the player installs, that the overlay permission can be granted and survives a reboot, and that an overlay genuinely draws above the home screen. Then open each application anybody might realistically leave running on that screen, and record whether the alert still appears over it.
If the permission cannot be granted, or an overlay will not draw above the home screen, that hardware cannot do this job. Finding that out on one unit is cheap. Finding it out after twenty-five are on brackets is a different conversation.
The trade-off nobody mentions until the panels are mounted
The decision that follows from that test is whether the television is the computer, or whether it is a monitor with a small player behind it.
| The television runs it | A dedicated player behind it | |
|---|---|---|
| Builds to support | one per brand and OS version | one, across the whole estate |
| Overlay above other apps | depends on the model | reliable |
| Kiosk lock and silent updates | almost never available | usually available |
| Replacing a failed unit | involves the panel | swap the box, panel untouched |
| Memory and processor | shared with the set's own interface | dedicated to the player |
The player software is identical either way. What changes is how many different systems you support and how predictable they are. A mixed estate means as many quirks as you have brands, each updating its firmware on its own schedule without asking.
The honest counterweight is that a box per screen is a real line in the budget, and it belongs in the first version of that budget rather than appearing later. Predictability costs hardware; inconsistency costs support time for as long as the estate exists. Neither answer is wrong, but choosing by accident is. A summary of what to run it on, and what the televisions need to be capable of covers each route.
What happens when the network goes down mid-alert
Signage is usually sold assuming the network is there. The interesting behaviour is what happens when it is not, which is frequently the same moment an alert matters.
The mechanism worth understanding is where the content lives. If a screen streams its playlist, an outage is a blank wall. If content is cached on the device and addressed by a checksum, playback continues from local storage and a file is only fetched again when it changes. That is the difference between a screen that works through an outage and one that advertises it to everybody walking past.
Alerts are a harder case, and a straight answer matters more than a reassuring one. A message cannot reach a screen with no connectivity at all. What a system can do is keep the gap short: screens poll rather than waiting to be pushed to, so one that was briefly unreachable collects what it missed at its next poll rather than never.
Signvero's published figure is under a second with a live socket, and two to five seconds without one. The range is worth understanding when comparing suppliers: a system that depends on a socket is faster while the socket is up and has to fall back to polling when it is not. A design that polls by default is slightly slower and has one fewer thing to go wrong.
How do you know the alert actually appeared?
"Sent" is not a result. It is the beginning of one, and a surprising number of systems report it as the end.
Three separate things are worth distinguishing, and a panel that collapses them hides the interesting part. The server dispatched the message. The screen acknowledged receiving it. The screen reports that it displayed it. A screen can pass the first, fail the second silently, and nobody finds out.
The mechanism that closes this is the screen reporting back rather than the server assuming. Each screen sends a heartbeat with what it is playing, the storage it has left, the network it is on, the version it is running, and whether it can cover another app. Delivery is tracked per screen, so a message that reached forty-nine of fifty is visibly that.
There is a real limit here and it should be said. Reporting that a screen displayed something is not photographic proof that a person saw it, and on some hardware a screenshot cannot be captured without an interactive consent dialogue that a wall-mounted panel has nobody to answer. What is genuinely answerable is whether each screen received the message, acknowledged it, and was capable of showing it, which is enough to find the one that is wrong.
What this costs, and where the cost actually lands
Pricing in this category is usually per screen per month, and that structure charges you for the exact thing you are trying to do. The estate that succeeds is the one that adds screens, so the reward for the project going well is a bill that grows with it.
The alternative structure is a licence for the installation rather than per device, which changes what the fiftieth screen costs relative to the fifth. Signvero is licensed per site, and it is quoted per estate rather than published as a list price, because a five-screen clinic and a two-hundred-screen campus are genuinely different conversations. The pricing page explains what is included and what is not.
The second cost arrives three months in, and it is rarely the software. It is the hardware decision made earlier. A mixed estate of consumer panels generates support time indefinitely: a firmware update changes behaviour on one brand, a replacement unit arrives without the setup step, a model that worked is discontinued and its successor behaves differently. None of that appears in a first-year comparison.
The third is whoever is on call. A system that reports which screens are healthy lets one person check an estate in a minute. One that reports only "sent" turns the same question into a walk round the building.
What to do before ordering the rest of the fleet
Start with one screen, not twenty-five. Take the exact model and firmware you intend to standardise on, factory-fresh, and confirm the player installs, the overlay permission can be granted, it survives a reboot, and an overlay genuinely draws above the home screen and above every application anybody might leave running on that panel.
Write down what you find, including the applications where the overlay does not draw. That document turns a vague promise about emergency coverage into a specific one, and it is worth having before hardware is ordered rather than after.
Then decide the hardware question deliberately. If the panels pass, running on them directly is reasonable. If they do not, or if "the panels" means four different answers, a dedicated player behind each screen buys one build and predictable behaviour.
Finally, ask any supplier the three questions that separate the categories: what happens when the screen is already showing another application, what happens when the network is down, and how the panel tells you a specific screen did not display the message. The answers are more informative than any latency figure.
