Skip to content

Emulator Explainer

Save States vs In-Game Saves On Android Emulators

Save states snapshot emulator memory, in-game saves use the game's own save system. Here's how both work on an Android emulator with save states.

Save States vs In-Game Saves On Android Emulators preview

Written by the Fulldive product engineering team, based on direct inspection of the repositories listed below.

An Android emulator with save states gives you two very different ways to save progress, and users get confused by this constantly. Save states are snapshots of the emulator’s whole memory. In-game saves are what the original game itself wrote to cartridge save memory or a memory card. Both are useful. They are not interchangeable, and on a real Android device they can fail in different ways. This post explains the difference, using work done in Fulldive’s One Emulator for Game Consoles as concrete examples.

What a save state actually is

A save state is produced by the emulator core. It serializes the current CPU registers, RAM, video memory, timers, and any other state the core tracks, then writes it to disk as a file you can reload later. Reloading a save state restores that exact frame.

Advantages:

  • Instant save and reload, even in games that have no save system.
  • You can checkpoint anywhere, not only at the game’s save points.
  • Good for difficult sections, speedruns, and grind-heavy RPGs.

Disadvantages:

  • Save state files are tied to the specific core and often the specific core version. Swap cores or upgrade a core and your states may stop loading.
  • They can capture broken state if the emulator was mid-glitch when you saved.
  • They are not portable to the real hardware.

What an in-game save is

An in-game save is what the cartridge or memory card would have stored on the original console. The game’s own save routine writes it; the emulator just provides the memory area. When you load the game again, the game reads it back as if the cartridge had been in a real console.

Advantages:

  • Portable across emulators and cores that agree on the save format.
  • Survives core upgrades, because the game still reads what it wrote.
  • Matches the experience the game’s designers built — save points are intentional.

Disadvantages:

  • Tied to the game’s save structure. If a game only saves at specific points, that’s what you get.
  • Some systems need specific file extensions and folder layouts to be found correctly.

Where this breaks on Android

Android emulators have to deal with a messy reality:

  1. Core upgrades. When the emulator bumps a core, the save state format can change. The desmume core was deprecated in favor of melonDS in the Fulldive emulator, and a lazy save migration was written so existing users wouldn’t lose their in-game saves when they next launched (commit f71aade4). That’s specifically for in-game saves; save states are a different story and more likely to be left behind on a core change.
  2. Save format imports. The same transition needed an import path for previous melonDS saves so users already on that core had continuity (commit 28a1f115).
  3. Sync and crash edge cases. A save sync crash was fixed in commit 52e9487d. Save code is one of the highest-risk surfaces in an emulator because crashes there can actually eat progress.
  4. Experimental states on newer cores. Citra save-state support was added experimentally in commit 1030d028. “Experimental” is the right word — save states on a newer core for a more complex system often need rounds of tuning.
  5. Quick save and quick load. Gamepad and on-screen shortcuts for quick save/load and fast forward were added in commit 86d4d1b1, which made save states actually usable in the heat of play.

That history is mostly about making the two save systems coexist safely rather than letting either one stomp the other.

When to use each

A simple rule we use internally and tell users:

  • Use in-game saves for normal progress, especially anything you might want to play on another device or hardware later. They are the canonical save for the game.
  • Use save states for convenience: before a hard boss, before a known glitch, for section retries, and for speedrun practice. Don’t rely on them as your only record of a playthrough across core upgrades.

How to not lose progress

Three practical habits:

  1. Back up your save folder. Android backups don’t always cover app-private storage on every device, so a manual copy of your emulator save folder before an update is cheap insurance.
  2. Note which core you used. If you’re about to try a different core for a game, keep a save state from the old core separately. You may not be able to load it on the new one.
  3. Use named slots, not just “Quick Save.” Quick Save is one slot that gets overwritten. Named slots let you keep multiple checkpoints.

Save state behavior depends on the emulator core and the specific game file. Fulldive’s emulator apps do not include or distribute copyrighted ROMs; users are expected to supply legally obtained game files that are compatible with the app. Save state and in-game save compatibility varies by game, file, device, Android version, and emulator core version. Treat “experimental” save-state support exactly as the label says — useful, but worth backing up.

Sources

Last updated: 2026-04-16. Commit hashes and version numbers are drawn from Fulldive repositories inspected on 2026-04-13.