Custom Launcher vs Kiosk Mode vs MDM: Which Layer Do You Need?

The Short Answer

These three terms describe different layers of the same stack, not competing products. A custom launcher changes the user interface — the home screen a person sees and how they move around the device. Kiosk mode restricts the device to one task or a defined set of apps, using lock task mode on a device that has a device policy controller (DPC) set as device owner. MDM or EMM is the fleet-policy layer that enrols devices, pushes and changes policy, distributes apps and reports compliance. A fourth layer sits underneath all three: system-level OEM integration, reached through OEMConfig, vendor administration APIs or firmware work, which is where controls live that the public policy API does not expose. Most programs use several layers at once, so the useful question is not which one to choose but which layer each individual requirement belongs to — and whether that layer can enforce the requirement or merely display it. A second question follows immediately, and is answered further down this page: whether the resulting configuration is written into the device once at staging or kept under ongoing remote management for the life of the fleet.

Four Control Layers, Not Three Products

Requirements arrive as sentences — "it should only run our app", "it must look like our product", "we need to change the allowlist later", "users must not reach settings". Each of those sentences belongs to a different layer, and the failure mode in most device projects is a requirement placed on a layer that cannot enforce it. The experience layer is the launcher: what the screen shows and where taps go. The task-restriction layer is lock task mode: which app the device is pinned to and which system UI elements remain reachable. The fleet-policy layer is the DPC and the management platform behind it: enrolment, user restrictions, app distribution, remote commands and reporting. The system layer is whatever the OEM exposes beyond the standard policy surface — scanner and key-remapping frameworks, silent firmware update control, privileged app permissions, persistence across resets. Mapping which control belongs to Android Enterprise, the EMM, the OEM or a launcher is exactly what the OEM/MDM Dependency Matrix is for, and the choice of whether to reach for the system layer at all is the subject of MDM vs custom Android ROM. Ordering matters: the lightest layer that can enforce a requirement is normally the right one, because each step down costs validation time, narrows the device shortlist and adds revalidation triggers.

• Experience layer — custom launcher: what the user sees and how they navigate
• Task-restriction layer — lock task / kiosk: which app the device is held in
• Fleet-policy layer — DPC as device owner plus the EMM console: what is allowed and what changes
• System layer — OEM integration, OEMConfig or firmware: controls the public policy API does not expose

What a Custom Launcher Changes

A custom launcher replaces the default home application to reshape the surface a user lands on — the app icons on show, the navigation between them, the branding and the first content entry point. It is an experience layer: it controls what the device looks and feels like rather than what it is technically permitted to do. Under a device-owner configuration the DPC can set the launcher as the persistent preferred handler for the home intent, so it is applied at provisioning rather than left to the user to pick, and no chooser dialogue appears at first boot. That single detail is what separates a deployable launcher from one a user can walk away from. A launcher can also carry legitimate operational value beyond branding — a shift-start checklist, a single large action button for gloved use, a status strip showing sync state or battery health, a language default that matches the site rather than the account. What a launcher cannot do is stop anything. It renders a smaller set of choices; it does not remove the underlying ones. Every restriction that must survive a determined or simply curious user has to be expressed on the policy layer, and then confirmed on the sample rather than assumed from the screenshot.

• A branded home screen with a curated set of app icons
• Navigation and a content entry point shaped around the workflow
• Set as the default home handler at provisioning by the DPC, not chosen by the user
• Experience and branding only — not a control boundary on its own

What Kiosk Mode and Lock Task Actually Control

Kiosk mode is the operational name for lock task mode, a framework capability granted by a device owner — or, on affiliated users and profiles from Android 9 onward, by a profile owner, though corporate-owned dedicated hardware is normally provisioned into device owner regardless. The DPC allowlists the packages permitted to enter lock task, and the device is then held inside that app either because the application itself enters the mode or because the management platform applies a kiosk configuration on its behalf; Google documents the mechanism under lock task mode for dedicated devices. Alongside the pinning itself, the policy selects which lock task features remain available — the home and overview buttons, the notification shade, the global actions menu, the keyguard, system information in the status bar. A single-app kiosk suits a device that does one thing; a multi-app configuration presents a managed home surface across a defined set of approved apps, which the Android Management API expresses as a kiosk install type or a managed kiosk launcher depending on the shape required. Two limits are worth stating early. Lock task blocks activities belonging to packages outside the allowlist, but it does not police what happens inside an allowlisted app, so an embedded web view, a document renderer or a help screen can still expose navigation the policy did not intend — and if a system handler such as the document picker is permitted so the workflow can function, whatever that handler reaches becomes reachable too. And lock task is a property of the managed mode the device is enrolled in — the mode itself is a separate decision, covered in dedicated vs fully managed Android devices. These restrictions are configurable for MDM/EMM and remain subject to technical validation on the chosen hardware and build.

• Single-app kiosk for a dedicated, one-task device
• Multi-app kiosk for a defined set of approved apps behind a managed home surface
• Lock task features decide which system UI elements stay reachable
• Intents raised from inside an allowed app are the usual escape route to test

What the Fleet-Policy Layer Adds

MDM or EMM operates at fleet scale. It enrols devices through an agreed provisioning route, applies user restrictions and configuration profiles, distributes and updates applications, delivers managed configuration to apps that publish one, reports inventory and compliance, and issues remote commands such as lock, reboot or password reset. Where a launcher and a kiosk policy shape a single device, the fleet-policy layer is how that state is applied to hundreds of units and kept current afterwards. Most hard restrictions live here rather than anywhere else: blocking installation from unknown sources, disabling safe-mode boot, preventing a user-initiated factory reset, restricting which settings a user may change, controlling debugging access. Application-level restriction usually lives here too — a browser that publishes a managed configuration can be handed an allowlist or blocklist by the EMM, but only for the fields its developer actually exposed, which is why browser restriction is one of the first things to test rather than promise. The available depth is OEM- and platform-dependent and differs between management platforms, so a control that is documented for the API is not automatically present in the console you have licensed, on the build you have bought.

• Enrolment through an agreed provisioning route, then policy applied at each check-in
• User restrictions: unknown sources, safe boot, factory reset, settings scope, debugging
• App distribution, version control and managed configuration delivery
• Inventory, compliance state and remote commands such as lock or reboot

What Only System-Level Integration Adds

Some requirements do not resolve on any of the three layers above, because the control is not part of the standard Android Enterprise policy surface. Typical examples are hardware key remapping, scanner and RFID trigger behaviour, granting a private application a privileged permission, holding a firmware version still while the rest of the fleet updates, controlling a charging dock or a peripheral bus, or keeping a configuration through a reset. These sit with the OEM, and are reached through OEMConfig — a vendor-published managed configuration schema delivered by a standard EMM — through a vendor administration SDK used by a custom agent, or through firmware work at the platform level. The practical consequence for a device project is that this layer narrows the device shortlist before anything else does: the requirement stops being "an Android tablet" and becomes "an Android tablet from a vendor that exposes this control on this build". It also introduces a maintenance obligation, because vendor frameworks version independently of Android itself. Treat system-level work as a deliberate escalation with a named owner, taken only when a requirement genuinely cannot be met above it, and record it as a known limitation with a revalidation trigger rather than as a solved item.

• OEMConfig — vendor settings pushed through a standard EMM without a custom agent
• Vendor administration SDKs — used by a custom agent where OEMConfig does not reach
• Firmware or platform work — the heaviest and least portable option
• Escalate deliberately: this layer narrows the device shortlist and adds revalidation triggers

Static Policy vs Remotely Managed: The Second Axis

Choosing layers answers what is controlled. A second, independent question decides how that control is maintained: is the policy written into the device once during staging, or is the device kept under ongoing remote management for its working life? Both are legitimate designs, and the wrong assumption here is expensive in a way that only shows up months after delivery. A statically configured device carries its accepted state from the staging bench. Provisioning applies the launcher, the lock task configuration, the app set and the restrictions; the device then operates without a standing management relationship. Nothing needs to check in, nothing needs a licence to keep working, and no console needs an administrator. The cost lands on change: a new allowlist entry, an updated app or a corrected setting means re-staging, a returned unit or a site visit, and that cost multiplies by every unit in the field. A remotely managed device keeps a live relationship with an EMM tenant. Policy is versioned centrally and applied at the next check-in, apps are updated in place, compliance is visible, and a lost device can be locked. The cost lands on dependence: the design assumes a network path, an active subscription, and a named person who owns the tenant after handover. That last point is the one most often left unassigned. The tenant is bound to an enterprise identity, and somebody has to hold the administrator credentials, renew the licences, approve applications and respond when a device drops out of compliance. If that owner is not named before batch approval, the fleet becomes unmanageable at exactly the moment management is needed. The offline case deserves an explicit answer rather than an assumption. A device that never checks in does not lose its policy — it keeps the last state it successfully applied and continues to run. What it loses is every subsequent change: new policy, app updates, revoked access and remote commands all queue and never arrive, and the console shows a stale last-seen timestamp that can be mistaken for a healthy device. Programs with genuinely disconnected sites often end up with a hybrid: a static baseline strong enough to be operationally correct on its own, plus enrolment that adds central management wherever connectivity exists. That hybrid has to be a stated design with an agreed offline window, not an accident discovered during the first policy change.

Why a Launcher Alone Is Not a Control Boundary

A custom launcher installed without device-owner policy behind it can usually be left behind. A user may reach the stock interface through safe mode, through a settings path that changes the default home application, through an intent raised by an allowed app, or through a factory reset — because the launcher paints a surface rather than removing a capability. Enforcement comes from the device-owner layer and the OEM APIs it exposes: the user restrictions that block safe boot and unknown sources, the lock task configuration that decides which system UI survives, the reset policy that decides whether a user may wipe the device at all. Non-circumvention is a property of the policy layer, not of the home screen. This distinction is worth writing into the requirements document in plain terms, because "locked down" means something very different to a designer and to an administrator. In practice the honest formulation is a pair: the launcher defines the intended path, and the policy layer closes the unintended ones. Both are then tested, and the ones that cannot be closed on the chosen hardware are recorded as accepted exceptions rather than quietly omitted.

• A launcher without device-owner policy can be bypassed via safe mode or a settings path
• A plain factory reset removes the device owner and drops the device to the stock interface
• Enforced restrictions live in the device-owner, user-restriction and OEM API layer
• The launcher defines the intended path; policy closes the unintended ones

Common Combined Architectures

In practice the layers stack, and a small number of combinations cover most deployments. A launcher plus fleet policy gives a branded surface that is also centrally managed and updatable — the usual shape for a customer-facing or field workforce device. Lock task plus a privately distributed application produces a dedicated device for a single workflow, with the launcher role effectively absorbed by the pinned app. OEMConfig pushes vendor settings through the standard EMM where a hardware behaviour needs to change but a custom agent would be disproportionate. A custom agent closes gaps the public policy API leaves, at the cost of a maintenance obligation. And a statically staged baseline, with or without later enrolment, covers fleets that will not have a reliable network path. None of these is a product tier; they are combinations chosen requirement by requirement, and a program can contain more than one — a single deployment often mixes a fully locked variant for shared-shift devices with a lighter configuration for supervisors.

• Launcher plus fleet policy: a branded surface that is centrally managed
• Lock task plus a private app: a dedicated, single-workflow device
• OEMConfig: vendor settings pushed through a standard EMM
• Custom agent: closing gaps the public policy API does not cover
• Static staged baseline: an accepted state that holds without a management connection

Requirement-to-Layer Decision Matrix

Mapping each requirement to a layer keeps the build proportionate and makes the acceptance conversation concrete: for every line below there is a mechanism that enforces it and a test that shows it held. The table is indicative — the enforcement route for a specific model, Android version, management platform and application is settled during validation and recorded before any commitment, because the same requirement can land on different layers depending on what the chosen hardware exposes.

Proving Each Layer on the Version-Controlled Sample

A layer map is a hypothesis until a sample tests it. The version-controlled sample is the unit that fixes the exact model and regional SKU, Android version and firmware build, application package and version, policy version and provisioning route — so that every claim below is attached to something reproducible rather than to a device family. Each layer produces a different kind of evidence, and confusing them is how a project arrives at a batch with an unpleasant surprise. A launcher-only claim, tested honestly, looks like this: the branded home screen appears, the icons are correct, and then a tester opens the notification shade, taps through to settings, changes the default home application, boots into safe mode and performs a factory reset. If those paths lead anywhere the requirement forbids, the requirement was never on the launcher layer — it belongs to policy, and the acceptance matrix records the mechanism, not the appearance. Task-restriction evidence is behavioural and adversarial by design. The sample is not proved by the app opening; it is proved by the app staying open through reboot, an incoming call, a notification, a charger disconnect, an update, a forced stop and a low-battery shutdown — and by an approved supervisor exit route that works for staff without becoming a general bypass. Bypass testing belongs in the acceptance matrix as named scenarios with pass, fail or conditional results, because these are the paths a real user finds in the first fortnight: safe-mode boot, the settings deep link, the share sheet, a file picker inside an allowed app, download handlers, an embedded web view that follows an external link, accessibility services, USB debugging, and the factory reset itself. Fleet-policy evidence is console evidence plus a change test: the device appears with the expected identity and build, the policy version that was approved is the one applied, and a deliberate policy change is published and observed reaching the device within the agreed window. System-layer evidence is the narrowest and the most model-specific — a vendor control either works on this build or it does not, and the result is tied to a firmware version that can move. Everything that cannot be closed is written down rather than dropped: the known-limitations library exists so that residual escape paths, conditional passes and dependency owners stay visible to the approver. The structure of the results themselves — scenario, expected behaviour, observed behaviour, verdict, owner — follows the sample acceptance matrix. Batch staging then reproduces the accepted state rather than reinventing it: the same provisioning route, the same policy version, the same app build, checked unit by unit against the reference sample with a stop rule when a unit deviates. That is what turns a working sample into a program, typically quoted from around 500 units upward, with a pilot tranche of twenty to a hundred devices inside the program used to confirm the layer decisions in real conditions before the remaining units are staged.

• Tie every layer claim to one version-controlled sample — model, SKU, build, app, policy, provisioning route
• Test the launcher by trying to leave it: shade, settings, default-home change, safe mode, factory reset
• Record bypass scenarios in the acceptance matrix with pass, fail or conditional verdicts and a named owner
• Prove fleet policy with a real change: publish a policy version and observe it arrive within the agreed window
• Reproduce, do not reinvent — batch staging repeats the accepted state and stops when a unit deviates

Known Limitations of the Layer Model

The layer model is a planning tool, not a guarantee, and it is worth stating where it stops being tidy. Layers are not perfectly separable in practice: a lock task configuration can change how a launcher behaves, an application update can move a control from the app layer to the policy layer, and an OEM implementation can differ from the documented framework behaviour on the same Android version. Availability is OEM-, Android-version-, EMM- and hardware-dependent throughout, so a control confirmed on one model is not confirmed on its successor.

• Managed configuration only exposes fields the application developer published — an EMM cannot invent them.
• Lock task blocks packages outside the allowlist, not navigation inside an allowed app; web views and permitted system handlers stay the usual escape route.
• A standard factory reset removes the device owner; persistence depends on the provisioning route and on OEM behaviour that must be confirmed per model.
• Remote actions require the device to receive and execute the command; offline or damaged units need a separate recovery path.
• Firmware and application updates can move behaviour across layers and should trigger revalidation rather than an assumption of continuity.
• Console documentation describes platform capability, not the licensed feature set on your tenant or the behaviour on your exact build.

Decide the Layer Before You Decide the Device

The cheapest moment to correct a layer decision is before hardware is selected, because the layer determines the shortlist far more than the specification sheet does. A requirement that resolves on standard Android Enterprise policy keeps the device choice wide; one that needs a vendor administration framework narrows it to a handful of models and adds a maintenance obligation. Bring the requirement list rather than a product idea: what the user must see, what the device must be prevented from doing, what will need to change after delivery, whether the fleet will have connectivity, who will hold the management tenant, and the quantity range under discussion. Vantora maps each line onto the experience, task-restriction, fleet-policy and system layers, states which are enforced and which are appearance, and records the residual limitations before anything is committed — the sequence of checkpoints is set out in how a validated Android device rollout works, and the integration work itself in App, MDM and Kiosk Integration.