Repurposing an Android ad display as a shop kiosk

Should you keep the Android board or replace it for a kiosk?

Keep the board for a kiosk where customers order and pay at the counter. If the whole stack fits inside the roughly 1.75 GB that stays available once the Android interface is stopped, and software rendering at 1920 × 1080 looks acceptable, the board is the low-risk choice.

The reasons to replace sit in three hardware facts: 2 GB of RAM with no upgrade path, a GPU with no usable Linux driver, and a vendor kernel from the 3.10 era that pins modern software to a chroot. Add your deployment requirements and the split comes out clean. A kiosk that shows products, takes orders and hands payment to the counter runs well on the old board. A kiosk that takes payment on the screen needs an operating system with a patch horizon measured in years, and this board's base system has a short one. Rendering decides the middle ground: text, grids and forms look fine in software, while smooth video and scrolling animation do not.

How much RAM does the kiosk stack get on a 2 GB board?

Measure free memory with the Android interface stopped, because that is the pool your kiosk lives in. One measurement on this class of board shows about 780 MB completely free plus roughly 970 MB of reclaimable file cache, about 1.75 GB usable.

Android's visible processes hold 150-250 MB while the interface runs; stopping Zygote and SurfaceFlinger ends them, and the file cache returns to the pool on demand. A 32-bit Chromium build also uses a little less RAM than the 64-bit build, which favors an ARMv7 board. Two habits keep the budget honest: run a trimmed profile with no extensions and a small disk cache, and cap the browser where the init system allows it. On a replacement board with systemd as init, limiting Chromium kiosk memory usage with systemd-run turns a runaway tab into a clean restart instead of a frozen screen.

Worked example: how much RAM is left for Chromium?

This scenario runs the numbers for a 2 GB board where a measurement under full Android shows 779 MB completely free and 971 MB of reclaimable cache, and it ends with a pass mark of 1200 MB for Chromium's measured peak.

1. Stop Zygote and SurfaceFlinger so the interface processes exit. Usable pool: 779 MB + 971 MB = 1750 MB.
2. Reserve 250 MB for the kernel, the bootstrap that mounts the Debian image, the watchdog and logging. Chromium budget: 1750 - 250 = 1500 MB.
3. Open the real storefront, cart, contact form and on-screen keyboard, then read Chromium's peak memory from its own task manager. Pass mark: 1200 MB or under, which leaves 300 MB, 20 percent of the budget, for leaks and spikes.

Result: a stack that peaks at 1200 MB passes and the board keeps its job for a counter-payment kiosk. A stack that creeps past 1500 MB fails, and the mainboard comes out.

Is software-rendered Chromium at 1920 × 1080 good enough for a storefront?

Yes for pages that change between taps and sit still otherwise. Software rendering drives 1920 × 1080 at 60 Hz acceptably for product grids, carts and forms, and it visibly fails on smooth-scroll animation, large blurred images and video.

The GPU on this board class has no usable Linux acceleration stack configured, and vendor Android graphics libraries rarely port into desktop Chromium cleanly. Test with the real page: open the category list, scroll it, add items to the cart, and watch for stutter and dropped frames. A page that passes costs you nothing that matters in software. An advertising loop that plays outside opening hours and needs smooth video is a replacement argument. One color note: a pale, cool cast on this panel class usually comes from the panel's white point, so work through the controller's color settings in software before ordering hardware to fix color.

What does a public payment kiosk need for session reset and crash recovery?

Three behaviors, each demonstrable before launch: browser data cleared between customers, an automatic return to the start page after an idle timeout of 30 to 60 seconds, and a relaunch within seconds of a crash or a power cut.

Kiosk browser modes in current desktop browsers document the pattern. The session resets by closing the browser, and the browser stays closed after that, so a supervisor has to relaunch it. On the old board you script all three parts yourself: a fresh profile per customer, an idle timer that navigates home, and a watchdog that restarts the stack when Chromium dies. The watchdog already present on this class of install, which restarts Android after every test, is the same idea applied one level up.

On a replacement board the service manager handles the relaunching; setting up Chromium kiosk autostart on a Linux panel covers that base. Payment sets the limit: card entry on a public screen needs an OS with a multi-year patch horizon, so keep payment at the counter until the mainboard is swapped. The pre-order app with age confirmation and payment at pickup that you run today is correctly scoped for this board.

Can you reuse the 47-inch panel with a new mainboard?

Almost always, yes. A USB HID touchscreen plugs into any board with host ports, and the panel moves to a new mainboard either through a real HDMI input on the cabinet or through an HDMI-to-LVDS converter matched to its datasheet.

Check the HDMI connector's direction first. On advertising and signage displays the port is usually an output from the player board, and a true input exists only where the cabinet was built with a switch or capture path; we explain why HDMI input on Android signage players rarely works. If the cabinet has no true input, the panel's LVDS interface is the route, and that starts with identification. Find the model label on the panel's metal frame, behind the cabinet or under the bezel, and pull its datasheet. The datasheet names the supply voltage, LVDS channel count, bit depth, native resolution and backlight specification, which is everything the converter matching in the next section needs.

The touch side is simpler: controllers of this type enumerate as USB HID, report an absolute coordinate range of 0-32767 with 10 multitouch slots, and work on any host. After portrait rotation, remap the axes (on this panel, screen X comes from touch Y and screen Y from inverted touch X) and run one calibration pass.

How do you match an HDMI-to-LVDS converter to the panel?

Match five specifications from the panel datasheet before you order anything: supply voltage, LVDS channel count, bit depth, resolution and timing, and the backlight connector with its enable line.

• Supply voltage. Converter boards in this category accept a wide 5-12 V input. The panel rail is separate and is commonly 3.3, 5 or 12 V; the datasheet value rules, because over-volting the panel rail kills its driver.
• Channel count. Single-channel LVDS panels and dual-channel panels use different standardized connector layouts, and the datasheet names which one you have. A single-channel converter cannot drive a dual-channel panel, and many 1920 × 1080 panels run dual-channel at 60 Hz.
• Bit depth. An HDMI-to-LVDS converter works by converting HDMI to 24-bit RGB and then to LVDS, so it natively serves 8-bits-per-color panels; an 18-bit panel needs a converter with a 6-bit-per-color mode.
• Resolution and timing. The converter's supported list must include 1920 × 1080 at 60 Hz, or the screen stays black.
• Backlight. Typical converter boards expose a backlight interface carrying the enable and brightness lines; confirm the converter's backlight output matches the panel's backlight connector, because the converter switches the backlight on and off.

One safety note: power the cabinet down, orient the LVDS cable to the datasheet's marked first conductor, and keep the backlight rail disconnected until the converter is configured. A reversed or offset LVDS cable destroys panel drivers on first power-up.

Where does each option win, and what is the decision?

Keep the board when no payment happens on the screen and Chromium's measured peak stays at or under 1200 MB; replace the mainboard the moment customers pay on the screen, or when the storefront will not scroll cleanly in software at 1920 × 1080.

• The old board wins for an order-and-collect kiosk: payment at the counter, one screen, pages made of text and product grids, and a requirement that rollback to the original system stays possible.
• A new mainboard wins for payment on the screen, an advertising loop with smooth video outside opening hours, several kiosks under central administration, and a patch horizon measured in years.

Recommendation: keep the existing ARM board for a kiosk with payment at the counter if the 1200 MB test passes and the real page renders cleanly in software. Replace the mainboard with a current single-board computer or an x86 mini PC for any on-screen payment project, and move the panel over through HDMI input or an HDMI-to-LVDS converter matched to the datasheet's voltage, channel count, bit depth, timing and backlight connector. Keep the boot chain untouched until the decision is made, and keep two checksum-verified backups of the original system either way. If the screen's real job turns out to be advertising instead of checkout, our small retail displays play straight from a card with no subscription and skip this conversion entirely.

Questions