Android™ kiosk and device management platform for retail stores

Store kiosks look simple until there are hundreds of them in several cities.

• Kiosks that don't stay kiosks: shoppers close the catalogue app, open a browser or change settings, and by lunchtime the tablet shows its home screen.
• Updates need a visit: every catalogue or app change means staff time in each store, so content goes stale.
• No view of what is broken: head office learns a kiosk is offline only when a store manager calls.
• Mixed hardware: different tablet models and Android versions behave differently when locked down.
• Several retailers, one product: each chain's devices, apps, prices and administrators must stay separate.

• Kiosk app (Kotlin): a catalogue with store stock, price check by scanning a barcode with the camera, "call a staff member" requests, an attract loop when idle and an automatic session reset after inactivity.
• Staff devices: a multi-app home screen on staff tablets and handhelds that shows only approved apps, such as stock lookup and assisted selling.
• Admin console (React): store groups, device inventory, a policy editor, app versions by rollout ring, remote lock and restart, and alerts when a kiosk goes quiet during opening hours.
• Enrolment kit: printed QR codes per store group, plus zero-touch for tablets ordered from participating resellers.
• Back end (NestJS): a tenant per retailer, catalogue and price sync from the retailer's POS or ERP, and queues for commands and alerts.

• Management layer: built on the Android Management API, which fits here because the product is offered to several retailers. Each retailer is a separate API enterprise, and each store group has its own policy.
• On the device: Google's Android Device Policy applies the policy. The kiosk app is installed as a kiosk app, receives its store ID and settings through managed configurations and is published privately through managed Google Play.
• Status: device reports and Pub/Sub notifications update the inventory. The kiosk app also sends a heartbeat every few minutes, because device reports arrive only periodically.
• Data: PostgreSQL for tenants, devices, policies and audit logs; Redis for command queues and alert timers.
• Hosting: services in Docker on AWS, with the console served as a Next.js app.
• If one chain wanted this only for its own stores, the API's usage policy would not fit. The same console would then sit on an existing EMM or a custom device-owner app.