Choose RetroArch stable or nightly builds on Android
Choose stable for a reproducible everyday library. Use a nightly only when a specific current fix or test requires it, keep the exact build receipt and a rollback copy of configs and saves, and obtain either channel only through Libretro's official distribution surfaces. A frontend update does not grant rights to any game content.
Do this in order
- 01
Write the exact bug, core, Android version, and device behavior you need to change.
- 02
Check official release notes or build information for evidence that a candidate addresses it.
- 03
Back up configuration, playlists, saves, states, and the current app/core version receipt.
- 04
Prefer stable when no named fix requires nightly; do not update only because a date is newer.
- 05
If testing nightly, change only the frontend build, reproduce once, and keep a rollback path.
- 06
Retain the build source, date, result, and remaining limitations; never bundle content with the app.
Decision and diagnostic table
| Need | Choose | Required evidence |
|---|---|---|
| Everyday reproducibility | Stable | Release identity and backup |
| Specific unreleased fix | Nightly test | Issue/fix link and dated build |
| Unknown crash | Stable plus logs first | Clean reproduction |
| No rollback copy | Do not switch yet | Complete backup and receipt |
A nightly is a test artifact
Its value is access to recent changes, but its date alone does not show that it fixes your device or core. Tie the test to one named behavior.
Separate frontend and core
Updating RetroArch and updating a libretro core are two changes. Keep one fixed while measuring the other so rollback evidence remains useful.
Test only with games and firmware you created, dumped lawfully, or received under permission covering your use. Emulator settings and technical compatibility never grant rights to ROM, BIOS, CHD, artwork, music, or other media.