A spare rugged device is useful only when it can take over the intended job. A charged unit on a shelf may still have the wrong operating-system build, a missing application profile, an unapproved accessory set or no clear path for resuming work. Plan the spare pool as a controlled working configuration, not simply as extra hardware.
This guide is for operations, IT and procurement teams planning replacement handhelds or tablets. It explains how to define readiness, compare spare-pool arrangements and record the evidence needed before a replacement is issued. It does not prescribe a universal spare percentage or promise a repair time.
Define the job that a spare must take over
Start with the role, not the device count. Name the task that may be interrupted, the application involved, the data that must be preserved and the accessories needed at the work point. A receiving handheld, a vehicle-mounted tablet and a supervisor's inspection device may require different replacement states even when they belong to the same product family.
Record whether the spare must replace one named configuration or several approved configurations. The Rugged Handheld Terminals and Rugged Tablets pages can help identify the current product direction, but family membership does not establish that applications, batteries, docks, cables or settings are interchangeable.
Separate two questions. First, can the replacement hardware perform the physical task? Second, can the managed device enter the approved application state? A spare can pass the first question and still fail the second because enrollment, permissions, network profiles or application data are missing.
Build a ready-state record for each approved configuration
A useful ready-state record identifies the exact model and regional configuration, operating-system and security-patch level, application build, management or provisioning state, network profile, assigned peripherals, power state and storage location. Add the date and person or system that last verified it.
Google's Android Management API provisioning documentation explains that provisioning binds a managed device to an enterprise and applies policies and applications according to the chosen management mode. This supports the general point that an enterprise replacement can require more than installing an app. It does not prove that an AIDC GO configuration includes Android Enterprise, an EMM service or a particular enrollment method.
For one vendor-specific example, Zebra's StageNow 5.21 profile documentation describes profiles that contain configuration settings and can be reviewed, published and delivered to supported Zebra devices. Treat that as evidence for the named Zebra tooling only. The project should identify its own approved provisioning method and preserve the versioned package or policy reference used for each spare.
Follow an editorial replacement event from shelf to resumed task
Consider an editorial warehouse example. A picking handheld is removed after a damaged connector is found. The nearest shelf spare is fully charged, but its application build is one release behind and its holster does not fit the worker's cart station. A second spare has the approved build, network profile and accessory set.
The team should not issue the first device merely because it powers on. It should verify the second device's asset identity, build, application profile, authentication path and physical accessories against the role record. The operator then signs into the approved application path and resumes only after the application identifies the correct task or an authorised recovery process resolves the pending state.
Battery readiness belongs in this event, but it is not the whole event. Use Handheld Battery Swaps and Shift Charging for battery rotation. Use Shared Android Handheld Handover for user sign-out and session transfer. The spare-pool record owns the replacement unit's complete approved configuration.
Compare spare arrangements by what they can actually cover
| Spare arrangement | What it can cover when verified | Limit that remains |
|---|---|---|
| One ready spare for one named configuration | A documented replacement path for that model, build, application and accessory set | It does not establish coverage for another model, region, dock, battery or application version. |
| Shared spare across several roles | A smaller pool when one exact configuration has been validated for each listed role | It does not establish interchangeability where roles require different peripherals, policies or screen layouts. |
| Unconfigured stock held for later setup | Hardware availability before a need is assigned | It does not establish that provisioning, licensing, updates and accessories can be completed within the interruption window. |
| Rotating operational unit used as a spare | A device that is already exercised in normal work under a controlled rotation | It does not establish that its user data, task state and physical condition are ready for another role without a release check. |
Do not choose a ratio from an industry anecdote. Estimate coverage from the number of distinct approved configurations, acceptable interruption, replacement preparation time, repair process and any single accessories that can block the handover. State those inputs rather than turning them into an unsupported universal formula.
Control build, update and accessory drift
A spare that is rarely used can drift away from the active fleet. Decide how the team will detect an old operating-system build, expired credential, missing application release or changed configuration profile before the device is needed. Keep an evidence date and a clear action for a failed readiness check.
Android's system-update management guidance shows that update control depends on device-owner or profile-owner capabilities and that pending updates can remain for operational reasons such as connectivity, storage or battery state. Zebra's LifeGuard documentation is a separate vendor example for supported Zebra Android devices. Neither source establishes the update service, support period or release channel for an AIDC GO model.
Accessory drift matters as much as software drift. Record the exact cradle, cable, battery, trigger or mount expected by the role and confirm the combination against current model documentation. Do not assume that a visually similar connector or a family-level accessory page proves fit. If the spare must move between sites or countries, confirm the regional hardware, power and radio configuration as part of the same record.
Ask for evidence that closes the replacement path
Before ordering or allocating spares, provide the role list, candidate model and configuration, deployment country, application and version, management method, network requirements, approved build, accessory bill of materials, charging location and acceptable interruption. Identify how a pending transaction or local record is recovered when the original unit is unavailable.
Use Integration & Support to frame model-, configuration- and version-specific questions. If a task may remain unconfirmed during a device loss, review Offline Barcode Capture and Unconfirmed Transactions with the application owner; the device alone cannot decide whether the backend accepted a transaction.
Ask AIDC GO to confirm only the product and documentation applicable to the proposed configuration. Then contact AIDC GO with the required role, quantity, country, application context and open accessory questions. A defensible spare plan links each ready unit to a bounded role and a repeatable verification record. It does not turn stocked hardware into an assumed service level.