A rugged handheld or tablet can have the right radio, scanner and application package yet still be unusable because it was enrolled under the wrong ownership model or cannot be returned to an approved state. The purchasing decision therefore includes more than asking whether a device “supports MDM.” It must define who owns the device, how the first policy arrives, what the user is allowed to change and what happens when the device is reassigned or retired.
This guide turns those decisions into a deployment record that an integrator, IT owner and hardware supplier can review together.
Start with the ownership and work pattern
Identify whether the device is company-owned for general work, company-owned for a dedicated task, or personally owned with a managed work profile. Google’s Android Management API provisioning guide treats these as different management scenarios and provisioning paths; the same QR code or enrollment step should not be assumed to produce every mode.
For a proposed handheld terminal or rugged tablet, describe the actual operator pattern. A shared warehouse device that opens one picking application has a different handover and reset requirement from a field tablet assigned to one technician. Record who owns the hardware, who administers it and whether users may add accounts or applications.
Select the enrollment path before the rollout date
Android Enterprise can be provisioned through methods such as an enrollment token, QR code, NFC or zero-touch enrollment, depending on the management scenario and supported environment. The named method must be tested with the exact Android build and management product. A label saying “Android Enterprise” does not prove that every enrollment path is exposed on every device configuration.
Zero-touch adds another chain of responsibility. Google’s zero-touch overview describes a reseller assigning a device to a customer and the customer applying a configuration that the device retrieves during setup. Before ordering, confirm who will register the serial numbers, which customer account receives them, and what the field team should see after a factory reset.
Separate enrollment success from work readiness
Enrollment proves that the device joined the intended management context. It does not prove that the scanner profile, certificates, application version, permissions or backend access are ready. The enterprise Wi-Fi identity can be checked with the EAP and certificate guide, while application and interface questions belong in a model-specific request to Integration Support.
Enrollment and policy delivery do not by themselves establish an approved boot trust chain. Separately define the accepted root of trust and image-update path using the rugged Android Verified Boot procurement guide.
Use a named build record: hardware model and configuration, Android version, enrollment method, management policy version, installed application version and approved accessories. That record becomes the comparison point for a replacement device rather than a general screenshot saying “enrolled.”
Make the state transitions observable
The table separates four states that are often compressed into one deployment checkbox.
| Observed state | What it can establish | What it does not establish |
|---|---|---|
| Device is assigned in a zero-touch portal | The recorded identifier is associated with the intended customer configuration | The device has completed setup or received the current policy |
| Enrollment screen completes | The tested enrollment route accepted the device | Required applications, permissions and network identities are not yet proven |
| Target application opens and a controlled task completes | The tested build can perform that task under the observed conditions | Recovery, reassignment and every peripheral path remain separate tests |
| Device is wiped or relinquished | The requested management action reached a defined end state | Local business records, external accounts and asset registers are not automatically reconciled |
Keep the portal record, device status and application evidence separate. This avoids treating a management-console entry as proof that a device is physically ready for work.
Test a replacement from reset to controlled work
Consider an editorial example: a company-owned spare is reset after a primary handheld fails. The spare appears in the enrollment portal, downloads the approved configuration and installs the picking application. The operator then signs in, scans a controlled label and completes one non-production test task. The team records the policy version and confirms that the device returns to the shared-device sign-in screen at handover.
This sequence complements the spare-device pool guide and the shared Android handover guide. It is an evaluation method, not evidence that a particular AIDC GO model supports a named management product, enrollment route or automated sign-out feature.
Define wipe, relinquishment and reuse separately
Google’s deprovisioning documentation distinguishes wipe operations from relinquishing ownership on supported company-owned work-profile devices. The resulting behavior depends on management mode and command options. Procurement should therefore ask what state the exact device reaches, which local data remains, and whether the device returns to an enrollment screen or an unmanaged personal state.
Also define the external records that a device command cannot settle by itself: asset assignment, SIM or service ownership, application accounts, certificates and repair status. A successful wipe response is not a complete retirement certificate unless the organization’s other records are closed as well.
Send one complete enrollment question to the supplier
Provide the exact model and configuration, Android build, intended ownership mode, management product, enrollment path, network identity method, required applications, peripheral dependencies and reset/reassignment outcome. Include the destination country and expected provisioning owner so regional configuration and service questions are visible.
AIDC GO can compare available hardware fields and route a concrete request through Contact. The customer’s IT or management-platform owner remains responsible for policy design, enrollment credentials, user accounts and the decision to wipe or reassign a device.