A microSD slot does not by itself prove that a rugged Android handheld can keep the business application’s offline queue on a removable card. First establish the exact device and OS build, whether the slot and its intended storage mode are supported, and where that specific app writes each dataset. Then test card removal, device replacement, sync and recovery. Capacity, portable storage and adopted storage answer different questions.
The RAM and storage sizing guide estimates capacity and update headroom. This article addresses the architecture and failure boundary of removable media. It does not claim that any current AIDC GO model exposes a microSD slot, adoptable storage or a particular application data path.
Separate the card, its mode and the application’s files
Confirm the model’s actual slot, supported card requirements and device policy with model-specific documentation. Android’s storage overview distinguishes portable and adoptable media. Portable storage is removable file storage; that does not mean an app’s private database or unsent transactions are automatically copied there. Android’s app-specific storage guidance also warns that files on removable external storage become unavailable when the media is removed. In Android terminology, “external storage” may be emulated rather than a physical card, so inspect the resolved location in the target app instead of guessing from an API name.
Android’s AOSP adoptable-storage guidance says adopted media is formatted and encrypted for one device, and an app can be placed there only under applicable app and platform conditions. That is not a portable swap card. Android version, manufacturer configuration, device management and application design can narrow the available choices. A card inserted into a slot is therefore not proof that a setting to adopt it exists on the purchased build.
Trace a hypothetical offline job
Editorial example only: a field team downloads 400 asset forms and associated reference photographs before a shift. It then records inspections while the network is unavailable. The project must identify separately where the downloaded reference files, the app’s database, new photos and the unsent transaction queue live. If only reference photos are exported to portable media while the transaction queue remains in internal app storage, replacing the card will not move the pending inspections to another handheld. If an approved app uses adopted media for applicable data, the card is bound to its original device; removing it for another unit is not a recovery strategy.
Before changing media or reprovisioning, the operator should confirm which records the backend has accepted, which are still local and which can be restored from an approved backup. A visible file in a file manager is not proof that its matching business record was synchronized. The application-update guide treats preservation of unsent work during app changes; card handling needs the same record-level verification.
Choose by recovery requirement, not capacity alone
| Requirement | Question to answer | Acceptance evidence |
|---|---|---|
| Transferable files | Question: does the app explicitly export the required files to portable media in a documented format? | Evidence: open and reconcile a sample export on the approved receiving system. |
| More app space | Question: does this Android build offer adoption, and does this app support the intended placement? | Evidence: check actual placement, operation and recovery on the exact configured device. |
| Device replacement | Question: what approved backup or server reconciliation restores local records without relying on a card swap? | Evidence: restore a controlled sample and compare transaction identifiers with the system of record. |
Do not treat a later card format, an app uninstall or a factory reset as a harmless storage-setting change. Each can affect local data under the project’s app and device policy. AOSP notes that adopted media is tied to one device and recommends stable physical locations to reduce accidental removal. That design tradeoff should be tested with the actual enclosure, shift procedures and approved backup path, without assuming a universal card endurance or speed result.
Run a bounded acceptance test
On the exact device build and app version, record the available card mode, card identification and resolved storage locations. Populate a small authorized offline dataset, disable connectivity, create a few clearly identified unsent records, then test the permitted removal or replacement procedure. Reconnect, reconcile every sample ID with the backend, and demonstrate the documented recovery path if the card or device is unavailable. Keep a separate result for reference-file access, app launch, unsent work and completed synchronization. If an operation cannot be performed safely under the app’s data policy, document that constraint instead of forcing the test.
For a proposed AIDC GO handheld, request model-specific slot and OS-build evidence through Integration Support. The handheld range is a starting point for configuration selection; Contact can receive the application’s offline-data map and recovery requirements. This guide does not establish removable-storage support or data portability for an unspecified model.