Windows EXE vs Android kiosk: what the choice actually decides
Both platforms run good self-service terminals. They fail in different places, and the failures show up after go-live, not in the demo.
A buyer comparing a Windows kiosk with an Android kiosk is usually shown two screens that look identical. The application is full-screen, the touch targets are large, the branding is the same. What differs is everything behind the glass: how the software behaves when the network drops, which peripherals it can drive natively, how hard it is to break out of, how it is updated across a fleet, and what the hardware underneath costs to specify and keep alive.
A note on where we stand. AtashiTech builds its packaged kiosk solutions as native Windows executables, and we also build locked-down kiosk-mode apps for Android tablets and iPads. So we have a position, and it is stated up front so you can weigh it. The comparison below is written from deployment realities, and the verdict at the end names the cases where Android is the better answer.
Windows kiosk vs Android kiosk, criterion by criterion
Eight criteria that decide most projects. Each card gives the practical position for both platforms.
Offline behaviour
- Windows EXE: a local database and a background service keep the journey running through an outage; transactions queue and reconcile when the link returns.
- Android: possible with a local store, but many Android kiosk apps are thin wrappers around a web page and stop when the page does.
Peripheral SDKs
- Windows EXE: the widest choice. Printer, scanner, payment, cash and biometric vendors ship Windows SDKs and OPOS drivers first.
- Android: good coverage for printers, scanners and Android-native payment terminals; thinner for cash recyclers, scales and gate controllers.
Lockdown
- Windows EXE: shell replacement, assigned access and group policy remove the desktop, taskbar and key combinations entirely.
- Android: device-owner mode with lock-task pins the app; strength depends on the device maker's firmware and your MDM.
Updates and fleet control
- Windows EXE: MSI or MSIX packages pushed through SCCM, Intune or an in-app update agent, with health reporting to a management platform.
- Android: APK push through an MDM or EMM; straightforward for the app, less so for OS patches on consumer-grade boards.
Hardware cost drivers
- Windows EXE: an industrial or mini PC, a Windows licence and a touch display; the PC is the largest line after the enclosure.
- Android: an all-in-one panel or a system-on-chip board; usually a lower bill of materials, offset by any peripheral that needs a bridge.
Security and data at rest
- Windows EXE: DPAPI or full-disk encryption, Active Directory identity, and a local database the application controls.
- Android: file-based encryption and work-profile isolation; enterprise identity usually goes through the MDM rather than the app.
Skills and longevity
- Windows EXE: .NET desktop skills are common in enterprise teams; long support windows on industrial Windows editions.
- Android: mobile developers are plentiful; the support window is set by the hardware vendor, and cheap boards age out first.
Best fit
- Windows EXE: peripheral-heavy, offline-critical, enterprise-integrated journeys with a long service life.
- Android: light journeys, single-terminal payments, signage with touch, high unit counts on a tight hardware budget.
Offline behaviour is the first question, not the last
A kiosk is judged by what it does when the network is down and nobody is watching.
Networks in lobbies, factory gates and food courts fail more often than the data centre does. The platform question is really a question about architecture: is the journey held in the terminal, or is the terminal a window onto a server?
Our Windows kiosk applications keep the journey in the terminal. A local SQL Server Express database stores every registration, token or transaction; a Windows Service syncs to the central system on a schedule and retries after an outage. The visitor still gets a badge, the patient still gets a token, and the record reconciles later. The kiosk application development page describes how this engine is built.
Android can be built the same way, and native Android apps with a local database do exist. The common failure is different: a large share of Android kiosk deployments are a browser in lock-task mode pointed at a web application. That is quick to build and easy to update, and it stops working the moment the page cannot load. If your journey must complete offline, ask any vendor, on either platform, to unplug the network during the demo.
Peripheral SDK availability decides the platform more often than the screen does
The application talks to printers, scanners, terminals, cash devices and gate relays. Somebody has to write and maintain that code.
This is where the two platforms diverge most. Peripheral vendors write their SDKs for the platform their installed base uses, and for retail, banking and industrial devices that base is Windows. Zebra badge and receipt printers, Epson OPOS receipt printers, Datalogic and Honeywell scanners, Pine Labs and Worldline payment terminals, Suprema fingerprint readers, JCM and CPI cash recyclers, and Wiegand or Modbus gate relays all have mature Windows integration paths, and these are the devices our solution pages name. The full list by category is on the integrations page.
Android coverage is real but uneven. Receipt printers and barcode scanners generally have Android SDKs. Payment is often simpler on Android because the terminal vendor supplies an Android-native device with the payment application already on it. Where Android becomes hard is the long tail: weighing scales on a serial port, note recyclers, document scanners, gate controllers and vital-signs instruments. Each one needs a USB-to-serial bridge and a driver that the board vendor may or may not support, and that dependency is yours for the life of the kiosk.
The practical test is to list every device the journey needs and ask the vendor of each for its SDK on your target platform. A self-checkout lane with a scanner, scale, cash recycler, card terminal and receipt printer nearly always lands on Windows for this reason. A food-ordering kiosk with one payment terminal and one printer has a genuine choice.
Lockdown and tamper resistance
The public will try every gesture, key combination and cable. The platform has to make all of them useless.
On Windows, a kiosk application replaces the shell. There is no desktop underneath, no taskbar, no Start menu, and the key combinations that would normally reach them are disabled by policy. Assigned access, group policy and the application's own watchdog work together: if the executable crashes, the service restarts it before the screen shows anything else. Because the enterprise already manages Windows, the same policies that harden office machines harden the kiosk.
Android lockdown is done through device-owner mode and lock-task mode, usually set by an MDM at provisioning time. Done properly on a device whose firmware respects it, this pins the kiosk app and hides the system UI. The risk is the device: consumer tablets and low-cost boards vary in how completely they honour lock-task, and a firmware update from the maker can change the behaviour. On an industrial Android panel from a vendor who documents kiosk mode, the outcome is close to the Windows one.
Updates, remote management and the fleet in its later years
A pilot of a few units is easy on either platform. The difference appears when the fleet is large and spread across sites.
Windows kiosks are packaged as MSI or MSIX installers and pushed through the tools the IT team already runs, such as SCCM, Intune or group policy, or through an in-app update agent that checks a central server at start-up and applies patches silently. Health telemetry, remote screenshots, log pulls and reboots come from an agent reporting into a kiosk management platform. Operating-system patches follow the enterprise's normal cycle.
Android app updates are simple: an MDM pushes a new APK, or the app updates itself from a private store. Operating-system updates are the weak point. They come from the board or panel maker, on that maker's schedule, and for inexpensive hardware the schedule often ends early. A fleet then runs an unsupported OS while the app is current. If you choose Android, choose a hardware vendor with a written OS support commitment and confirm your MDM can push OS images to it.
Hardware cost drivers, described without numbers
We do not publish prices, and hardware prices move too fast to print. The drivers are stable and worth knowing.
The enclosure, touch display and mounting cost roughly the same either way; they do not care what runs inside. The platform decision changes four things. First, the compute module: a Windows kiosk needs an industrial or mini PC and a Windows licence, while an Android kiosk can use an all-in-one panel or a system-on-chip board, which is usually the cheaper bill of materials. Second, the peripheral bridges: every device without a native Android SDK needs an adapter and integration work, and that can erase the compute saving on a peripheral-heavy unit. Third, the service life: industrial Windows hardware tends to have longer availability and longer OS support, so the fleet is replaced less often. Fourth, the software estate: if the enterprise already licenses management tooling for Windows, the kiosk rides on it; if not, an MDM subscription is an ongoing line either way.
The expensive mistake is choosing the platform on compute cost alone and discovering the peripheral gap after the enclosures are ordered. The scoping process we use lists every peripheral before any hardware is specified for exactly this reason.
Which one to choose
A neutral reading of the criteria above.
Choose a Windows EXE when the journey depends on several peripherals, must complete offline, has to authenticate against Active Directory or write to SQL Server, or will stay in service for many years. Self-checkout, bill payment with cash, contractor induction with gate release, and patient registration with document scanning all sit here.
Choose Android when the journey is light and the hardware budget per unit is the binding constraint: a menu with one Android-native payment terminal, a feedback or survey station, a signage screen that also takes touch, or a wayfinding panel. Android is also the right answer for the display side of a mixed deployment; our queue management solution drives Android display boards from a Windows kiosk over the local network.
Choose neither, yet, if the journey has not been mapped. Platform is a consequence of peripherals and offline requirements, not a starting point. Our related comparisons on kiosk vs tablet app and buying vs building kiosk software cover the two decisions that usually come first.
Not sure which platform your journey needs?
Send us the journey and the peripheral list. We will tell you which platform fits and why, including when the answer is not the one we build.
Frequently asked questions
Tell us the journey, the sites and the hardware you already have — every engagement is scoped and quoted individually.