u/Halmonster

I’ve been working on Code on the Go, an Android IDE that runs entirely on an Android phone.

One of the things I want to share with this community specifically is how we approached Kotlin support. Running a full LSP implementation on a phone requires making decisions you don't face on a workstation: memory constraints, thermal limits, and a soft keyboard that changes how a developer interacts with autocomplete and inline diagnostics.

Code on the Go runs Kotlin LSP to provide real-time editor feedback: completions, error highlighting, and inline diagnostics as you type. On mid-range hardware this required careful management of the language server process lifecycle to avoid the LSP becoming a battery and memory drain during longer sessions. We're still refining this in future work and welcome feedback from Kotlin developers who try it.

The broader context: Code on the Go includes a Gradle build system that compiles on-device (including on 32-bit ARM hardware), a JDWP-based debugger that runs without ADB, and Sketch-to-UI, which converts a photo of a hand-drawn layout into Android XML using an on-device TFLite model and other features to make professional-grade development tools available and easy to use on a phone.

One of our pre-release users wrote a Sinhala/English keyboard app in Kotlin using Code on the Go and published it to the Play Store from his phone. This served as a full pipeline test we needed for Google Play Store compatibility.

APK

Github source

Code on the Go is free and open-source. Curious how others are handling LSP lifecycle or memory limits on mobile? And welcome any other questions about the work we’ve been doing.

-Hal

Disclosure: I am the CTO and one of the developers of this project.

Conventional Android debugging assumes two machines connected via ADB. Because our mission is to empower people who (1) only have a phone not a laptop or desktop, and (2) don't have much network infrastructure, that means we needed a debugger running entirely on one device, with no external connection. Here is how we solved it, and what we had to do to make it happen without rooting the device. 

My team has been working on Code on the Go (CoGo), a GPLv3-based IDE that runs locally on Android phones. While there are many code editors for mobile, we wanted to build a true development environment that handles the full lifecycle (full Java and Kotlin support, Gradle builds, Git, and specifically on-device debugging) without requiring a workstation or a cloud server.

The key problem: ADB's client-server-daemon architecture is not just a convenience layer; it is load-bearing. The JDWP traffic that carries debug commands and responses between your IDE and the Android runtime is brokered through ADB. Strip ADB out and you lose the transport layer entirely.

Our solution was to attach the JDWP agent directly to the target process at launch and route its output to our debugger over a local socket, bypassing ADB completely. In practice this means we launch the app with the JDWP agent running in client mode, pointing at a socket address our IDE is already listening on. The handshake happens locally, the IDE connects, and from that point the debug session behaves like any other JDWP session: breakpoints, step execution, variable inspection and live editing, VM control, thread management.

Getting permission to do this without root was the harder problem - Android security policies are there for a reason. Attaching to another process and manipulating its launch flags requires privileges a normal app does not have. We solved this by adapting components from the Shizuku project, scoping them exclusively to our own processes rather than using Shizuku's general-purpose privilege broker model. The target app uses the standard debuggable flag in its AndroidManifest; we are not doing anything unusual on that side. The privilege requirement is on the IDE side, not the app under test.

One thing we want to be transparent about: this approach does have implications worth understanding. While the debuggable flag in a debug build is expected and standard, the Shizuku-based access on the IDE side is more unusual, and we have been deliberate about scoping it narrowly as possible. If anyone wants to dig into that part of the implementation, the relevant code is in the repo and we are happy to discuss the security model in the comments.

The resulting session supports breakpoints, step execution, variable inspection and live editing, VM control, thread inspection, and source navigation. 

One of our pre-release community members, whose phone is his only development device, used CoGo to build Sriboard, a Sinhala and English keyboard app, and published it to the Play Store entirely from his phone. 

That said, there are some rough edges worth knowing about. Running the LSP, the build system, and a debug session concurrently on a low- or even mid-range phone creates memory pressure we have not yet fully solved. We are also still working on attach-to-process debugging for apps that are already running. If anyone has already solved this in a similar context, we'd like to talk with you.

Where to find it:

Source  License: GPLv3

APK

Code on the Go is a free, open-source Android IDE that runs entirely on a phone. It is built by App Dev for All, a small not-for-profit. No ads, no tracking, no monetization model.

Happy to go deep on the JDWP implementation, the Shizuku adaptation, the memory management approach, or anything else in the stack.

-Hal