A shared Android handheld is ready for the next person only when access, user data and unfinished work have a defined outcome. A locked-down home screen can restrict which apps run, but it does not by itself prove that the previous operator signed out, that cached records disappeared or that a pending transaction reached the business system.
Imagine an operator finishing a stock movement as the shift changes. The screen shows a completed scan, a background upload is unresolved, and a second app still displays the operator's name. The next worker picks up the same device. This is an editorial scenario, not a customer incident or an AIDC GO test. It exposes three separate handover questions: who can use the device, whose data is visible, and who owns the unfinished movement.
Separate the launcher, the application user and the business record
Ask the project team to describe each layer using the proposed app and management setup. “Kiosk mode” may mean an allowed-app experience. “Log out” may refer to one application, an identity provider or an Android user. “Clear data” may mean removing a displayed record, deleting local files or destroying a user's whole local working area. Those actions are not interchangeable.
Android's lock task mode documentation describes restricting a dedicated device to an allowlisted app or set of apps under a device policy controller. Platform version and management context affect the available controls. This is an app-access mechanism, not an assurance that business sessions and offline records are cleared at a shift boundary.
The application's accepted transaction is a separate record again. Signing out locally must not be described as reversing an accepted stock movement. Conversely, a scan remaining on screen is not proof of acceptance. Keep the detailed retry and unknown-result rules in the existing offline barcode capture guide; here the decision is how handover preserves accountability for that work.
Choose the handover mechanism around the actual applications
A team using one business app may rely on that app's own controlled sign-out and next-user sign-in. A team using several supported identity-integrated apps may evaluate a coordinated sign-out mechanism. A separate Android-user design is another option, not a synonym for either of those approaches. Do not select a mechanism from the word “shared” alone.
Microsoft's shared device mode for Android illustrates the application dependency. Its documented Android 8.0-or-later scenario requires device preparation and supported single-account applications. The sign-out flow removes account and cached token information in that setup, but application developers must still clear their own data and displayed cached content. An unsupported application does not acquire those behaviours just because it is installed beside a supported one.
Android's multiple-user management guide describes persistent secondary users and ephemeral users whose local user environment is removed when the user stops, switches away or the device reboots. Multi-user support is optional and device limits apply; the management workflow generally requires Android 9.0. Confirm the exact implementation and version rather than inferring support from an Android logo.
These platform examples are alternatives to assess with the application and management providers. They do not establish that a particular AIDC GO handheld supplies a management licence, supports a named shared-device mode or automatically deletes user information. A destructive cleanup method is also a poor substitute for resolving a record that still needs to be submitted.
Walk through one shift change before choosing a policy
Use a non-production test account and a controlled task representing the real workflow. The table below describes proposed observations, not tests that AIDC GO has executed. Agree on the expected outcome before running them, including who may authorise cleanup or task reassignment.
| Handover moment | Observation in the proposed workflow | Decision that must be explicit |
|---|---|---|
| Operator ends the shift | Check the visible task state and any pending local or server-side work before sign-out. | Identify whether the operator finishes, parks or escalates the task, and who can take responsibility next. |
| Application signs out | Reopen each relevant app and check identity, displayed records and access to earlier information. | Define which applications participate, which local data must be removed and how completion is confirmed. |
| Device returns to the pool | Check whether the device is in a known ready state or still requires attention. | Prevent an unresolved handover from being represented as ready merely because the launcher is visible. |
| Next operator signs in | Confirm the new account, permitted tasks and the ownership of any resumed work. | Keep the previous operator's identity out of new actions unless the application has an explicit, auditable delegation rule. |
In the opening example, the movement can be placed in a visible exception state with a named owner while its result is resolved, if the business application supports that process. That is a design choice, not a universal Android feature. Do not silently reassign the queued operation to the next operator simply because the device is now in their hands.
Avoid treating a blank screen as proof of data removal. An app might display its sign-in page while another screen, export, attachment or independently authenticated app remains accessible. The evaluation should cover the routes the next user can actually reach under the deployed policy, not only the main screen seen in a demonstration.
Include interruption and recovery in the handover exercise
Repeat the agreed handover with connectivity unavailable, then restored. Observe whether sign-out requires a network service, what the operator sees while it waits, and what the next user can access. Keep the original task identity and ownership visible in the test record. A reconnection is not evidence that every queued operation has been accepted.
Also check the relevant apps after they move to the background and return, and after a controlled device restart. These are proposed evaluation conditions, not guarantees that a restart clears sessions. Microsoft specifically makes app lifecycle handling and cached-data cleanup part of a shared-mode application's work; the buyer should ask for evidence from the actual app versions.
For every interruption, record the management policy revision, Android build, application version, account type and observed result. “The device was reset” is too vague: an app restart, an Android-user switch and a device wipe have very different consequences. Do not use a wipe or erase local task data on working equipment as an exploratory handover test.
Connect device selection to a supported operating arrangement
Compare the hardware candidates through the handheld terminals category, then identify which Android build and configuration the proposed application and management provider support. The mobile-computer versus barcode-scanner comparison can help establish where the application and user session actually run when an external scanning device is involved.
Prepare a simple sequence showing sign-in, task completion or escalation, sign-out, device return and next-user access. List all participating applications, including browser-based tools and any second app that handles attachments or dispatch information. Attach the intended management policy and specify the states that should prevent a device from being handed over as ready.
Bring model, operating-system, interface and document-version questions to Integration Support. The application and identity teams remain responsible for session behaviour, record ownership and data-cleanup rules. Device configuration and application support need to be evaluated together; neither a kiosk demonstration nor a generic Android feature list is a complete handover acceptance result.
When you contact AIDC GO, include the proposed model, deployment country, application and management versions, and the handover sequence. That gives the discussion a concrete starting point without assuming an unconfirmed MDM service, automatic session clearing or support for every shared-device implementation.