CodeAssist: An On-Device Android IDE That Replaces Gradle With Its Own Task Engine

The Problem: Building Android Apps Without a Laptop

Android development normally requires a desktop machine running Gradle, the Android SDK, and a JVM. On a phone, a full Gradle runtime is too heavy, and the Gradle daemon consumes too much memory and CPU. CodeAssist solves this by providing an IDE that runs entirely on Android/ART and builds APKs on-device. It targets developers who want to write, edit, and compile Android or Java projects without carrying a laptop. The README is explicit: no Gradle daemon, no laptop. This is for hobbyists, students, or anyone who needs to make a quick change and produce an installable APK from a phone or tablet.

How It Works: A Custom Task Engine and In-Process Toolchain

Instead of hosting Gradle, CodeAssist models projects itself. The documentation describes a declarative project model compiled into an incremental task DAG. This DAG has fingerprint up-to-date checks and a persistent cache, borrowing Gradle's incremental ideas without its weight. When you edit one file, only the affected build tasks re-run. The build pipeline uses pure-Java tools: Eclipse JDT (ecj) for Java compilation, D8/R8 for dexing, and apksigner for signing, all running in process. Native aapt2 is invoked as a subprocess. The architecture separates platform-core modules (no domain knowledge) from higher layers that contribute behavior through extension points. This design keeps dependencies acyclic and allows language backends, analyzers, and build systems to plug in. The result is a self-contained build system that mimics Gradle's task graph but avoids the daemon's overhead.

Getting Started: Build and Run Commands

The README does not include a quick-start command sequence, but the repository layout and documentation indicate you build the project itself using the same toolchain. The Build section is truncated in the provided material, so exact commands are not confirmed. Based on the module layout, there are desktop and Android launchers: ide-desktop and ide-android. You would likely clone the repository, open it in an IDE (or build from the command line), and run the appropriate launcher for your target. The README mentions a regressionTest suite that runs on CI and a CI_CORE_ONLY flag for skipping some tests. The documentation files, such as docs/build-system.md and docs/architecture.md, contain the detailed build instructions. Without the full README, I cannot give you precise Gradle or command-line invocations. You should check the repository's docs directory for the exact steps.

Java and Kotlin Completion: What the Benchmarks Show

CodeAssist includes Java code intelligence powered by Eclipse JDT, offering error-tolerant parsing, ranked completion, diagnostics, and quick-fixes. Kotlin completion is in beta and is tuned to the same ranked experience. The README includes benchmark tables that are regenerated on each release. For Java completion, the reported metrics are 100% recall, 75% top-1, and 0.88 MRR. Latency is 4.3 ms for member access and 2.8 ms for type references. Symbol index queries show about 4.4 microseconds for prefix and 56 nanoseconds for fuzzy. These numbers come from the maintainer's machine and are indicative, not a guarantee. The quality metrics are deterministic, but latency depends on hardware. The project tracks these against committed baselines, and CI fails on quality regressions. This is a concrete way to measure improvement, but you should treat the absolute numbers as specific to the test environment.

Block Editing: A Projectional Editor That Writes Back Byte-for-Byte

One distinctive feature is the block editor, which projects any Java file into a Scratch-style block tree. The block tree is a live projection of the same DOM that the code editor uses, so the two views never drift. A block edit compiles to the smallest possible source edit, leaving untouched lines and comments intact. This is a projectional editor, not a textual one. Typed value sockets, inline completion, palette search, and drag-and-drop all map back to the same pipeline. The documentation claims byte-for-byte round-tripping. This is useful for beginners who prefer visual programming, but it also means that any change you make in blocks must translate back to source without altering unrelated parts. The risk is that complex Java constructs may not project cleanly into blocks, and the editor may not support every language feature. The README says any Java file can be projected, but it does not specify limits for advanced syntax like annotations, generics, or lambdas.

Limitations and Failure Modes: Not a Gradle Replacement

The most obvious limitation is that CodeAssist does not run Gradle. That means any project that depends on Gradle plugins, custom build logic, or specific Gradle tasks will not work as-is. The project model is declarative, so you must describe your build in CodeAssist's terms. If your project uses complex dependency resolution, multi-module setups with custom configurations, or build-time code generation, you will likely hit a wall. The README mentions Gradle compat in docs/build-system.md, but the material does not describe the extent of that compatibility. Another failure mode is the reliance on pure-Java tools for compilation and dexing. While D8/R8 and apksigner are standard, using ecj instead of javac may produce different behavior for some edge cases. Also, Kotlin completion is beta, so Kotlin projects may have incomplete support. The on-device environment has limited memory and CPU compared to a desktop, so large projects may be slow or fail to build. The benchmarks show impressive latency, but those are for completion, not full builds.

Alternatives: Comparing to AIDE and Termux-Based Builds

A direct alternative is AIDE, an Android IDE that also builds APKs on-device, but it uses a more traditional approach with its own build system and does not replace Gradle with a custom task engine. AIDE is proprietary, while CodeAssist is GPL-3.0. Another alternative is to use Termux on Android to install a full Java toolchain and run Gradle manually, but that requires a JVM and a Gradle daemon, which is heavy and often impractical on a phone. The key difference is that CodeAssist avoids the daemon entirely and runs tools in-process, whereas Termux would still use Gradle's standard architecture. CodeAssist's approach is more lightweight but less compatible with existing Gradle builds. If you need full Gradle compatibility, AIDE or Termux might be better, but they sacrifice the lightweight, integrated experience that CodeAssist aims for.

Maintenance and Licensing: GPL-3.0 and Active Development

The project is licensed under GPL-3.0, which means any derivative works must also be licensed under GPL-3.0 if distributed. This has implications if you modify CodeAssist and share it, but it does not restrict your use of the IDE to build your own apps. The repository is not archived, and the last push was in August 2026, with recent releases v3.9.9, v3.9.8, and v3.9.7. The README indicates an automated workflow that regenerates badges and benchmark numbers on each release, suggesting a disciplined maintenance process. The test suite reports 3217 tests passing across 499 suites, with 0 failing and 2 skipped. This is a sign of ongoing quality control. However, as an experimental project, you should expect breaking changes between releases. The documentation is comprehensive, with several docs files covering architecture, modules, extension points, and language support. Upgrade cost is not explicitly documented, but the presence of a regression test suite and CI suggests that regressions are caught. You should check the release notes for each version to understand what changed.

Editorial conclusion

Adopt CodeAssist if you need to edit and build Android or Java projects entirely on a phone or tablet, especially for quick fixes or learning, and you accept an experimental tool that is not a drop-in Gradle replacement. Do not use it for large production projects that depend on the full Gradle ecosystem, custom plugins, or exact build compatibility. Before relying on it, verify that your project's build scripts and dependencies work with its declarative project model, check the current state of Kotlin completion (beta), and review the GPL-3.0 license implications for distributing any modified versions. The project is actively maintained with recent releases, but its architecture deliberately diverges from Gradle, so test a small project first and confirm that the on-device toolchain produces APKs that match your signing and packaging requirements.

Official sources

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