Android Automotive internal storage uses flash memory with thousands of erase and write cycles. If flash memory fails, the system can become unusable. As vehicles have long lifespans (typically more than 10 years), flash memory must be extremely reliable. This page describes flash memory behavior and how OEMS can mitigate the risk of flash memory devices failing.
Flash memory performance
Flash memory devices use wear leveling techniques to work around erase and write limitations by arranging data and distributing writes evenly across the system so that no single block fails due to intensive writes. The estimated life of flash memory depends on:
- Number of writes
- Write patterns
- Available size of flash memory. Larger storage size means the wear leveling algorithm can spread the writes across a larger number of blocks.
- Wear leveling techniques
- Environmental factors. Examples include an operating temperature range of usually -20 to 85 Celsius. Temperatures outside this range could further shorten the lifespan of the flash memory.
Flash memory lifespan can be calculated with the help of this formula:
However, the system would stop functioning properly long before the flash memory completely wears out as the usable storage size decreases, and the eMMC may have an even shorter lifespan depending on the leveling techniques and the write patterns used. In addition, this estimate does not consider the effects of misbehaved or malicious apps, which could disrupt Automotive systems by writing large blocks of junk data to flash memory without special permissions.
To detect the possible flash memory failure before it actually happens, proper storage health monitoring should be built in as part of the overall system health monitoring
Implement flash memory
Android Automotive supports features that enable OEMs to protect and monitor their systems' internal storage to prolong its lifespan.
Reduce flash wear
OEMs concerned about flash wear on internal storage can also add an SD card fast enough to be used as adopted storage. The SD card is expected to have the following properties:
- When adopted, the SD card is encrypted and is safe for storing app data.
- SD card slot must be in a safe location (users are not expected to remove the SD card frequently).
- SD card cannot be used for transferring data between Automotive systems and a computer.
- Ejecting the SD card doesn't affect a running system. However, it shouldn't be removed unless it needs to be replaced.
Apps on SD cards
To further protect the internal storage of Android Automotive system, OEMs can specify whether third-party apps can be installed on internal storage so that apps can write only to the partition on which they are installed. To configure, set the following configuration in the resource overlay:
<bool name="config_allow3rdPartyAppOnInternal">false</bool>
To ensure second-party apps (those built by car app developers) can be installed on SD cards if
the car mandates, car app developers must include
android:installLocation=["auto" | "preferExternal"] in the app's manifest file.
If the car does not allow third-party apps to be installed on internal storage, app installation
fails without this flag (or if the installLocation=internalOnly
setting is configured).
Get disk metrics
AAOS 13 introduced Flash Memory Overuse monitoring and metrics collection as part of Car Watchdog. For details, see Monitor flash memory usage.
Android 8 introduced storaged, a system service that samples and publishes disk and flash memory metrics, such as information about overall disk usage, flash memory lifetime estimation, and per app disk I/O stats. OEMs can use this information to warn users when the internal storage begins to fail or when specific apps are performing too many disk I/Os. For details, see Implement storaged.