Argosy Launcher: fan control on Odin, AYN and Retroid, and every link pointing at another org

Every link in the README points at nendotools, the repository is rommapp

The repository is served from `rommapp`, and the documentation consistently points somewhere else. The build badge, the releases link, the wiki link for setup guides, the link for opening an issue when an emulator is missing, the bug report form and the feature request form all name `nendotools/argosy-launcher`. That is ten-odd links pointing at one organisation while the metadata and the tree belong to another, which is the signature of a project that moved and kept its documentation. It matters practically: a reader who follows the setup link lands on a repository that may or may not be the same code, and someone filing a bug through the documented form may file it against the wrong tracker. GitHub redirects renamed organisations, so this may resolve correctly for all of them. The README does not say either way, and no migration note is visible in what the documentation covers.

Fan control and performance mode exist on three device families

Quick Settings opens on R3, the right stick click, anywhere in the app, as a right-side panel with four controls: theme, haptics, UI sounds and background music. Those four are universal. Performance Mode and Fan Control are not, and are stated to appear only on supported devices, named as Odin, AYN and Retroid. That is the sharpest device limitation in the documentation, because thermal and performance controls are the ones a handheld owner is most likely to want, and an Anbernic user gets a panel without them even though Anbernic is the first device family listed under target devices alongside the RG35XX, RG556 and RG406. Android TV boxes are also listed as a target. The other anywhere-binding, L3 for the Quick Menu, has the same shape: it assumes a controller with clickable sticks, which is exactly the assumption the rest of the interface rests on.

The RomM token is read from a file, and the variable prefix is not consistent

The environment example is four lines and the interesting one is how the credential is handled. The RomM token is described as long-lived and created in RomM under Settings, Client Tokens, at a POST endpoint, and it is not read from an environment variable. `ROMM_CLIENT_TOKEN_FILE` points at `~/.romm-client-token`, so the secret lives in a file with a path the app controls rather than in a shell export that would land in history or in a process listing. That is the better choice and worth copying. The naming is less tidy. Two variables use a doubled M, `ROMM_BASE_URL` and `ROMM_CLIENT_TOKEN_FILE`, while the storage override uses a single M, `ROM_STORAGE_PATH`, commented out along with its example default of `/storage/emulated/0/ROMs`. Debug logging is the third optional key. Three variables, two prefixes, and the default path is visible only because the line is left in place.

The app updates itself from GitHub Releases, and there is no store listing

Getting started is five steps and the first two are the distribution model: download the latest APK from GitHub Releases, install the APK on the device. Then run the app, follow the wizard, connect to a RomM server or skip for local-only use, and sync. The requirement line is Android 8.0 or newer, with emulators installed separately and the RomM server marked optional for local use. Updates are then handled in the app after the initial install, and one of the eight screens in the screenshot section is the built-in updater, so the channel is a named feature rather than an afterthought. That makes the in-app updater part of the trust chain for anyone who installs from an APK rather than a store, and it is worth pairing that observation with the beta channel, which the documentation describes as possibly unstable and possibly introducing breaking changes.

Two releases ninety-five minutes apart, and a branch last pushed four days earlier

The release history is dense in a way that is easy to misread. v2.18.0 was published on 2026-09-28 at 11:49:33 UTC, and the default branch was last pushed eleven seconds earlier that same minute. Then there is a gap, and two releases land on the morning of 2026-10-02: v2.19.0 at 07:33:41 and v2.19.1 at 09:08:26, about ninety-five minutes apart. So the two newest versions were published on a morning with no accompanying commit to the default branch, which means either the release workflow rebuilt an existing commit or the tags were pushed without code changes. For someone tracking versions, the practical consequence is that the commit date is a poor guide to which build you are running, and the tag is the only reliable identifier. The project is GPL-3.0, so redistribution has its own terms worth reading before you pass an APK around.

The setup guide is a wiki, and the tree carries four unexplained directories

The README hands setup, emulator configuration and troubleshooting to a GitHub wiki rather than to the repository, so the durable documentation for a sideloaded APK lives in a place most people never browse and which has no version relationship to the code. Meanwhile the tree itself is wide. Alongside `app/`, `config/`, `docs/`, `scripts/`, `testbed/`, `libs/` and the Gradle files, there is `design-handoff/`, `design-system-docs/`, a `libretrodroid/` directory consistent with the RetroArch support, a `sigil/` directory with no extension or description, and a `.takt/` dot-directory whose purpose the README never mentions. Two configuration templates are committed by name, which is the right call: `keystore.properties.example` for Android signing and `.env.example` for the RomM connection. Both being examples rather than real files is the pattern to check first when auditing a build.

Thirteen named emulators, detected and assigned without configuration

The emulator list is the most concrete part of the feature set, and the claim is that most setups need no manual work at all. Argosy detects which emulators are installed and assigns them to the right platforms; with RetroArch you pick cores per platform and the launcher makes sure you launch with the right one every time. The named list runs to thirteen: RetroArch, PPSSPP, DuckStation, AetherSX2, Dolphin, DraStic, melonDS, Mupen64Plus FZ, Pizza Boy, Lime3DS, Azahar, Flycast and Redream, with a documented route for anything missing, which is an issue. Multi-disc titles get a disc picker at launch so you choose where to start, which is the small piece of polish that separates a launcher from a file browser. Around that sit RomM library sync with IGDB metadata, RetroAchievements progress, smart collections such as Top Unplayed and Recently Added, offline mode, and image caching for cover art.

Editorial conclusion

Use Argosy Launcher if you already run a self-hosted RomM server and play on an Anbernic, Retroid Pocket, Odin or AYN handheld, because the RomM integration is the reason it exists and the gamepad-first navigation is what makes those devices usable. Two things to check first. Performance Mode and Fan Control appear only on Odin, AYN and Retroid devices, so on an Anbernic the thermal controls simply are not there. And updates arrive inside the app from GitHub Releases rather than through a store, which makes the built-in updater part of your supply chain; combine that with the beta channel, whose versions may be unstable and may introduce breaking changes, and treat sideloading this APK as a deliberate decision. Verify the release you install is from the rommapp repository, since every link in the README points elsewhere.

Frequently asked questions

Official sources

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