A rugged handheld can list enough memory to launch an application during a demonstration and still run short during a full shift. The working requirement includes the application, operating-system services, offline reference data, queued transactions, logs, captured files and space needed for updates. Procurement should therefore compare a defined workload with the exact memory and storage configuration, not treat one headline number as a guarantee.
This guide shows how an integrator or project buyer can turn the real workload into a configuration question without assuming that every Android device, removable card or storage option behaves the same way.
Describe the workload before comparing numbers
Start with the application package, supporting services and the tasks that remain available without a network. Record the largest offline catalogue or route file, the number and type of queued records, any images or documents kept locally, expected log retention and the update method. A rugged handheld category page can show current model fields, but those fields only become useful when the workload is named.
Separate a normal shift from a recovery case. A warehouse application that usually uploads each transaction may need to retain a larger queue during an outage. A field application may temporarily hold forms and photos until a confirmed upload. The offline transaction guide explains delivery state; this article focuses on the device capacity needed to keep that state safely.
Keep RAM and persistent storage as different decisions
RAM supports active processes and working data. More installed storage does not compensate for an application that exceeds its practical memory budget. Android’s memory-management overview explains that the system manages processes under memory pressure and may remove cached processes; a purchasing team should use the actual application and concurrent services when assessing a configuration.
Persistent storage holds installed packages, app data, offline datasets, logs and staged files. The advertised storage capacity is not the same as space available to the project after the operating system and preinstalled software. Ask for the exact configuration and measure usable space on a representative device after the approved build is installed.
If several applications run together, list them together. A scanner service, VPN, device-management agent and business application can all be active during the same task even though the purchasing sheet names only the foreground app.
Do not add “expanded RAM” to physical RAM on a quotation
A quotation reading “4 GB + 4 GB expansion” needs two fields, not an 8 GB physical-RAM total. Ask what is installed as physical RAM, what the additional figure represents, whether it consumes persistent storage, and which device build and setting implement it. A marketing label alone does not describe the memory mechanism.
Android’s memory-allocation explanation describes zRAM as compressed swap space within RAM. That is not another bank of installed RAM and should not automatically be described as flash-backed expansion. A separately documented storage-backed vendor feature is a different case; do not assume that every “virtual RAM” label means the same implementation.
For a bounded example, Zebra’s Power Manager “RAM on Disk” documentation describes allocating device storage for this purpose. Its published requirements include MX 13.4+, Android 14/API 34+, and specified 6375 or 6490 platform OSX builds: QCT6375.140.14.3.2 or QCT6490.140.14.5.6, respectively, or later within those requirements. This is not support for all Zebra devices, and it establishes no AIDC GO capability. Confirm the exact supported build rather than treating Android 14 alone as sufficient.
Editorial quote comparison—not a benchmark. Candidate A is advertised with 4 GB physical RAM plus a documented 4 GB storage-backed option. Candidate B has 8 GB physical RAM. They are not equivalent configurations merely because both advertisements display the number eight. The choice remains conditional on the application workload, the actual hardware and the cost; this example predicts no speed or failure rate for either candidate.
Compare the same app release, data and concurrent services on the quoted configurations. Resume a queued task after opening the other required apps, confirm retained business state, and check that update staging still fits. Record pauses, restarts and available persistent space. If a documented expansion setting may be changed, compare its supported states with the supplier’s prescribed restart procedure. Do not root the device or alter low-level memory parameters to make a procurement demonstration pass.
If the workload fails, determine whether memory pressure, an application leak, persistent-storage exhaustion or another fault caused the result. More physical RAM may be a useful configuration choice, but it does not prove that every defect is solved; expansion should not be dismissed or accepted without the same workload evidence. Keep physical RAM, expansion mechanism and remaining storage separate in the accepted quotation. No universal compression ratio, flash lifetime or performance gain is assumed here.
Build a storage budget with visible headroom
Android distinguishes persistent app files from cache. Its app-specific storage guidance notes that cache files may be removed when internal storage is low and that applications should query available space rather than assume it. Business records waiting for confirmation should therefore not depend on a cache location simply because it is convenient.
List each storage consumer with a normal amount, an adverse but credible amount and a cleanup or transfer owner. Add update staging, diagnostic capture and rollback needs where the deployment process requires them. Headroom is a project rule to be justified by the application and maintenance process; it is not a universal percentage supplied by the hardware label.
Compare what each observation can prove
| Observation | What it can establish | Limits of this observation |
|---|---|---|
| Application installs and opens | Establishes: The tested package can be installed and started on that build | Does not establish: This does not establish adequate RAM during peak work or enough storage for offline growth |
| A reference dataset downloads | Establishes: The observed dataset fits in the selected location at that time | Does not establish: This does not establish capacity for updates, logs, queued work or a larger production dataset |
| A shift completes with free space remaining | Establishes: The tested workload stayed within the observed capacity | Does not establish: This does not establish behavior during a longer outage or after repeated application updates |
| A removable card is detected | Establishes: The device and build recognized that card in the observed state | Does not establish: This does not establish that the application can store protected business data there or continue when the card is removed |
Record the starting free space, application and data versions, ending free space, queue count and any cleanup action. The same fields make a later regression visible instead of relying on a screenshot of a storage specification.
Walk one receiving-app example from install to recovery
Consider an editorial example. A receiving application installs a local item master, keeps barcode transactions until the server confirms them and retains diagnostic logs for support. The team loads the approved build, downloads the representative master, processes a controlled batch, disconnects the network, queues additional transactions and then reconnects. It records peak queue size, active application behavior and storage before and after confirmed upload and cleanup.
The test also stages the next approved application package because update files can compete with offline data. If the application slows, restarts or cannot complete the update, the team keeps RAM pressure, storage exhaustion and application logic as separate possible causes. This is an evaluation method, not a performance claim for any AIDC GO model.
Treat removable storage as a separate architecture choice
A slot or card-size listing does not prove that the application can use removable storage for its database, credentials or queued work. Android’s adoptable-storage documentation describes formatting, encryption, device binding and performance checks for supported implementations. Support still depends on the device build, application design and deployment policy.
If a removable card is proposed, document whether it is portable storage or adopted storage, what data is allowed there, what happens when it is absent or damaged and how a replacement is prepared. Do not treat removable media as automatic extra application memory, and do not use another manufacturer’s supported behavior as evidence for an AIDC GO configuration.
Send one configuration question with measurable inputs
Provide the exact application and version, Android or Windows requirement, concurrent services, installed package size, offline dataset, worst credible queue, media and log retention, update method, removable-storage policy and required free-space alarm. Include the destination country and any accessory or charging arrangement that affects the final configuration.
If the application platform is not yet fixed, resolve that boundary with the Android versus Windows rugged-tablet guide before treating memory numbers from the two environments as directly comparable.
Use the deployment readiness checklist to keep the build and recovery evidence together. Send the model shortlist and workload to Integration Support or Contact so the current configuration and documentation can be checked. The application owner remains responsible for data retention, cleanup, update and recovery behavior.