Android Kiosk Mode: Device Owner and Lock Task

An unattended kiosk needs reliable restrictions, recovery, and updates as well as suitable hardware. Consumer Android hardware — TV boxes, tablets, all-in-one panels — is cheap, capable, and everywhere in Indonesia's supply chain. That's why photobooths, signage players, and self-service kiosks run on it.

A device that sits unattended in a mall for a year gets poked, unplugged, and occasionally attacked with a USB keyboard. It has to shrug all of that off.

Device owner, not a launcher hack

The cheap route is a "kiosk launcher" app: replace the home screen with your app and hope. It fails, predictably. The status bar can be pulled down and safe mode boots straight past your launcher.

The recents button exposes other apps. A USB keyboard opens shortcuts you never considered. Launcher replacement is a UI preference, not a security boundary.

The proper route is device owner provisioning. Think of device owner as a building's master key, not a key to one door — once it's set, it controls the whole device, not just what's on screen.

Provisioning happens on a factory-fresh device: via QR-code at setup, or adb shell dpm set-device-owner on bench-provisioned fleets. Supported provisioning paths and prerequisites depend on the Android version and device; factory-reset provisioning is the usual deployment route. Once active, device owner turns on what a kiosk actually needs: whitelisting lock task packages, hiding the status bar, blocking safe mode, disabling USB debugging and factory reset, and installing updates silently.

Provision on the bench, before deployment. Device-owner provisioning usually requires an unprovisioned device or a factory reset; check the supported provisioning route for the exact device before rollout.

Lock task mode

With device owner in place, the kiosk app runs in real lock task mode, not screen pinning. Screen pinning is built to be user-escapable. Lock task with an allowlist restricts navigation; the device policy controller can configure permitted system features. Test notification, dialog, and hardware-button behaviour on the target version. Power and volume behavior is configurable too.

Configure and test the boot path so the kiosk app starts in lock task mode. RECEIVE_BOOT_COMPLETED is one part of startup handling; background-launch restrictions and device firmware affect whether another screen appears first.

The watchdog

Recovery must work without somebody standing beside the machine to restart it. The app will die eventually — a crash, an ANR, a WebView that ate the heap, an HDMI handshake that never completed. Recovery has to be layered, each layer catching what the one above it missed:

In practice: the app heartbeats a small watchdog service in a separate process, and silence beyond a threshold means relaunch. A scheduled nightly reboot clears the slow leaks nobody will ever debug on a device in a mall. Every recovery event gets reported to the backend — a device that restarts itself twice a day is telling you something.

Remote recovery

A site visit with a USB keyboard adds to the cost of operating each device. So every kiosk carries a command channel (MQTT, FCM, or plain polling) that can restart the app, reboot the device, clear app data, pull logs, and capture a screenshot remotely.

Some application faults recover after a remote restart; others need rebooting or physical checks. Record recovery success on your own devices before setting visit targets. Plan which failures still require a site visit. The backend side of that channel is the same pattern as any device fleet — see the complete guide to IoT backends.

OTA updates without bricking the fleet

Device owner lets you install updates silently. That's exactly enough rope to brick every kiosk in one careless push.

The discipline: roll out in rings, a canary handful first, then the full fleet. Schedule updates inside a closed-hours window. Verify the APK checksum and signature from a trusted source. Test rollback too: Android normally blocks an ordinary downgrade, so retaining the previous APK alone is not a complete recovery mechanism.

Keep the previous APK as part of a tested recovery mechanism. Treat "app fails to reach healthy state after update" as a trigger for automatic rollback through a supported path.

The watchdog already knows what healthy looks like — reuse it as the update verdict.

The physical failure modes

Two problems no amount of software architecture fixes on its own:

• Power. Assume outages happen. Configure the board to power on automatically when mains returns — a capability that depends on the device firmware and power controller — and make the boot path land in the locked kiosk app with zero prompts. A kiosk that waits for someone to press a power button after a blackout is offline until the next site visit.
• Screen burn-in. Static UI elements can cause image retention or burn-in on susceptible panels. Shift static elements by a few pixels on a cycle. Dim during idle hours. Schedule the screen fully off overnight with a wake alarm. Cheap insurance against replacing panels across a fleet.

The takeaway

Kiosk mode is a stack. Device owner is the foundation. Lock task is the fence. A layered watchdog is the immune system. A command channel is the field team. Disciplined OTA sits on top.

A gap in any layer can undermine unattended operation. The content and fleet-operations half of this story — what these locked-down devices actually play, and how hundreds of them get managed — is covered in running Android TV signage fleets.