Storage failures rarely begin with a clean “eMMC worn out” message. A field unit starts taking longer to boot, SQLite transactions stall, an update runs out of space, or the filesystem remounts after another unplanned power cut. By then, the useful evidence may already be gone.
The practical way to size eMMC is to measure host writes on the real Android workload, estimate internal write amplification, reserve free space, and validate the selected part under temperature and power-loss conditions. Capacity and endurance are related, but a larger number on the box is not a complete lifetime calculation.
What actually consumes eMMC life
NAND flash wears as blocks are programmed and erased. The eMMC controller spreads writes, manages bad blocks, performs error correction, and moves data internally. Android sees logical block writes; the NAND can see more physical writing because of garbage collection, metadata updates, small random writes, and background maintenance.
That multiplier is write amplification. It changes with free space, workload shape, filesystem behavior, controller firmware, temperature, and aging. A workload dominated by aligned sequential media writes is not equivalent to thousands of small database syncs.
| Workload source | Why it matters | Useful control |
|---|---|---|
| Application logs | Can write continuously and burst during faults | Rotate by size and age; cap retained data |
| SQLite or local database | Journals and syncs create small repeated writes | Batch safely and review transaction frequency |
| Camera or sensor capture | High sustained data volume | Set retention, bitrate, and export policy |
| OTA updates | Large writes to system slots and temporary space | Budget both slots, payload, rollback, and cleanup |
| Crash dumps | Largest bursts occur when the device is already unhealthy | Reserve quota and upload selectively |
| Swap or memory pressure | Turns RAM shortage into storage traffic | Fix memory budget; avoid relying on flash as RAM |
| Filesystem housekeeping | Free-space pressure raises internal movement | Maintain headroom and monitor utilization |
The worst logging bug is often more important than the nominal business workload. During development, leave the unit running with network failures, peripheral disconnects, and repeated service restarts. Watch what gets written when the system is unhappy.
Start with a transparent lifetime estimate
A first-pass calculation can compare options:
raw writable data = usable NAND capacity × rated program/erase cycles
estimated host-write budget = raw writable data ÷ assumed write amplification
Consider an illustrative 64 GB device using NAND rated for 3,000 program/erase cycles. The raw figure is 192 TB. With an assumed write amplification of 3, the simplified host-write budget is 64 TB. At 20 GB of host writes per day, that is about 8.8 years.
That is not a warranty. Spare area, static data, controller policy, NAND type, retention, bad-block growth, workload distribution, and vendor endurance definitions all affect the result. Use the calculation to expose assumptions and compare parts, then replace estimates with supplier data and testing.
The calculation also shows why extra capacity helps. If the image and customer data occupy nearly the whole device, wear leveling has less room to work. Moving from 32 GB to 64 GB may provide more than storage headroom; it can spread the same daily writes across more NAND.
Measure writes on the product workload
Measure after the software has reached steady operation. A short test can be dominated by first boot, application installation, media indexing, and update setup. Run several representative days or an accelerated but realistic cycle.
Linux block statistics expose aggregate sectors written by the eMMC block device. Android’s storage services and kernel interfaces can add UID-level or application-level context, depending on BSP and version. Collect both: the block device tells you total host traffic, while per-UID data helps identify the writer.
Use fixed checkpoints:
- Start from a documented production image and free-space level.
- Record block write counters and storage health data.
- Run the real application, display, network, and peripherals.
- Inject failures that create logs and retries.
- Apply an OTA update and perform rollback or recovery tests.
- Record counters again and normalize writes per day or per transaction.
Do not use application file size as the write count. A 10 MB log that is rewritten, compressed, copied, and deleted may create far more than 10 MB of block traffic.
The Android power-loss recovery guide is relevant here. Repeated brownouts can turn normal metadata activity into corruption and recovery writes. Endurance and power integrity are separate requirements, but the field symptoms overlap.
Select the eMMC as a controlled component
Part number matters. Record density, NAND technology when disclosed, endurance class, operating temperature, firmware revision, package, life-cycle status, and health-report support. “64 GB eMMC” is not a production specification.
Consumer and industrial-temperature parts may differ in qualification, retention claims, supply control, and endurance documentation. Industrial labeling does not automatically mean unlimited writes; request the endurance conditions and understand whether figures assume sequential workload, particular capacity use, or a defined temperature.
Avoid uncontrolled substitution. A second-source part needs image compatibility, boot timing, performance, power-loss, thermal, and endurance review. This belongs in the same change-control process as an SBC revision, as explained in Android SBC lifecycle planning.
Use health indicators without overpromising them
Modern eMMC devices can expose a pre-end-of-life indication and device lifetime estimates through extended device data. Lifetime estimates are commonly reported in broad usage bands rather than exact remaining days. Vendor interpretation and availability vary.
Treat these values as maintenance signals, not precision fuel gauges. Record the raw fields, device identification, firmware, host-write counters, uptime, temperature history, free space, and important I/O errors. Trends across a fleet are more useful than one isolated value.
| Signal | What it can tell you | What it cannot prove |
|---|---|---|
| Lifetime estimate fields | Approximate consumed-life band | Exact date of failure |
| Pre-end-of-life status | Spare-block pressure warning | Absence of filesystem or power faults |
| Host writes | Workload volume seen by block layer | Internal NAND write amplification |
| I/O latency trend | Emerging stalls or heavy maintenance | Root cause without other evidence |
| Corrected/uncorrected errors | Controller or media stress | Remaining retention under all temperatures |
| Free-space trend | Risk of higher amplification and failed updates | NAND health by itself |
If the BSP does not expose health data cleanly, decide whether a privileged service should collect it. Do not grant a general application broad device access just to read storage counters.
Reduce writes without risking data integrity
The right goal is useful data with bounded writes, not simply fewer fsync calls. Removing durability from critical transactions can trade endurance for corrupted state.
Set explicit quotas for logs, analytics queues, media, and crash artifacts. Batch noncritical telemetry. Keep databases indexed and avoid polling that rewrites unchanged state. Move temporary data to appropriate cache locations and let it be discarded. Stop duplicate logging at framework and application layers.
Maintain free space for updates and controller operation. Alert before the device is nearly full and test how the application behaves at the warning and stop thresholds. An update design using A/B slots needs room for both system images and working data; the Android OTA guide covers the rollback implications.
Qualify lifetime and failure behavior
Benchmarks are useful for comparing lots but weak predictors of field life. Build an endurance rig that replays the production write pattern, including databases, logs, updates, and idle periods. Run units at relevant temperature points, because data retention and wear behavior are temperature-sensitive.
Cycle power at controlled moments on sacrificial units. Verify bootloader, partition table, metadata, application database, and rollback behavior. Track latency as well as pass/fail; long tail latency can break a watchdog or UI before an I/O error appears.
Keep at least one sample from each qualified storage lot. When field data changes, compare against the golden unit with the same image and workload.
Frequently asked questions
Is 64 GB eMMC always more durable than 32 GB?
Not always, but more NAND usually gives wear leveling more room for the same data set and daily writes. The exact result depends on NAND, controller, overprovisioning, workload, and supplier rating.
Can Android report eMMC health?
The underlying device may expose lifetime and pre-end-of-life data, and the kernel or privileged services can read storage statistics. Availability depends on the eMMC, kernel driver, permissions, and BSP implementation.
Should logs be moved to an SD card?
Only if the SD card is controlled, replaceable, monitored, and suitable for the workload. Moving uncontrolled writes to a less reliable medium can create a different field failure. First fix retention and log storms.
Bottom line
eMMC endurance is a workload budget. Specify the actual part, measure block writes over realistic cycles, leave free space, watch coarse health indicators, and test power loss at temperature. If the lifetime estimate cannot show its daily-write and write-amplification assumptions, it is not an engineering estimate yet.