Argosy Launcher: a gamepad-first Android front end for a self-hosted RomM library

The gap Argosy fills between a RomM server and a handheld

RomM is a self-hosted game library server. It stores ROMs, attaches metadata and cover art, and exposes an API. What it does not ship is a client for the device you actually play on. Argosy Launcher is that client, written in Kotlin and released under GPL-3.0. The README describes it as "a gamepad-first Android launcher for retro gaming handhelds with native RomM integration."

The audience is narrow and clearly stated: owners of Anbernic, Retroid Pocket, Odin, AYN and Android TV devices. These machines boot into a stock Android shell that was never designed to be driven by a D-pad. Argosy replaces that shell with a library browser you can operate without touching the screen. If you play on a phone with a touchscreen and a Bluetooth pad, the interface still runs, but the design assumptions point elsewhere.

The practical problem is not the launcher itself. It is the round trip between a server, a memory card, and an emulator. Argosy collapses that into one app: sync, download, assign an emulator, launch.

How the RomM sync, download queue and emulator handoff work

The data flow runs in one direction from your server and then back again for saves. Argosy reads the RomM library over the API, caches metadata and cover art locally, and presents it as a browsable grid. The README describes image caching as storing "all cover art locally for fast, offline browsing," which is what makes the offline mode possible: once a library has been synced, the metadata and artwork survive without a network.

Downloads are queued rather than immediate. The README says games are "automatically sorted by platform" and that you can "queue multiple downloads." BIOS files are handled by the same path, which matters because a large share of emulator setup failures come from missing firmware rather than missing ROMs.

Emulator assignment is the part that saves the most manual work. Argosy detects installed emulators and maps them to platforms. For RetroArch specifically, it manages core selection per platform, so a launch does not depend on whichever core was last loaded by hand. Multi-disc titles get a disc picker at launch instead of a merged file.

Save sync is bidirectional and the README states that conflict detection is present. That is the one place where the design has to make a judgement call about which copy wins, and the README does not document the resolution rule.

Installing the Argosy Launcher APK and connecting it to RomM

The README gives a five-step path: download the APK from GitHub Releases, install it, run the app, connect to RomM or skip, then sync. There is no Play Store listing and no package manager route. You sideload the APK from the releases page.

On first run the setup wizard appears. To connect to a server you need a RomM client token, which the repository's .env.example describes as created in RomM under Settings > Client Tokens, via POST /api/client-tokens. The same file shows the shape of the configuration:

ROMM_BASE_URL=https://romm.example.com
ROMM_CLIENT_TOKEN_FILE=~/.romm-client-token

That file is the build-time and development configuration, not something the Android app reads directly, so treat it as documentation of which values the client needs. In the wizard you supply the base URL and the token. After that, run a library sync. You should see your platforms populate with cover art. Launch a game and the disc picker or emulator handoff appears.

Where Argosy Launcher stops being the right tool

The emulator support list is finite. RetroArch, PPSSPP, DuckStation, AetherSX2, Dolphin, Drastic, melonDS, Mupen64Plus FZ, Pizza Boy, Lime3DS, Azahar, Flycast and Redream are named, with an invitation to open an issue for anything missing. If your platform depends on an emulator outside that list, auto-detection will not help you and the launch path may not exist at all.

The larger constraint is the server. The README calls RomM "optional, for sync features," which is technically true and practically misleading: sync, on-demand downloads, save sync, achievements and ratings all route through RomM. Skip the server and you are left with a local launcher and an app index. That is a real use case, but it is a fraction of the feature list.

There is no iOS build, and the repository is Kotlin with an Android app module, so none is implied. Anyone searching for an Argosy Launcher iOS client will not find one here.

Save conflict handling is the weakest documented area. The README asserts that "conflict detection ensures you never lose data" but does not describe the merge policy, the prompt, or what happens when two devices write between syncs. If you play across more than one handheld, that is the behaviour to probe before trusting it with progress you care about.

Argosy Launcher against a plain emulator frontend

The obvious alternative is a generic Android front end such as Daijisho or Dig, or simply launching emulators from the stock app drawer. The difference is where the library lives. A generic front end scrapes metadata from public databases and stores it on the device. Argosy does not scrape at all: metadata comes from your RomM server, which in turn sources it from IGDB, and the README lists cover art, descriptions, genres, franchises and player counts among the fields.

That distinction decides the choice. If you want a launcher that works with zero infrastructure, a scraper-based front end is simpler and has no server to keep running. If you already maintain a RomM instance, a scraper duplicates work you have done and will drift from your server's state. Argosy's value is that the server remains the single source of truth, including for saves.

The second difference is input. Most Android front ends are touch-first with gamepad support bolted on. Argosy maps the Quick Menu to L3 and Quick Settings to R3, and exposes performance mode and fan control on Odin, AYN and Retroid hardware. Those are handheld-specific affordances that a general front end has no reason to implement.

Maintenance, licence and what upgrading costs you

Argosy Launcher is not archived. The last push to the main branch was on 2026-08-28, the same day as the v2.10.0 release, and v2.9.0 and v2.8.0 landed earlier that same week. Three releases in six days is a fast cadence, and it also means the project moves quickly enough that pinning a version is worth considering on a device you rely on.

Upgrades are handled inside the app. The README lists an in-app updater and a built-in updater among the features, and states that "updates are handled in-app after initial install." That removes the need to sideload each release, but it also means the app needs network access and a release channel you trust. Beta builds exist and the README warns they "may be unstable and introduce breaking changes," so do not opt into that channel on a device holding saves you have not backed up elsewhere.

The licence is GPL-3.0. In practical terms, if you fork and distribute a modified build, the copyleft terms attach to that distribution. Running it on your own handheld is unaffected. For anything beyond personal use, read the licence text rather than a summary.

The repository carries a libretrodroid submodule and a testbed directory, which suggests the emulator integration layer is shared code rather than something written from scratch. The README does not document how that submodule is versioned or updated, so a source build may need attention there.

Editorial conclusion

Argosy Launcher is for people who already run RomM and own an Android handheld with physical controls: install the APK, point it at your server with a client token, and let it handle downloads and save sync. It is not the right tool for a phone-only user who wants a desktop-style launcher, nor for anyone unwilling to run a server, since the README lists RomM as optional but most of the feature set depends on it. Before committing, verify that the emulators for your platforms are in the supported list, that your device runs Android 8.0 or higher, and that your RomM instance exposes the client token endpoint the .env.example references.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes