When the link drops, an Android panel keeps running and keeps its last screen. What stops is anything that needs the server, so the app has to plan for it.
This question arrives from the maintenance side rather than the purchasing side, usually after a first install: a supervisor pulls the network cable as a test, the screen freezes on a spinner, and the panel is declared unreliable. In most cases the hardware did exactly what it was asked to do. Android does not queue requests, retry writes or invent data when the network disappears; those behaviours belong to the application, and they are decided long before the panel is mounted.
The reference unit for this guide is a 15.6-inch Android panel: the BVS-VR156 15.6-inch Android panel PC, with a 1920 × 1080 ten-point capacitive screen, an RK3566 processor, 2 GB RAM, 32 GB storage, Android 11, two USB ports, one HDMI output, a TF slot and a gigabit LAN port.
1. The short answer
A panel with a dropped link stays powered, stays booted, keeps its local storage and keeps rendering whatever is on screen. What it loses is new data from the server, confirmation that a write succeeded, and an accurate clock reference. Three things therefore happen at the same moment:
- ◆ Whatever was cached stays visible. A work order list, a machine status page or a queue display keeps rendering from memory, which is why an outage on a panel sometimes looks like a working system.
- ◆ New actions have nowhere to go. A tap that posts a record will fail unless the app writes it locally first. The user sees either a queued confirmation or an error, and which one appears is a design decision.
- ◆ The clock drifts. Without a time server, the panel's clock runs on its own oscillator. After a few days offline, timestamps on locally stored records no longer match the rest of the estate.
None of that is a hardware fault. It is the normal behaviour of a thin client, and it is worth saying plainly in the handover document so that the next person who pulls a cable knows what to expect.
2. Three ways a link fails, and why they differ
“The network is down” covers three situations that behave differently on the panel, and a test that only covers the first one proves very little.
The second row is the one that catches people out. A panel with a static address survives a DHCP failure that leaves its neighbour dark, and a panel relying on a lease can drop off the network with a completely healthy cable. On a plant floor, where address ranges are managed by a different team from the one that owns the panel, a reservation on the server side is worth the five minutes it takes.
3. Android will not retry for you
This is the part that decides whether the project succeeds, and it is entirely in software. The operating system provides a network stack, not a delivery promise. If the app calls an endpoint and the call fails, nothing in Android stores that call for later unless the app does it.
Four patterns cover most panel applications:
- ◆ Write locally first, sync second. The tap writes to a local table, the screen confirms immediately, and a worker thread pushes to the server when the link returns. The operator is never blocked by a network that is not there.
- ◆ Give every record an ID before it leaves the panel. A UUID generated on the device makes retries safe: the server can reject a duplicate instead of creating a second work order.
- ◆ Retry with backoff, not in a loop. A tight retry loop on a saturated link turns a slow network into a dead one, and it drains battery-free panels into watchdog resets.
- ◆ Show the queue depth. A small counter in the corner — “3 pending” — tells the supervisor whether the panel is offline or simply idle, without a support call.
If the application cannot be changed, the alternative is a local gateway that buffers on the panel's behalf. That is a bigger project than most people expect, and it is usually cheaper to fix the app.
4. What 2 GB of RAM and 32 GB of storage really hold
An offline queue is a storage decision disguised as a network decision. The reference unit ships with 2 GB of RAM and 32 GB of eMMC, with 4 GB and 64 GB available as options, and a TF slot that takes cards up to 32 GB.
- ◆ The queue lives on eMMC, not in RAM. A queue held in memory disappears on the first power cut, which at a plant is the event most likely to coincide with the outage.
- ◆ Estimate the record size, then multiply. A machine-status event is a few hundred bytes; a scanned document image is a few hundred kilobytes. Ten thousand text records fit comfortably in a gigabyte; the same number of images does not.
- ◆ Reserve a floor for the system. An Android image and its cache occupy several gigabytes on their own. Treat the free space figure as smaller than the sticker suggests, and set a cap on the queue rather than letting it fill the partition.
- ◆ A card is for overflow, not for the main store. The TF slot handles a spool of images or a log archive, but a card that can be removed by a passer-by is not where an audit trail should live.
Two gigabytes of RAM is enough for one kiosk application and its cache. It is not enough for a browser with six tabs, a second app in the background and a queue of images waiting to upload, which is why the panel should run one thing.
5. What the screen should show when the link is gone
The default failure mode of a web-based panel is a modal dialogue over a grey page. On a plant floor that is the worst possible outcome: the last known machine status disappears behind an error box that nobody dismisses, and the panel becomes a decoration until someone walks over to it.
Three rules make an outage legible instead:
- ◆ Keep the data on screen. The last known state, greyed or badged, is more useful than an empty page.
- ◆ Stamp the last successful update. “Updated 14:22” tells a supervisor instantly whether the numbers are two minutes or two hours old.
- ◆ Separate stale from wrong. Data that is old is not the same as data that failed to save. Those two states deserve different colours and different words.
The panel helps here more than a small display would. At 1920 × 1080 there is room for a status strip along the upper or lower edge of the screen without stealing space from the working area, and 250 cd/m² is bright enough to read that strip under plant lighting without turning the whole interface into a light box.
6. Kiosk mode, the watchdog and the unattended restart
A panel that loses the network is usually a panel nobody is standing in front of. That makes unattended recovery part of the network answer, not a separate topic.
- ◆ Pin the application. Android 11 supports screen pinning and a locked-task mode; either keeps an operator, or a cleaner with a cloth, from leaving the app. A panel stuck on the settings screen is offline in every sense.
- ◆ Auto-start after boot. After a power cut the panel should come back to the application without a tap. Check this on the bench, not on the wall.
- ◆ A nightly restart is cheap insurance. A scheduled reboot at a quiet hour clears leaked memory in an app that has been running for weeks, and it costs the site nothing.
- ◆ Decide what happens to unsent records on reboot. If the queue is in memory, they are gone. If it is on disk, the app needs to reload it before the first request of the new session.
The housing helps as well: the unit is passively cooled with no fan to seize after a year of dust, and it runs from a 12 V 3 A adapter. Fewer moving parts means fewer reasons for a panel to be dark when someone finally walks up to it.
7. Time, identity and the reconciliation problem
An offline panel keeps its own clock, and that clock drifts. A week without a time server is enough to put timestamps minutes away from the rest of the estate, which turns a straightforward queue into an argument about which record came first.
- ◆ Store two times per record. The device time when the operator acted, and the server time when the record arrived. The first is the business fact; the second is the audit trail.
- ◆ Resynchronise on reconnect, and reconcile the offset rather than silently overwriting device timestamps.
- ◆ Keep the device identity stable. A queue is attached to a panel, and a panel that has been re-imaged with a new hostname is a queue the server cannot match to a station.
8. A failover path that pays for itself
A second network path sounds like a good idea on every project and is justified on rather fewer. The test is simple: how long can the station be blind, and what does that cost per hour?
- ◆ Wired first. The gigabit LAN port is the working path. A cable does not care about steel racking, and it does not drop a session when a forklift passes.
- ◆ Wi-Fi as a backup, not a peer. The 2.4 GHz radio is standard on this unit and keeps a panel reachable when its cable is being re-terminated. It is not a substitute for the cable in a room full of metal.
- ◆ Test the switch before adding redundancy. Most panel outages are a single failed port, and a spare port plus a labelled patch lead solves that for the price of a lead.
9. The half-UPS mistake
A common arrangement puts the network switch on a UPS and leaves the panel on a wall socket. When the power fails, the switch stays up, the server stays reachable, and the panel reboots — losing any queue held in memory and taking two minutes to come back. The site then reports that the panel “does not survive power cuts”, when what actually happened is that the panel was excluded from the protection it needed.
Either put the panel on the same UPS as the switch, or accept that both go down together and design the queue to survive a cold start. One of those two, decided in advance, is a plan; the other is a fault report.
10. A test script for the next site visit
Every one of these takes minutes, and together they answer the question in the title far better than a specification sheet:
- ◆ Pull the cable for fifteen minutes. Does the screen keep its data, and does it say how old that data is?
- ◆ Act while it is disconnected. Queue three records, reconnect, and count what arrives. Three is the right number; two means a silent loss.
- ◆ Kill the DHCP lease and watch whether the panel stays reachable on its reservation.
- ◆ Power-cycle at the wall. The app should return without a tap, with its queue intact.
- ◆ Compare the clock against a phone after a day offline. More than a minute of drift is worth a fix.
11. The reference unit in numbers
12. The short version
When the link drops, the panel is not the part that fails. It stays on, keeps its last screen and holds whatever the application told it to hold. What decides whether the station survives an outage is three software choices — a queue on disk, an ID generated before transmission, and a screen that reports how old its data is — plus two physical ones: a network path that does not depend on Wi-Fi through steel, and a power arrangement where the panel and the switch go down together or not at all.
The BVS-VR156 15.6-inch Android panel PC is the unit used throughout this guide, with a 1920 × 1080 panel, a gigabit LAN port, a TF slot and 32 GB of storage for a local queue. If the station needs a different screen size, the Android tablet PC collection lists the 10.4 to 32-inch range on the same platform. Tell us the application, the queue length you need to survive, and how the site is powered, and we will confirm the configuration.
