VadimBoev/FlappyBird: a Flappy Bird clone in C with an APK under 100 KB

What the sub-100 KB APK is actually for

This project is a demonstration of a constraint, not a general-purpose game. The README says the goal was to create a game with the minimal APK size that would still be understandable and interesting, and that the original attempt in C++ with ImGui produced an APK around 1 MB, crashed, and shipped only the armeabi-v7a library. The rewrite in C targets less than 100 KB and, per the description, works on Android 5.0 and above.

The audience is narrow and specific. If you want to see how far a native Android binary can be pushed before the platform's runtime overhead dominates, this repository is a worked example with a build you can reproduce. If you want a Flappy Bird you can reskin and publish, you are looking at the wrong artifact: there is no licence file in the repository, and the README states that the rights to the game and resources belong to DotGEARS. The code is a study of a size budget, and the README's own framing is competitive interest rather than product intent.

Native Activity, OpenGL ES 2 and OpenSL ES in one binary

The architecture follows from the size goal. The README says the implementation combines OpenGL ES 2, shaders and Android Native Activity, with OpenSL ES for sound playback and MP3 as the compressed audio format. That combination removes most of the Java layer from the equation: Native Activity gives the app a C entry point, so the game loop, input handling and rendering live in the same compiled library rather than crossing a JNI boundary every frame.

The asset pipeline is deliberately small. PNG decoding is handled by upng, a single-file decoder the README names as the choice for that job. Audio is compressed to MP3 rather than shipped as PCM or WAV, which matters when the whole APK has to fit under 100 KB. The README describes the process as starting from a Hello World in C packaged into an APK, then layering these pieces on top. The data flow is therefore: assets in the APK, decoded at runtime by upng, uploaded as textures through OpenGL ES 2 shaders, with OpenSL ES feeding MP3 audio, all driven from the Native Activity entry point.

What the README does not document is the internal structure of the FlappyBird directory, the shader sources, the game state machine, or how input is mapped. Anyone evaluating the code for reuse has to read the source, because the prose stops at the list of components.

Building the APK on Linux and macOS with make

The README gives two build paths. On Windows with Visual Studio Code, the instructions are to create a .env from .env.example and run build.bat. On Linux and macOS, the path is the Makefile: install the Android command-line tools, set environment variables in a .env file at the project root, then run make from the FlappyBird directory.

Start by copying the example environment file. The keys are the ones the build reads, so they have to point at real SDK and NDK installations on your machine:

cp .env.example .env

The example file ships with placeholder values that you replace. Note that BUILD_TOOLS_VERSION is pinned in the example, so a machine with a different build-tools install may need that line edited:

ANDROID_SDK_ROOT=/path/to/your/android/sdk
ANDROID_NDK_ROOT=/path/to/your/android/ndk
ANDROID_HOME=/path/to/your/android/home
KEYSTORE_PASSWORD=your_keystore_password
PACKAGE_NAME=your.app.package.name
BUILD_TOOLS_VERSION=30.0.3

With the environment set, build from the game directory. The README shows the cd and make pair, and BUILDING.md is where it says to look for more detail:

cd FlappyBird
make

The signed output lands at FlappyBird/app/build/outputs/apk/FlappyBird-signed.apk. The README does not document what a successful build prints, how long it takes, or how to produce an unsigned or debug variant, so treat the first run as a way to find out whether your NDK version matches what the Makefile expects.

Where this approach breaks down

The first limitation is the one the README itself leaves open. There is no licence file in the repository, and the README states that the rights to the game and resources belong to DotGEARS. That means the code's reuse terms are unclear and the game's assets are explicitly not the author's to grant. For anything beyond reading and building locally, that is a blocker you have to resolve before writing code, not after.

The second is platform reach. Native Activity and OpenSL ES are Android-only by construction, so nothing here transfers to iOS, desktop or web without a rewrite. The description says Android 5.0 and above, and the README's history notes that an earlier attempt shipped only armeabi-v7a while Google's 2022 requirements call for arm64-v8a as well. If you are building for a store, verify which ABIs the current Makefile produces rather than assuming the problem was solved.

The third is documentation depth. BUILDING.md is referenced for detail, but the README does not describe the code layout, the shader pipeline, the game loop, or how to change the gameplay. A team that wants to modify the game rather than admire its size will spend most of its time in the source. If your goal is a maintainable game you can extend, a framework with a documented API is the better starting point, and the size advantage is not worth the missing documentation.

How it differs from Raylib and rawdrawandroid

The README names rawdrawandroid as the starting point and Raylib and ImGui as earlier experiments. The difference is where each one puts its abstraction. rawdrawandroid is a way to get a C application onto Android without the usual Java scaffolding; this project takes that idea and adds a concrete game on top, with its own asset decoding (upng) and audio path (OpenSL ES). Raylib, by contrast, is a general game library with a documented API and backends for many platforms, and the README records that an earlier C++ attempt using ImGui produced an APK around 1 MB. That number is the trade-off in one line: Raylib and similar libraries buy you portability and a documented API at the cost of binary size.

So the comparison is not which one is better, it is which constraint you are optimising. If you need to ship the same game on Android, iOS and desktop, a library like Raylib is the sensible choice and the APK size is irrelevant. If your constraint is the APK size itself, or you want to understand what the Android platform actually requires from a C program, this repository shows one answer. The README's own inspiration list reads as a lineage rather than a comparison, and it does not claim to beat any of those projects on features.

Maintenance, versions and what the repository tracks

The last push was on 2026-05-17, and the three most recent releases are v1.9.2 on 2026-05-17, v1.9.1 on 2026-05-16 and v1.9 on 2026-05-15. The version numbers move in small increments, and the release cadence in May 2026 was three tags in three days, which suggests fixes rather than a rewrite. The repository is not archived, and the README links to a Telegram dev blog for updates. It does not document a changelog per release, so the release notes are the place to look for what changed between v1.9 and v1.9.2.

The upgrade cost is dominated by the Android toolchain rather than by this project's own code. The .env.example pins BUILD_TOOLS_VERSION, and the build depends on ANDROID_SDK_ROOT, ANDROID_NDK_ROOT and ANDROID_HOME being set correctly. When you move to a newer NDK or build-tools release, the Makefile is what has to keep working, and BUILDING.md is the only documentation the README points to for that. There is no dependency manifest in the top-level entries: the repository holds .env.example, .gitattributes, .gitignore, BUILDING.md, FlappyBird.sln, the FlappyBird directory, README.md, README_RU.md and flappy.gif. That is a small surface, which is good for auditing and bad for anyone hoping for a packaged release of the toolchain. On licensing, the absence of a licence file and the DotGEARS statement are the two facts to weigh; this is not legal advice, but they are the questions to put to a lawyer before you ship anything derived from the assets.

Editorial conclusion

Adopt it if your interest is the size budget itself: a working Android game in C that stays under 100 KB, with a Makefile build you can read end to end. Do not adopt it as a game engine or as a base for a commercial title; the README states that the rights to the game and resources belong to DotGEARS, and the repository carries no licence file. Before building, confirm that your NDK and build-tools versions match BUILDING.md and that your .env sets ANDROID_NDK_ROOT, since the README only points at BUILDING.md for detail.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. VadimBoev/FlappyBird on GitHub