# Lemuroid: a Libretro frontend for Android that hides the configuration > Lemuroid bundles Libretro cores behind an Android app with automatic save states and ROM scanning. It is easy to start and hard to tune, and the README says little about the parts that matter when something breaks. **Swordfish90/Lemuroid** — All in one emulator on Android! - Repository: https://github.com/Swordfish90/Lemuroid - Stars: 4,362 · Forks: 363 - Language: Kotlin - License: GPL-3.0 - Published: 2026-09-23 · Updated: 2026-09-23 · Language: en - Canonical page: https://hysenlabs.com/projects/swordfish90-lemuroid ## The problem Lemuroid solves: Libretro without the configuration surface Libretro is a plugin interface. A frontend loads a core, hands it a ROM, and routes input, video and audio between the core and the host. RetroArch is the best known frontend and exposes that interface directly: core options, video drivers, shaders, overlays, playlists. That is the point of RetroArch, and it is also why people bounce off it on a phone. Lemuroid takes the opposite position. The README states the goal plainly: ease of use, good Android integration and a great user experience. It originated from a rib of Retrograde and graduated to a standalone project integrating LibretroDroid, the author's own Android binding for Libretro. So the frontend is not a generic shell around cores; it is an Android app that owns the whole path from ROM discovery to on-screen controls. The audience follows from that. This is for someone who has a folder of ROMs on a phone or an SD card and wants to press a game, not a settings tree. It is also a reasonable fit for Android TV, which the feature list calls out by name. It is a poor fit for the tinkerer who wants to swap a core's internal resolution or load a CRT shader chain, because the app's premise is that those decisions are already made. ## How the frontend, the cores and the metadata database fit together The repository layout shows the architecture more clearly than the README does. There are separate Gradle modules: lemuroid-app for the application, lemuroid-cores for the emulator cores, lemuroid-touchinput for the on-screen control layer, lemuroid-metadata-libretro-db for game metadata, and retrograde-app-shared plus retrograde-util inherited from the Retrograde lineage. There are also two application variants, lemuroid-app-ext-free and lemuroid-app-ext-play, which is how the F-Droid and Google Play builds differ. That split matters when you evaluate the project. The touch input code is its own module, which is consistent with the feature list advertising optimized touch controls and customizable size and position. The metadata module is separate from the cores, so ROM scanning and indexing is not entangled with emulation. And the cores live behind LibretroDroid rather than being reimplemented, which is why the supported systems list reads like a Libretro core catalogue: stella for Atari 2600, snes9x for SNES, gambatte for Game Boy and Game Boy Color, mgba for GBA, genesis_plus_gx for the Sega family, mupen64plus for N64, PCSX-ReARMed for PlayStation, ppsspp for PSP, desmume or MelonDS for DS, citra for 3DS, fbneo for arcade. The data flow is therefore conventional for a Libretro frontend: the app scans storage, matches files against the metadata database, and on launch loads the appropriate core through LibretroDroid, which owns the native side. Save states are handled by the app rather than by the user, which is what the automatic save and restore feature means in practice. The trade-off is that anything the app does not surface is not reachable without rebuilding it. ## Installing Lemuroid and getting a first game running The README does not document a build from source or a command line install. It points at two distribution channels, F-Droid and Google Play, with badges linking to com.swordfish.lemuroid on F-Droid and the equivalent Play listing. So the install path is the store, not a shell. On a device with F-Droid already configured, the package can be installed from the F-Droid client. If you prefer a direct download, the F-Droid package page exposes the APK for com.swordfish.lemuroid, and sideloading it requires allowing installs from unknown sources on that device. The Google Play listing is the alternative for devices where sideloading is awkward, such as a Chromebook or a Google TV box. Once installed, the first real use is a scan. Put ROMs somewhere the app can read, then open Lemuroid and let it index them. The README describes this as ROMs scanning and indexing, and it also states support for zipped ROMs, so a zipped collection does not need to be unpacked first. After the scan, games appear in the app's library and launch with a tap. There is no configuration file to edit and no core to select, which is the whole design. The settings that exist are the ones the feature list names: touch control size and position, display simulation for LCD and CRT, gamepad mapping, tilt input, and cloud save sync. If you are on Android TV, the README lists Android TV support as a feature, so the same scan-and-launch flow applies with a controller rather than a touchscreen. ## Where Lemuroid stops: cores, platforms and missing documentation The supported systems list is the boundary, and it is worth reading as a boundary rather than a menu. PlayStation 2 is not on it. GameCube and Wii are not on it. Dreamcast is not on it. If your library is built around those, Lemuroid is the wrong tool regardless of how well it handles the systems it does support. The 3DS entry deserves a note of its own. The list names citra as the core, and Citra's upstream development status is not something this repository controls. The README lists the system as supported; it says nothing about which titles run acceptably, and it offers no compatibility table. Treat the 3DS line as a statement about integration, not about performance. The documentation gap is the other limitation. The README is a feature list and a systems table. It does not document rollback, it does not explain where save files are written, and it does not describe how cloud save sync resolves conflicts between two devices. Those are exactly the questions a user asks after a week of play, and the repository does not answer them. The code is public, so the answers exist, but you will be reading Kotlin modules rather than a manual. ## Lemuroid compared with RetroArch: same cores, different contract Both projects are Libretro frontends, and the supported systems overlap heavily because they draw on the same core library. The difference is what each one puts in front of you. RetroArch exposes the Libretro interface and expects you to manage it. You install cores, build playlists, choose video and audio drivers, and tune per-core options. That control is why people use it, and it is also why the first hour with RetroArch on a phone can be spent in menus rather than in a game. Lemuroid inverts that. Cores are bundled through the lemuroid-cores module, the app decides which core handles which system, and the user-facing surface is a library and a small settings set. The README's stated goal of ease of use is a design constraint, not a marketing line: it explains why there is no core picker. If a core misbehaves on a particular title, you cannot switch to another one for that system without changing the app. So the choice is not which emulator is better. It is whether you want the Libretro interface exposed or hidden. RetroArch gives you the interface and the work that comes with it. Lemuroid gives you the result and takes away the levers. ## Licence, build cost and what a fork would owe Lemuroid is GPL-3.0. The repository carries a COPYING file at the top level, which is the licence text, and the project is distributed through F-Droid, a store that checks licensing. For a user installing from F-Droid or Google Play, the licence has no practical effect on use. For anyone building or redistributing, the GPL-3.0 obligation is the relevant fact, and it applies to the app and its modules, including the retrograde-app-shared and retrograde-util modules inherited from the Retrograde lineage. The individual Libretro cores linked through LibretroDroid carry their own licences, which are not stated in this README; that is something to check before redistributing a build. This is a description of what the repository contains, not legal advice. The build itself is a Gradle Android project with buildSrc, a settings.gradle.kts listing the modules, and separate free and play variants, so a fork has to keep two application flavours working rather than one. The repository also carries fastlane metadata, which is where the store listing text and screenshots live, and a crowdin.yml pointing at the translation project on Crowdin. Neither is needed to run the app, but both are part of the maintenance surface if you fork it. ## Conclusion Adopt Lemuroid if you want a Libretro frontend on a phone, tablet or Android TV and you would rather not configure cores, and if the systems you care about are on the supported list: NES through PlayStation, plus N64, PSP, DS and 3DS. Do not adopt it if you need per-core tuning, shader work or a desktop build, and do not expect PS2 or GameCube, which the README does not list. Before committing, verify two things on your own device: that your ROMs are picked up by the scanner, and that the automatically saved state is restored when you reopen a game. The repository's last push was on 2026-08-12, so the code is moving even though the README has not caught up. ## FAQ ### What consoles does Lemuroid emulate? The README lists Atari 2600, 7800 and Lynx, NES, SNES, Game Boy, Game Boy Color and Game Boy Advance, the Sega Genesis, CD, Master System and Game Gear, Nintendo 64, PlayStation, PSP, FinalBurn Neo arcade, Nintendo DS, PC Engine, Neo Geo Pocket and Neo Geo Pocket Color, WonderSwan and WonderSwan Color, and Nintendo 3DS. ### Which is better, Lemuroid or RetroArch? Both are Libretro frontends drawing on the same core library, so the systems overlap. RetroArch exposes core options, playlists and drivers; Lemuroid bundles the cores and presents a library instead, in line with its stated goal of ease of use. ### Can Lemuroid run PS2 games? No. The PlayStation 2 is not in the supported systems list in the README. The PlayStation entry covers the original PlayStation, handled by the PCSX-ReARMed core. ### How do I install Lemuroid? The README links to two distribution channels: F-Droid, for the package com.swordfish.lemuroid, and Google Play. There is no documented command line or source build install path in the README. ### Where are Lemuroid save files stored? The README does not document the save file location. It states that the app automatically saves and restores game states, and lists quick save and quick load as features, but gives no path or directory. ### Does Lemuroid support cheats? The README does not mention cheats anywhere in its feature list or systems table, so nothing about cheat support can be confirmed from the documentation. ## Sources - [Issues](https://github.com/Swordfish90/Lemuroid/issues) - [License: GPL-3.0](https://github.com/Swordfish90/Lemuroid/blob/master/LICENSE) - [README](https://github.com/Swordfish90/Lemuroid/blob/master/README.md) - [Releases](https://github.com/Swordfish90/Lemuroid/releases) - [Swordfish90/Lemuroid on GitHub](https://github.com/Swordfish90/Lemuroid) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/swordfish90-lemuroid