Set RetroArch SaveRAM autosave on Android without confusing it with save states
Use Settings → Saving → SaveRAM Autosave Interval to choose a non-zero interval only after the core has created a normal in-game save and RetroArch can write to its active Save Files directory. The setting periodically writes non-volatile SaveRAM; it does not create a save state, cover every core, or replace Close Content and a backup. Test one authorized game, confirm the save file changes, close content normally, and cold-load the in-game save before relying on it.
Do this in order
- 01
Record the RetroArch package and version, core and version, authorized test game, active Save Files directory, and an existing in-game save that cold-loads with autosave disabled.
- 02
Open Settings → Saving, locate SaveRAM Autosave Interval, and choose a short non-zero test interval; a value of zero disables periodic SaveRAM writes.
- 03
Change progress inside the game's own save system, wait beyond the chosen interval while content remains active, and avoid loading a save state during this test.
- 04
Inspect the configured Save Files location or its export and confirm that the expected save artifact changed after the in-game save; do not infer success from an on-screen notification alone.
- 05
Use Quick Menu → Close Content, return to the main menu, then relaunch the same game and core cold and load the progress through the game's own menu.
- 06
Keep the smallest reliable interval for that setup, preserve a separate backup, and repeat the receipt after changing package, core, save sorting, directory grant, or cloud-sync policy.
Decision and diagnostic table
| Observation | What it means | Next check |
|---|---|---|
| Interval is 0 | Periodic SaveRAM flush is disabled | Use Close Content or choose a non-zero test value |
| State reload restores progress | Only state behavior is proven | Cold-load the game's normal save |
| Save file never changes | Core, path, permission, or save-event boundary | Check core support and active Save Files directory |
| File changes but another device is stale | Sync timing or path-layout mismatch | Close content and verify both sync manifests and directories |
The interval flushes SaveRAM, not the whole machine
RetroArch's current configuration template defines the interval as a periodic write of non-volatile SRAM measured in seconds, with zero disabling it. A core must expose relevant non-volatile memory for that setting to have useful work to do.
A save state serializes a broader execution snapshot and follows different compatibility rules. Loading a state can also change what appears in memory, so keep states out of the autosave proof.
A cold in-game load is the acceptance test
The durable result is not a menu value or a timestamp by itself. Close the content safely, relaunch the same core and game, and load through the game's native save interface. That proves the core, path, write, and read sides agree.
Cloud sync starts after local persistence
RetroArch documents automatic cloud synchronization around startup and core unload. A remote copy cannot repair a local save that was never flushed, and mismatched save-sorting settings can place equivalent games in different paths. Prove local persistence first, then prove the sync result.
Use only games and save data you are entitled to use. SaveRAM settings do not grant rights to ROMs, BIOS files, disc images, artwork, music, achievements, or cloud credentials; redact account and path details before sharing diagnostics.