A kiosk that looks locked during a five-minute demo may still expose Settings after a crash, show a permission dialog after an update, or sit at the launcher after a power cut. Those are not unusual corner cases. They are the paths that customers eventually find.
For a production Android kiosk, use lock task mode under a device owner or dedicated-device management policy. Do not build the product around screen pinning. Screen pinning is a user feature and can be exited; lock task mode is the managed-device mechanism that restricts the device to an allowlisted application or small set of applications.
Lock task mode and screen pinning are not interchangeable
Both features can make one application fill the display, but their security and lifecycle behavior differ.
| Capability | Screen pinning | Managed lock task mode |
|---|---|---|
| Intended use | Temporary user convenience | Dedicated and corporate-owned devices |
| Exit control | User can normally unpin | Device policy controls exit |
| App allowlist | No managed app set | Device policy controller allowlists packages |
| System UI control | Limited | Status bar, Home, Overview, notifications, and keyguard can be controlled |
| Provisioning | Manual user action | Device-owner enrollment or managed provisioning |
| Production suitability | Demo or supervised personal use | Kiosk, terminal, panel, and unattended appliance |
The distinction matters because a full-screen activity is not a kiosk either. Immersive flags hide navigation temporarily, but dialogs, gestures, crashes, and process restarts can reveal the system. Treat immersive mode as presentation behavior and lock task as device policy.
Make ownership part of manufacturing
Lock task mode becomes dependable only when the application that manages it has the required policy authority. In most commercial builds, that means provisioning a device policy controller as device owner while the unit is still in a clean state.
Decide who owns that controller. It can be a dedicated management application, the main kiosk application if the scope is small, or an enterprise mobility management agent. Whichever route you choose, document the package name, signing certificate, enrollment method, reset procedure, and replacement-board process.
Provisioning should be a factory station, not an engineer’s memory. A useful station record contains the device serial number, image build, policy-controller version, application version, enrollment result, and final kiosk self-test. If a factory reset removes ownership, the recovery work instruction must put it back.
For an AOSP product without Google services, verify the provisioning flow on the actual BSP. APIs may exist while setup screens or vendor customizations behave differently. This is one reason to evaluate the Android BSP before selecting an SBC, not after the enclosure is finished.
Design the boot path, not only the happy path
The kiosk should recover to a known state after cold power, application update, process death, and an interrupted network connection. A robust sequence is simple on paper:
- Android boots and starts the policy controller.
- The required kiosk packages are confirmed on the allowlist.
- The launcher or boot receiver starts the kiosk application.
- The foreground activity enters lock task mode.
- A local health check confirms the UI, peripherals, and network-dependent services.
- If a dependency is unavailable, the kiosk shows an owned offline state rather than a system dialog.
Do not assume a boot-completed broadcast is the whole design. Android can delay background execution, package replacement can change the process order, and a launcher race can leave the stock Home screen visible. For a single-purpose image, a custom Home application can be cleaner because Android already knows where to return when the foreground activity closes.
But a custom launcher creates responsibility. It must handle boot, app replacement, maintenance entry, and failures without becoming a second fragile application. We normally keep the launcher thin and put business logic in the kiosk app.
Control every route out of the application
List escape paths explicitly. The common ones are Home and Overview gestures, notification shade, power-menu actions, Settings activities opened by an intent, permission dialogs, USB accessory prompts, keyboards with settings shortcuts, and app links that launch a browser.
Lock task features can selectively expose system functions when the product needs them. Resist the temptation to enable everything during development and promise to remove it later. Start with the narrowest policy, then add only a capability tied to a written requirement.
Maintenance access needs equal care. A concealed multi-tap sequence is convenient but not strong authentication. Better options include a technician credential, time-limited code, managed remote command, or physical service input inside the enclosure. Log maintenance entry and always return to lock task after a timeout or reboot.
Hardware still matters. Exposed USB ports and debug headers can bypass a perfect UI policy. The Android SBC security guide covers the broader boundary; kiosk mode is one layer, not the entire security model.
Keep dialogs under application control
Unattended products fail badly when Android asks a question no user is authorized to answer. Exercise runtime permissions during provisioning. Preconfigure default handlers where the product owns the image. Test USB attachment, Bluetooth pairing, captive portals, certificate errors, low storage, and expired credentials.
If the app requires network service, build an offline screen that states what is still possible and automatically retries. Sending users into Wi-Fi Settings breaks the kiosk boundary and produces configurations support cannot reproduce.
Updates deserve a staged flow. The app should survive being replaced, the policy controller must not lose its authority, and the new version must return to the foreground. Coordinate this with the Android OTA update and rollback plan. Update one canary group first and keep a signed rollback path.
Validate failure recovery on real hardware
A kiosk test plan should be repetitive. Run it on the production board, touch panel, scanner, printer, payment peripheral, and network configuration.
| Test | Action | Pass condition |
|---|---|---|
| Cold boot | Remove power for 30 seconds, then restore | Kiosk reaches usable screen without exposing launcher or dialogs |
| App crash | Force the foreground process to stop | App restarts or launcher returns to it; lock task remains effective |
| App update | Replace package with signed next version | Policy remains valid and new activity resumes correctly |
| Network loss | Disconnect Ethernet and block Wi-Fi | Owned offline UI appears; no system settings are exposed |
| Peripheral churn | Reconnect every USB device in varied order | No unmanaged chooser or permission prompt blocks operation |
| Storage pressure | Fill data partition to the defined threshold | App warns, rotates data, and remains controllable |
| Maintenance exit | Enter and abandon service mode | Device relocks after timeout and records the event |
| Repeated cycles | Run hundreds of reboot and restart cycles | No intermittent launcher, keyguard, or setup screen appears |
Record video for intermittent boot failures and collect logs before the next automatic restart overwrites evidence. A test that passes 99 times and fails once is not “mostly done” for a kiosk deployed in thousands of locations.
Operational details that prevent support calls
Keep time, certificates, and storage healthy. A kiosk with a dead real-time clock can reject TLS certificates and look like a network outage. Rotate logs before the data partition fills. Give the application a version screen that a technician can read without leaving kiosk mode.
Also define what the customer may configure. Brightness, volume, language, accessibility, and network selection may be legitimate requirements, but they should appear inside a constrained product UI. Exposing general Settings because one control was missing is a large increase in support and security surface.
The existing self-service kiosk platform guide helps with board and peripheral selection. Lock task work starts after those requirements are known and turns the hardware into a controlled appliance.
Frequently asked questions
Can an ordinary app enable production kiosk mode by itself?
It can request lock task, but the managed experience depends on device policy and allowlisting. Without the correct policy authority, behavior can fall back toward user-controlled pinning or fail to meet the intended restrictions.
Should the kiosk app also be the launcher?
Sometimes. A custom Home app simplifies the return path on a single-purpose image, but it must be extremely small and reliable. Separate launcher and business apps can reduce coupling when updates are frequent.
Is lock task mode enough to secure a kiosk?
No. It controls the interactive Android surface. Production security also needs signed builds, verified boot, controlled updates, protected credentials, restricted debug access, physical port policy, and monitored fleet operations.
Bottom line
Reliable kiosk mode is a provisioning and recovery system, not a full-screen flag. Use device-owner policy, allowlist only the required packages, own the boot and offline paths, control maintenance entry, and hammer the product with restarts and peripheral changes. If every failure returns to a screen your team designed, the kiosk is close to production-ready.