Configure an Android kiosk by enrolling the device as fully managed, so your device policy controller (DPC) is the device owner, then allowlist the kiosk apps for lock task mode, make the kiosk app the persistent home screen and test both the user workflow and administrator recovery. Lock task mode is enforced by the DPC; screen pinning, which a user can leave, is a different feature. Confirm each device model and Android release on its own. This guide covers Android dedicated devices only; iOS single-app devices use Apple’s own mechanisms and need their own procedure.
For the product scope, see Android kiosk management and device management.
Ownership and enrolment
Lock task mode is a device-owner capability. Only a DPC that is the device owner, or the profile owner of an affiliated user, can set the lock task allowlist. A work profile on a personally owned phone cannot turn the whole device into a kiosk. Provision dedicated devices as fully managed from a factory reset, and approve the data removal that provisioning requires.
Choose a pilot device the organisation is authorised to manage. Record its model, Android release, security patch level, management agent version and enrolment method. Enrolment itself is covered on device enrolment.
Define a usable restricted workflow
List the main app, any companion apps, the sign-in journey and the peripherals the task needs: scanner, printer, payment terminal or camera. Include keyboard, accessibility and network-recovery needs. Decide which system functions must remain available and who may authorise maintenance access.
Install and launch the required apps before restricting anything. Confirm that each app reaches its services, completes authentication and performs the intended task. The kiosk policy should preserve that working baseline, not hide an installation or identity problem.
Write the administrator recovery procedure before applying the policy. Keep its credentials separate from ordinary user access. Agree a local or physical recovery path as well as a remote one, because the network can fail.
Configure single-app and multi-app policies
Otukan runs dedicated Android devices in single-app kiosk mode and in multi-app kiosk mode with a restricted launcher. Administrators choose which system features stay available in lock task mode, within what each Android release allows. The platform sequence below gives developers and administrators a shared basis for verifying the result on the device.
Apply the Android lock task boundary
- Inventory the exact package names. For a single-app kiosk, identify the app that owns the workflow. For a multi-app kiosk, include the kiosk launcher and each companion app.
- Set the allowlist with
DevicePolicyManager.setLockTaskPackages()and read it back withgetLockTaskPackages(). An app can check its own status withisLockTaskPermitted(). - Make the kiosk app the default home screen with
DevicePolicyManager.addPersistentPreferredActivity(), using an intent filter forACTION_MAINwithCATEGORY_HOMEandCATEGORY_DEFAULT. The device then returns to the kiosk app after a restart or a press of Home, rather than offering the stock launcher. - Enter lock task mode. The kiosk activity can call
startLockTask()itself, declareandroid:lockTaskMode="if_whitelisted"in its manifest, or be launched by the DPC withActivityOptions.setLockTaskEnabled(true)on Android 9 or higher. - Choose the system UI that stays available with
setLockTaskFeatures()(Android 9 or higher). By default the Home and Overview buttons, notifications, the global actions menu and the status bar information are hidden. Flags such asLOCK_TASK_FEATURE_HOME,LOCK_TASK_FEATURE_NOTIFICATIONS,LOCK_TASK_FEATURE_GLOBAL_ACTIONSandLOCK_TASK_FEATURE_KEYGUARDre-enable them; Overview and notifications also require the Home flag. - Verify the result on the device. Exercise navigation, notifications, external links, share menus and every companion-app handoff the workflow needs.
A multi-app kiosk needs a deliberate way to move between approved apps. Adding packages to an allowlist does not design that navigation. Test the launcher and each return path, including the route back after sign-in or a peripheral operation. Android blocks an activity from an app outside the allowlist when it would open in a new task, but an activity launched into the current task can still appear; on Android 11 or higher, LOCK_TASK_FEATURE_BLOCK_ACTIVITY_START_IN_TASK blocks those too. Check that neither case strands the user.
Add device restrictions
Lock task mode limits navigation. Pair it with user restrictions that close the remaining exits, for example DISALLOW_SAFE_BOOT, DISALLOW_FACTORY_RESET, DISALLOW_ADD_USER and DISALLOW_CREATE_WINDOWS, which stops other apps drawing windows over the kiosk. Evaluate each one against legitimate accessibility and support needs. A system update policy set with setSystemUpdatePolicy() keeps OS updates inside a maintenance window.
| Configuration choice | Test before wider assignment |
|---|---|
| Single main app | Restart and app relaunch return to the intended usable screen |
| Approved app set | Every allowed handoff works without exposing unrelated apps |
| System UI features | Users can complete the task without an escape into general settings |
| Network configuration | The device reconnects without opening broad administrative access |
| Maintenance procedure | Authorised recovery works and ordinary users cannot invoke it |
Locking navigation is not a substitute for application security or a device-wide malware verdict.
Keep iOS separate. Guided Access is a feature the device user turns on to stay in one app. Apple’s App Lock payload, on supervised devices, keeps the device in a specified app and returns to it after restart. Both are Apple mechanisms with their own tests.
Recovery: administrator access, restart and lost connectivity
Test recovery while the pilot is physically within reach. Record the policy revision and the device’s actual state before and after every exercise. A command sent by the management service is not evidence that an offline device applied it.
Otukan keeps kiosk policy enforced while a device is offline and applies queued commands when it reconnects. It provides a remote kiosk exit from the console and a protected local administrator exit.
On the platform side, the DPC ends lock task mode for an app by removing it from the allowlist, and an app in lock task mode can call stopLockTask(). Test that exit path on each Android release in your fleet, and do not assume a remote change can reach a disconnected device.
Rehearse the operational failures
- Restart the device and confirm the kiosk app returns without an unrestricted interval on the stock launcher.
- Interrupt connectivity and verify the agreed offline workflow and visible error state.
- Restore connectivity and reconcile the intended policy with the applied state.
- Exercise an app crash, a failed launch and an interrupted app update without losing the recovery path.
- Test administrator maintenance access and the return to kiosk restrictions.
- Attempt the same exit actions as an ordinary user and confirm they are blocked.
Repeat install, update, sign-in and the main workflow with both the kiosk policy and the unrestricted baseline. Include peripherals and accessibility tools in that baseline rather than treating them as accidental exceptions.
Escalate an unrecoverable device to the agreed physical-support procedure. A destructive reset needs explicit authority and a restoration plan. Close the acceptance record with device versions, expected results, observed behaviour and the fleet operations reviewer.
Further reading
- Lock task mode — Android Developers
- Dedicated devices overview — Android Developers
- DevicePolicyManager — Android API reference
- AppLock — Apple Device Management