# FGA is an Android app that plays a game by looking at the screen, and its releases are build numbers > A Kotlin port of a Lua automation project, packaged as an Android application that recognises what is on screen and taps it through an accessibility service rather than by touching the game. The release tags are bare build counters, three of them shipped on one day, and the wiki the documentation links to is committed in the repository. **Fate-Grand-Automata/FGA** — Auto-battle app for F/GO Android - Repository: https://github.com/Fate-Grand-Automata/FGA - Website: https://fate-grand-automata.github.io - Stars: 2,391 · Forks: 364 - Language: Kotlin - License: MIT - Published: 2026-09-28 · Updated: 2026-09-28 · Language: en - Canonical page: https://hysenlabs.com/projects/fate-grand-automata-fga ## Automating a commercial game is your decision to make, not this page's to enable This repository automates repetitive play in a commercial mobile game, which means anyone using it is making their own decision about how that game's own rules apply to them. That decision belongs to the user, and the project's own framing is narrow: it says the app is not made to play the story for you but to automate the mundane farming, and it states that it does not tamper with the game in any way. What follows here is an account of how the thing is built, because that is what the repository is a record of. It is not an operating guide, and deliberately so: the page's own getting-started material lives on the site and in a wiki, and the permissions this kind of app needs are the user's to grant deliberately rather than to grant because a document told them to. If you are deciding whether to run it, the deciding question is the game's terms, not anything here. ## Three Android platform APIs, doing three different jobs The mechanism is stated in three lines and there is nothing hidden in it. ```text OpenCV for image recognition Media Projection for taking screenshots Accessibility Service for clicking/swiping ``` The camera API is what lets the app capture what is on the screen, and the accessibility service is what lets it send taps and swipes. Computer vision then matches the captured frame against reference images to decide what the current screen is. The project describes this as working the way a person does, by looking at the screen and tapping, and the technical choices are consistent with that claim: nothing here reads game memory, injects code, or modifies an installed package, and the only channel into the game is the same one a user's thumb has. The cost of that design is that the app is as good as its reference images and as fast as the recognition step, since every decision is made from a captured frame rather than from state. ## A Kotlin port of a Lua project, with a settings screen instead of a config file The lineage is explicit in the acknowledgements rather than buried: the app is a port of an existing Lua automation project for the same game, and the page credits that project's developers as the reason this one exists, stating plainly that without them it would not. The engine sits in its own directory at the repository root, separate from the Android application module, which is the shape you would expect from a port whose core is not an Android concept. What the port changes is the packaging and the ergonomics: the original is a set of scripts you configure by editing files, while this one is a graphical application with a configuration interface and, in the project's words, no time limit on use. That is the whole difference in one sentence, and it explains why the application exists rather than being a distribution channel for the scripts. ## One press becomes: match the screen, then offer what fits it The runtime loop is described in a single sentence and it is worth unpacking, because it explains both the convenience and the fragility. > When you click on the PLAY button, the app detects which script can be run on the current screen and presents it to you. So the app does not run everything it knows. It matches the current screen against the scripts it has, and it shows you the ones that apply, leaving the choice to you. That is a defensible design for something that can act on your account: the blast radius of a misdetection is bounded by what you were offered, because you still decide. It also means the recognition has to be right, which is why the repository includes a separate support image maker for producing the reference images the matcher needs, documented on a wiki page. A user therefore ends up maintaining an image set, and a visual change in the game, a new event screen, a different device resolution, is a recognition failure that the user has to diagnose. ## Three releases on one day, tagged with bare build numbers The tag names carry no semantic version at all: 3059, 3058 and 3057, with the release titles repeating the same bare number. All three were published on 2026-10-02, at roughly 10:45, 11:23 and 14:49. So the project's version is a build counter that has passed three thousand, it moves several times a day, and there is nothing in the number that tells you whether a change is compatible, fixes something or alters behaviour. For a tool that automates a third party interface, that cadence is a reasonable response to the game itself changing underneath it, and it is also why you should not treat any of these tags as a release you can reason about. If you want to know what a given build does, the only source is the diff between the commits behind two counters, and the page does not summarise them for you. The last recorded commit on the master branch is the same day as the newest tag. ## A Ruby gemfile, a release directory and a dependency bot The top level is a mixture of four toolchains, and none of them is a surprise once you know what each is for. There is a Gemfile and a lock file, which is Ruby in a Kotlin project, and that pairing is the localisation and translation tooling rather than anything shipped to a phone. There is a release automation directory, which is the tool that builds and publishes those build-numbered tags. There is a dependency update configuration for an automated upgrade service, which for a project tracking a game and its own port is the difference between catching an upstream change and not. And there is a funding configuration plus a small donation page link, so the project has a funding route as well as a contribution route. The interesting one for a user is the dependency bot, because a continuously released app on a continuously updated dependency set is a different risk profile from a project that bumps deliberately. ## The wiki is in the repository, and so are two agent instruction files The documentation the page points at lives in two places at once. There is a wiki directory committed to this repository, and the readme links to wiki pages on the hosting service, so the same content can be read in the source tree and on the web. That is why the contributing guide is referenced as a relative file in the readme and resolves, while the troubleshooting guide and the image maker guide are referenced as hosted pages. It also means the parts of the documentation a new user actually needs, the troubleshooting guide and the image maker, are the parts that change with the game, and they are the parts most likely to drift from the build you installed. Two other entries are worth naming. There are agent instruction files at the root, one aimed at a specific assistant and one generic, which is a convention borrowed from server side projects and now common in mobile repositories. And the project is an Android application only: the build files, the modules and the permissions it asks for are all Android, so there is no desktop or phone-agnostic build in this repository for anyone who wants the same automation elsewhere. The licence is MIT, and the icons come from a separate icon set rather than being drawn for the project. ## Conclusion FGA is worth reading if you want to see accessibility-driven screen automation built properly, because it keeps to three documented platform APIs and its own statement that it does not modify the game, and it offers you the choice of which script to run rather than running all of them. It is not a good fit for anyone who wants a stable release to pin, because the version is a build counter that moves several times a day with nothing in the number describing what changed. Two practical points follow from how it works. Recognition depends on reference images, so a change in the game's interface is a recognition failure you have to diagnose, which is why the project maintains an image maker. And whether using it is acceptable is a question about the game's own terms rather than about this repository, so settle that first and take responsibility for it; this account deliberately stops at the architecture and will not walk you through running it. ## FAQ ### What is Fate Grand Automata? A Kotlin Android application that automates repetitive play in a mobile game. The project describes it as a port of an existing Lua automation project, packaged with a configuration interface, and states that it works by looking at the screen and tapping rather than by modifying the game. ### What Android version does FGA need, and does it need root? Android 7 or later, and no root on phones. What it does need is the user granting screen capture through the platform projection API and enabling the accessibility service, both of which are deliberate user actions on the device. ### How does the FGA app see the screen and click? Three platform pieces: a computer vision library matches captured frames against reference images, the media projection API supplies the screenshots, and an accessibility service sends the taps and swipes. The project describes the combination as working the way a person does. ### How are FGA releases versioned? With a bare build counter rather than a semantic version. Three of them, 3057, 3058 and 3059, were published on the same day, so the number tells you nothing about compatibility and any comparison between builds has to come from the commits between them. ### Can I use FGA on iOS or on a desktop computer? Not from this repository. The build files, the application module and the permissions involved are all Android, so the repository builds an Android application and nothing else. The documentation also notes that translating the app is handled through a separate translation service rather than through pull requests. ## Sources - [Fate-Grand-Automata/FGA on GitHub](https://github.com/Fate-Grand-Automata/FGA) - [License: MIT](https://github.com/Fate-Grand-Automata/FGA/blob/master/LICENSE) - [Project website](https://fate-grand-automata.github.io) - [README](https://github.com/Fate-Grand-Automata/FGA/blob/master/README.md) - [Releases](https://github.com/Fate-Grand-Automata/FGA/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fate-grand-automata-fga