Restricting a handheld to approved work screens can reduce accidental exits, but a locked-down home screen is not proof that the job can be completed. A warehouse task may need a scanner input, an exception photo, a document viewer, a sign-in screen and a reliable way back to the original task. The buyer's test is whether that whole route remains usable on the actual Android build, application release and management configuration.
This is a workflow decision, not a promise that an AIDC GO model includes a particular device-management service. Start with the real application map and the approved device configuration, then test the steps an operator must finish.
Identify which kind of restriction is proposed
Android lock task mode is a dedicated-device mechanism in which a device policy controller (DPC) allowlists packages that may run. Google's guide distinguishes it from screen pinning: screen pinning looks similar, but the person holding the device can exit it. An enterprise mobility management (EMM) product may provide its own Kiosk settings on top of Android policy. Ask what it actually configures, which Android and management modes it supports, and how its application policy maps to the task—not simply whether a brochure says “Kiosk.”
One work app may contain the task screen, scanning integration, camera capture and attachment review within its own package. Another deployment may deliberately use a separate camera, document or identity application. Google's lock task guidance allows a single app or a set of allowlisted apps; it also notes that activity and task behavior matter. A separate visible app may need approval, whereas a background service is not automatically another user-facing app that should be placed on an allowlist. The integrator should trace the actual activities and packages in the chosen build.
Walk an approved task through every screen
Consider this editorial example, not a customer test. An operator opens picking task P-218, scans an item, sees a damaged carton, takes a photo, returns to P-218 and submits the exception. In a single-app design, the photo screen may be an activity inside the work app. In a multi-app design, the work app may launch a separate camera and receive a result. The procurement question is whether the selected restriction permits that exact handoff and restores the task with its scanned item and unsent exception intact.
Test the actual scan route, whether it uses the application's own scan control or a documented external input path. Then check camera permission, file or image access, the return action and the application's handling of a cancelled capture. A successful photo does not prove that the photo was attached to the correct task; the submitted record needs to show the intended item and exception. If a file viewer is required for an instruction, repeat the same test with that viewer. Do not allow every installed app merely to make a failed transition disappear.
For one-app operation, the cleanest acceptance result is that the approved app completes the whole cycle without exposing unintended exits. For a multi-app cycle, list each visible transition and its return target, then confirm that the management policy and the application both support it. The decision is based on the required workflow, not on a general ranking of one-app against multi-app Kiosk.
Test interruption and the controlled way out
Repeat the same task after a device restart, a work-app crash and a sign-in expiry. Check whether the device reaches an approved launcher or work screen, whether unfinished work is shown accurately, and whether the operator can authenticate without escaping into an unrestricted setting. A restriction policy does not save an application's pending transaction by itself; the application and backend must define recovery. If work was submitted just before a crash, verify its result before creating another transaction. The offline transaction guide covers that separate data-integrity question.
The administrator also needs a documented maintenance route: identify who may pause the restriction, update or replace the work app, collect diagnostics and restore the approved state. Google's lock task documentation describes policy and exit mechanisms with Android-version differences; the exact EMM controls must be validated in the selected management product. A device that operators cannot exit may still be unsuitable if authorized staff cannot recover it after an application failure.
Keep UI restriction separate from account and data controls
A Kiosk policy governs which screens or apps the device can expose. It does not establish that the previous worker signed out, that a new worker has the correct role, or that locally held data has been cleared. Those are application, identity and data-policy decisions. The shared-device handover guide addresses pending work and the next user; the Android Enterprise enrollment guide addresses ownership and provisioning. System updates and application validation have their own release path. None substitutes for testing this allowed application chain.
For purchasing, document the Android build, DPC/EMM product and version, allowlisted packages, application build, scan path, photo path, sign-in method and administrator recovery method. Demonstrate the editorial task with the buyer's real app and a deliberately interrupted task before treating the setup as deployable. Browse the handheld terminal range for device options, and use Integration Support to confirm the exact software and configuration evidence required. A device category page is not proof of Android Enterprise certification, a supplied EMM service or compatibility with an untested application.