Code FA runs VS Code on Android by driving code-server in a webview

The architecture is a server on the device and a webview over it

Code FA is an Android version of VS Code implemented using code-server, and the readme is upfront that others have done similar things and that this is one of them.

The principle is to run code-server and then use a webview to load the view. The upper framework is Flutter, the loading of VS Code is implemented in Flutter, and VS Code itself runs in the Android webview.

So the stack is three layers. A Linux userland on the device provides the environment, code-server provides the actual editor, which is a browser application, and the Flutter app provides the native shell that starts the server and hosts the webview that displays it.

The important consequence of that design is the feature list. Fully local operation of code server, and it can run without an internet connection. There is no server on your laptop, no tunnel, no remote machine, and no account. The editor is the thing itself, running on the device.

That is also where the constraint comes from. The readme notes that the package size is relatively large since the resources required are necessary for the initial run, and that integrating them into the server and dynamically downloading them is not very meaningful. So the whole environment ships in the APK, and the size is the price of working offline.

The implementation is Dart and Flutter, the licence is BSD-3-Clause, and the last push was on 2026-08-14.

The project tells you where it falls short

Two paragraphs in the readme are unusually candid, and they belong in any evaluation.

The first is the advice to weigh this solution against others available from different developers. The author is not claiming this is the best way to get VS Code on Android, only that it is one way, and that the package is large because the resources for the initial run are necessary, so the alternative of bundling less and downloading on demand is not very meaningful.

The second is the quality statement. There might be some bugs, but it performs reasonably well. And then, the note about support: I'm quite busy, so responses to issues might be slow. Thank you for your understanding.

That combination, a working implementation with an explicit bug warning and an explicit slow-response warning, tells you what kind of engagement you are signing up for. This is a hobbyist project with a working artefact rather than a maintained product, and the difference matters when something breaks on a device you cannot easily reproduce it on.

The feature list is short and specific: fully local operation of code server, support for the latest version 4.103.1, support for quick updates to code-server versions, support for custom code-server versions, and it can run without an internet connection.

Custom versions are the one that makes it more than a packaged snapshot, and it comes with a process attached.

Changing the code-server version is a manual procedure

The section on changing the code-server version is a five step procedure using the device's shared storage, and it is the part of the project that requires you to understand what you are doing.

First, create a file named code_version in /sdcard with the version number as its content, such as 4.103.1, without any line breaks. Second, download the matching code-server archive, for example the linux-arm64 tarball. Third, place the downloaded file in /sdcard, and do not unzip it or change its filename.

The remaining steps repeat the third one, because the readme describes downloading the corresponding version and placing it in /sdcard, again without unzipping or renaming, and then launching Code FA and using it.

The repetition is probably a typo in the documentation, but the constraints it states are real. The file must not be renamed, because the app looks for a specific name, and it must not be unzipped, because the app does that itself.

The mechanism is worth understanding, because it explains the feature list. The version file tells the application which code-server release to look for, the application finds and unpacks the archive into its own environment on first run, and the resources that have to be present at that point are why the APK is large. Quick updates to code-server versions and support for custom code-server versions are the same mechanism with a different number in the file.

The linux-arm64 example in the download link is the architecture hint, and it is the one thing to check against your own device.

The server runs in Ubuntu, not in Termux

There is a note that changes how you install anything inside this environment.

Code Server runs in an Ubuntu environment, not in a Termux environment. Therefore, if you need to install any dependencies, simply look up how to install them on Ubuntu.

That is short and it saves a lot of time. The obvious assumption for a developer on Android is Termux, with its own package manager and its own paths, and following Ubuntu instructions inside a Termux shell produces confusing failures.

The repository even documents the Ubuntu commands, with a small apology for the fact that the section should not really be there. This section shouldn't really be here because it's not a Code FA issue, but many people don't know how to install simple dependencies on Ubuntu, and all related questions end up being directed to Code FA.

So the commands are the standard ones.

apt update

apt install python3
apt install clang

The reasoning is obvious once stated. The code-server process is a Linux server binary, it needs a Linux userland with a package manager, and the app ships a complete Ubuntu userland rather than hooking into the Termux one that is already on the device. The cost of that choice is disk space and the loss of the Termux integration, and the benefit is that the environment behaves like the server's own documentation assumes.

The build tooling assumes a Flutter and Dart workflow

The package manifest is a set of build commands, and they show how the project is put together and how it is released.

The Android build commands are driven by a tool called nic, with separate entries for a release build, a split APKs build and an AAB build for the Play Store. There are also Mac targets, for installing from local code, building a Mac app, and generating the Mac app as a tarball or as a dmg, which tells you the project is not Android only even though that is the point of it.

The Dart side of the tooling is standard. Gen Intl Code runs intl_utils:generate, which produces the localisation code, and Gen Model runs build_runner with the delete-conflicting-outputs flag, which is the code generation step for the data models.

There is also a Start Services entry, and it is the most informative line in the file.

adb shell sh /storage/emulated/0/Android/data/com.nightmare.sula/files/start.sh

So the services are started by a script inside the app's own external files directory, and the script is run over adb from a development machine. The package identifier in the path, com.nightmare.sula, is also different from the project name, which is worth knowing if you are trying to find the directory on the device.

There is a Default group too, with an upload build package step, a prepare package step that renames, and a clean build cache step.

The repository is a Flutter app with a Chinese translation

The top level listing describes a standard Flutter project with a few extra pieces.

There is pubspec.yaml, pubspec.lock and pubspec_overrides.yaml for the Dart dependencies, analysis_options.yaml for the linter configuration, a .metadata file for the Flutter tooling, and the usual lib/ and assets/ directories. The android/ directory is the Android host project, and there is a .vscode/ directory for editor settings.

The .gitmodules entry is the interesting one, because it points at a subproject, and in this case it is almost certainly the code-server environment, which is not something you would check into the application repository as ordinary source.

There is a scripts/ directory for the build and release helpers, a CHANGELOG.md, and the documentation is duplicated. The README header says Language: English with a link to README-ZH.md, and both are in the repository, which for a project whose author is not a native English speaker is a courtesy to the reader and a sign of who the audience is.

The LICENSE file is the BSD 3-Clause, and the project uses the standard GitHub badges for the release version, the last commit, the pull requests, the code size, the licence, the download count and the forks.

The release history is quiet. The tags are v1.6.1 from 2025-08-24, v1.5.0 from 2024-12-30 and v1.2.4 from 2024-06-30, so the last release is over a year old, while the last push was on 2026-08-14, which is consistent with the author's own note that responses to issues might be slow.

Editorial conclusion

Adopt Code FA when you need a working VS Code on an Android device, ideally offline, and you are willing to manage the code-server version by hand. Do not adopt it if you need a small download or a polished package, because the author states the package size is relatively large and that the solution has bugs. Verify first that the code-server build you drop in /sdcard matches the architecture of your device, and that the dependencies you install into the bundled Ubuntu environment are the ones the server needs, since Code Server runs in Ubuntu rather than in Termux.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-3-Clause
3. nightmare-space/code_lfa on GitHub
4. README
5. Releases