What if your Android phone could be more than the device you build for?
What if it could also be the Linux development environment you build on, while remaining connected to a real Android device for the complete build, test, debug, and validation cycle?
That is the direction I am exploring with two projects:
- Ternux — a Debian + Xfce4 Linux workspace on Android using Termux and PRoot
- ADT — a native ARM64 Android development toolchain for Linux
Together, they create an interesting workflow:
Write / Modify Code
↓
Build
↓
Sign
↓
ADB Install
↓
Real Device
↓
Test
↓
Read Logs
↓
Debug
↓
Fix
↓
Rebuild
↓
Repeat
The important part is the loop.
Ternux: the Linux workspace
Ternux provides a Debian + Xfce4 Linux environment directly on an ARM64 Android device through Termux and PRoot.
It provides the userspace needed for development while using the Android device's existing kernel.
The environment can include:
- Debian ARM64
- Xfce4
- Termux:X11
- Linux development tools
- Git
- compilers and build tools
- Mesa graphics
- Zink → Turnip on supported Adreno devices
- Vulkan tools
- optional LLM and development workloads
No Android root is required.
The goal is not to emulate another computer.
It is to turn the Android device itself into a portable Linux workspace.
ADT: the Android development layer
Ternux provides the workspace.
ADT provides the Android development toolchain.
ADT targets Linux ARM64 environments and provides native ARM64 Android build and platform tooling, including:
- "aapt"
- "aapt2"
- "aidl"
- "zipalign"
- "dexdump"
- "adb"
- "fastboot"
- "apksigner"
- "d8"
- Android platforms
- supporting JDK/CMake/Ninja tooling
The important distinction is that ADT is not simply a collection of Android binaries.
The host tools are built for the ARM64 Linux environment.
That makes an ARM64 Android phone running Ternux a viable host for the development workflow.
The real-device connection changes the workflow
A build environment becomes much more useful when it can communicate with the actual Android device.
ADB provides that bridge.
From the Linux/PRoot environment, the development workflow can communicate with an Android device through ADB when the device is appropriately paired and accessible.
That means the developer does not have to stop after:
source → compile → APK
The APK can continue through:
APK
↓
ADB
↓
Install
↓
Launch
↓
Test on real hardware
↓
Collect logs
↓
Diagnose
This is important because a successful compilation does not prove that an application works correctly on the target device.
Real-device testing exposes things that compilation alone cannot:
- ABI problems
- JNI loading failures
- runtime crashes
- permission issues
- device-specific behavior
- graphics/runtime problems
- process failures
- incorrect assumptions about the Android environment
Manual development loop
The simplest version is completely manual.
A developer can work inside Ternux, use ADT to build the application, connect to the device through ADB, install the APK, run it, inspect the result, and then return to the source.
Conceptually:
┌──────────────┐
│ Edit source │
└──────┬───────┘
↓
┌──────────────┐
│ Build + Sign │
└──────┬───────┘
↓
┌──────────────┐
│ ADB Install │
└──────┬───────┘
↓
┌──────────────┐
│ Real Device │
└──────┬───────┘
↓
┌──────────────┐
│ Test + Logs │
└──────┬───────┘
↓
┌──────────────┐
│ Debug + Fix │
└──────┬───────┘
│
└──────────→ Build again
This creates a short feedback loop between development and reality.
Why the real device matters
A simulator or static build check can answer some questions.
A physical device answers different questions.
For example:
«Did the native library actually load?»
«Did Android select the expected "arm64-v8a" binary?»
«Does the application process remain alive?»
«What does "logcat" report?»
«Does the application behave correctly on this specific Android version and hardware?»
Those questions require execution.
That is why ADT's validation work focuses on the complete path rather than simply checking whether binaries exist.
The documented validation chain is:
Native source
↓
ARM64 shared library
↓
APK packaging
↓
Signing
↓
ADB installation
↓
ARM64 ABI selection
↓
JNI loading
↓
Native execution
↓
Log output
↓
Process remains alive
From manual testing to agent-assisted development
This is where the architecture becomes more interesting.
Once the development environment, build tools, ADB access, logs, and source tree are available from the same Linux workspace, an agent can potentially operate the same feedback loop.
Instead of:
Human:
build → install → test → read logs → diagnose → fix
the workflow can become:
Agent
↓
Modify code
↓
Build
↓
Install with ADB
↓
Run/test
↓
Collect logs
↓
Analyze failure
↓
Modify code
↓
Build again
↓
Repeat
The agent does not need a special imaginary development environment.
It can use the same tools a developer uses.
For example, an agent operating inside the Linux/PRoot environment could conceptually invoke:
./gradlew assembleDebug
adb install -r app-debug.apk
adb shell am force-stop com.example.app
adb shell monkey -p com.example.app 1
adb logcat -d
Then it can inspect the output, identify a failure, make a controlled change, and start another iteration.
The important boundary: autonomy needs control
Autonomous execution does not mean giving an agent unrestricted access to everything on the phone.
A safer architecture is:
Agent
│
▼
Ternux / PRoot
│
┌────────┴────────┐
│ │
Source Toolchain
│ │
└────────┬────────┘
▼
ADB
│
▼
Android Device
The agent should operate within explicit permissions and a defined task boundary.
For example:
Task
↓
Build
↓
Install
↓
Run test
↓
Collect evidence
↓
Diagnose
↓
Propose/apply fix
↓
Re-test
A human can remain the authority over what the agent is allowed to change, while the repetitive build/test/debug cycle becomes automatable.
Why I find this interesting
The interesting idea is not simply:
"Linux on Android."
And it is not simply:
"Android development on ARM64."
It is the combination:
«A portable ARM64 development environment connected to real Android hardware, with a feedback loop that can be operated manually or progressively automated by development agents.»
That changes the phone from a passive target into an active development workstation.
Two projects, one workflow
The architecture can be summarized simply:
Android Phone
│
Termux + PRoot
│
┌───────┴───────┐
│ │
Ternux ADT
│ │
Linux workspace Android tooling
│ │
└───────┬───────┘
│
ADB
│
▼
Real Android Device
│
Test / Logs / Debug
│
└──────→ Fix
Ternux provides the Linux environment.
ADT provides the Android development toolchain.
ADB provides the device connection.
The real device provides execution evidence.
And an agent can potentially sit above the workflow and automate the repetitive parts.
What I am exploring next
The next step is not simply adding more tools.
It is making the feedback loop increasingly reproducible:
Build → Install → Test → Observe → Diagnose → Fix → Validate
with clear evidence at every stage.
That could eventually make an ARM64 Android phone a surprisingly capable development platform—not because it replaces every desktop workflow, but because it makes development, testing, and automation possible on the same physical hardware.
Projects
- "Ternux" (https://github.com/soobujmiah/ternux)
- "ADT" (https://github.com/soobujmiah/adt)
- "Portfolio" (https://soobujmiah.github.io)
I am building this in public and documenting what is verified, what is observed, what is experimental, and what still needs testing.
