How to build a kiosk mode Android app,
that actually locks down.
A kiosk mode Android app has a different job than most internal business apps. It doesn't just need a login screen, it needs to fight to stay the only thing on screen. Android does that with lock task mode and the dedicated device APIs; iOS does it two different ways. Here's what each actually locks down, and how to build the app behind it.
The short version
One app, nothing else on screen.
A kiosk mode Android app is an ordinary app running inside Android's lock task mode: a device policy controller allowlists the app's package, and the system hides notifications, the status bar, and the Home and Overview buttons while that app is running. Android groups this under what it calls dedicated devices, previously known as corporate-owned single-use, or COSU.
A single purpose device app built this way can't be backed out of, minimized, or swapped for another app by whoever is standing at the device — only a device admin, remotely, can release it. That's the entire point, and it's also why an android app kiosk mode setup needs more planning than adding one line to an app.
Where it shows up
Five shapes a single purpose device app takes.
The lock-down mechanics are identical across all five. What changes is the one screen it's protecting.
Check-in / visitor kiosk
A lobby tablet that logs a visitor and prints or shows a badge.
Self-order screen
A menu or product picker that ends in a payment step.
Digital signage
A slideshow or media loop with no input at all.
Field handheld
One job app, handed to whoever is on shift.
POS / payment terminal
A register that can't be swapped for anything else.
On Android
What “kiosk mode” means to Android.
Android doesn't actually call it kiosk mode anywhere in its own documentation — that's the term the rest of the industry uses for two things Android calls lock task mode and dedicated devices.
Lock task mode: the system feature
Lock task mode is the actual API, available since Android 5.0. While it's active, the system runs one app in an immersive, full-screen state: the status bar goes blank, notifications don't show, and the Home and Overview buttons disappear. Only apps a device policy controller (DPC) has allowlisted with setLockTaskPackages() are allowed to run this way, because the person at the device usually can't exit on their own. A DPC can also choose which system UI stays visible — notifications, a Home button, the lock screen — through setLockTaskFeatures(), so an android app kiosk mode screen doesn't have to be totally bare if you want a launcher-style experience instead.
Dedicated devices: the deployment model
Dedicated devices is Android's name for the broader pattern of using lock task mode to run a whole device for one job — what the industry used to call corporate-owned single-use, or COSU. The device is factory reset, then enrolled as fully managed, usually by scanning a QR code that carries the provisioning configuration. From there a DPC, an EMM built on the Android Management API, or a custom-built admin app owns the device: allowlisting apps, managing users if the kiosk is shared, and freezing OS updates during hours the device can't go down for a restart.
What actually stays on screen
Lock task mode doesn't have to mean a totally bare screen. A DPC can turn individual pieces of system UI back on with setLockTaskFeatures(). Everything below is hidden unless it's explicitly enabled, except global actions, which is on by default.
| System UI feature | Default state | What it does |
|---|---|---|
| Home button | Hidden | Enabling it shows the button, but tapping it does nothing unless the default launcher is also allowlisted. |
| Overview / Recents | Hidden | Opens the Recents screen. Requires the Home button to also be enabled. |
| Global actions | Visible | The only feature enabled by default. Long-pressing power shows the power-off dialog; without it, most users can't power the device off. |
| Notifications | Hidden | Full notification shade, icons, and heads-up alerts for every app. Requires the Home button to also be enabled. |
| System info | Hidden | The status bar's connectivity, battery, and sound indicators. |
| Keyguard | Hidden | Re-enables any lock screen set on the device. Rarely wanted on a public-facing kiosk. |
On iOS
iPhone splits this into two features.
Where Android has one API with two ways to trigger it, Apple ships two genuinely separate features that look similar from across the room.
Guided Access: manual, per-device
Guided Access is an Accessibility feature anyone can turn on in Settings. Triple-click the side button (or Home button on older devices), and the current app locks in place until someone re-enters the Guided Access passcode or authenticates with Face ID or Touch ID. It needs no device management enrollment at all, which makes it genuinely useful for a single demo device, a classroom iPad, or letting a kid use a phone without wandering into other apps — and genuinely useless as a way to manage a fleet, since someone has to be standing at each device to turn it on. Worth knowing: Apple disables Crash Detection and emergency calling during a Guided Access session.
App Lock: the MDM version built for fleets
App Lock is a device management payload an MDM pushes remotely, and it needs the device to go through Automated Device Enrollment. Once it's active, the chosen app reopens automatically after a restart — no triple-click, no passcode prompt, no one physically present. This is the one that actually competes with Android's dedicated device mode: both are built to lock an owned, enrolled device to one app indefinitely and unattended, and both are managed remotely rather than toggled by hand.
Side by side
Android vs iOS, the real comparison.
The fair comparison isn't Android against iOS, it's the three actual features against each other — because two of the three aren't built for the same job as the other two.
| Android lock task mode | iOS Guided Access | iOS App Lock (MDM) | |
|---|---|---|---|
| Who turns it on | A device policy controller or EMM | Anyone at the device, by hand | An MDM admin, remotely |
| Enrollment needed | Fully managed device | None | Automated Device Enrollment |
| Exits without an admin | No | Yes, with the passcode | No |
| Survives a restart | Yes | Session ends | Yes, reopens automatically |
| Built for | A fleet of unattended devices | One person, one device, briefly | A fleet of unattended devices |
In practice: Android's lock task mode and iOS's App Lock are the two features actually competing for a real deployment. Guided Access is a different tool entirely, closer to Android's screen pinning than to either kiosk mode.
Try it
Pick your kiosk type.
What a kiosk mode Android app locks to, and what to plan for, changes with the device. Pick the closest match.
Check-in / visitor kiosk
A lobby tablet that logs a visitor and prints or shows a badge.
Locks to
A name, photo, and Submit form — nothing else.
Typical hardware
Wall-mounted or countertop tablet.
Plan for
An idle timeout that returns to the blank form after every visitor.
Try it
Is your kiosk app actually ready?
Kiosk mode fails more often on planning than on code. Check off what's already sorted for your rollout.
0%
0 of 6 sorted
Early. Sort out who owns the DPC or MDM before writing any code.
Building it
Building a kiosk mode Android app in Newly.
Newly's job here is the app itself — a real, owned codebase built around one screen. Enrolling devices and allowlisting the package is a separate, native-project and device-management step that happens after export.
- 1
Describe the one screen the device should show
Not “build me a kiosk app” — the actual screen. “A check-in tablet that shows a name field, a photo capture, and a Submit button, nothing else” gives Newly something concrete to build, and keeps the app itself genuinely single-purpose instead of a full app with a kiosk mode bolted on.
- 2
Let Newly build the real screen and app shell
Newly generates an actual React Native and Expo native codebase around that one screen — not a webview, not a wrapped website. That matters here specifically, because lock task mode is a native Android setting, and you can only set it on native code you actually have access to.
- 3
Add the lock-down setting to the exported project
Since you own the source, set the activity's lockTaskMode to if_whitelisted in the native Android project Newly exports. This is a native-project config step, not a Newly prompt — it happens after export, in the Android project itself.
- 4
Hand the package to your DPC or EMM to allowlist
A device policy controller or EMM has to call setLockTaskPackages() to allowlist your app's package before lock task mode will actually engage on a managed device. This is the step that turns “an app that can run in kiosk mode” into “a device that's actually locked to it.”
- 5
Provision the devices
Factory reset each device, then enroll it as fully managed — usually by scanning a QR code with the provisioning config, or via NFC or an enrollment identifier for devices that don't support QR provisioning.
Why the app being real, owned code matters here.
Lock task mode is a native Android setting on a specific activity. A drag-and-drop builder that outputs a wrapped website has nowhere to put it. Newly generates a real React Native and Expo project you fully own, from $25/month, so the native config a kiosk needs is something you can actually reach and edit.
For the exact manifest and permission details a locked-down single-purpose device needs, see Android restricted permissions.
Where it fits
A single purpose device app is usually one piece of a bigger tool.
Kiosk mode is a device setting, not a whole product, so it tends to show up as the delivery mechanism for something else. A field inspection app locked to one handheld per inspector keeps the device on-task during a shift. A merchandising app on a company tablet works the same way in a store aisle. The lock-down is the same either way; what changes is the one screen it's protecting.
Why they fail
Where kiosk projects go wrong.
None of these four are code problems. They're planning gaps that only show up once devices are already in the field.
Kiosk mode bolted onto a general-purpose app
Locking a full app with a hamburger menu and six tabs into one screen just hides the rest of the app behind a wall the user can't see past. The screens people don't need should never have been built, not just hidden. Start from the one task, not from trimming an existing app down.
No plan for who allowlists the app
The app can be finished and the lock task code can be correct, and the kiosk still won't lock down, because nothing allowlisted the package on the device. That's a device policy controller or EMM step, entirely separate from the app itself, and it needs an owner before launch week.
Guided Access or screen pinning mistaken for a fleet solution
Both work fine for a single demo device or a personal accessibility use. Neither scales past a device you can walk up to and triple-click or pin by hand. A real rollout of more than a few units needs managed enrollment, not a manual toggle repeated on every unit.
No recovery plan for a dead or lost device
A kiosk sitting on a counter unattended eventually gets unplugged, factory reset by accident, or walks off. Fully managed enrollment (Android) and Automated Device Enrollment (iOS) both exist partly so a replacement device re-provisions itself instead of needing someone to drive out and set it up by hand.
FAQ
Kiosk mode Android app, answered.
A kiosk mode Android app is an app that stays locked to a single screen on a device, so whoever is standing in front of it can't get to the home screen, notifications, or any other app. Android builds this on lock task mode, part of what it calls dedicated devices (formerly corporate-owned single-use, or COSU): a device policy controller allowlists the app, and the system hides the status bar, notifications, and the Home and Overview buttons while that app runs. It's the same mechanism behind check-in tablets, self-order screens, and single-purpose handhelds handed to drivers or field staff.
Build the app first, lock it down second.
Describe the single screen your kiosk needs to show. Newly builds the real, owned React Native and Expo app around it, ready for your device policy controller or MDM to lock down.