Background: a fixed world map. Bangladesh is highlighted because ADT is built and validated in Dhaka — the only place this project's evidence names.

ARM64 Android Development Toolchain

ADTarm64

Android development on Linux ARM64 — without an x86_64-only Studio.

AOSP-sourced · native aarch64 · real-device validated

ADT provides a practical Android and Flutter toolchain for Linux ARM64 environments, including Termux + PRoot Debian on ARM64 Android devices. Prepare, build, sign, install, inspect, debug and validate Android applications — the CLI toolchain is the canonical path; GUI/X11 support is optional.

Get started Repository Releases

device25053RT47C · onyx
android16 · API 36 · arm64-v8a
soc / gpuSnapdragon 8s Gen 4 · Adreno 825
hostTermux + PRoot Debian · aarch64

01What is ADT?

Google's Linux SDK host binaries are x86_64. ADT builds the native host tools from official AOSP source for aarch64/glibc, keeps offline-installable verified artifacts, and validates the whole pipeline on a real physical device.

What it is

Native ARM64 Android SDK build-tools and platform-tools, built from AOSP source, plus the host toolchain around them: JDK, CMake, Ninja, NDK shims and Flutter/Dart support.

Why it exists

An ARM64 machine — including an Android phone running Termux + PRoot Debian — should be able to produce, sign, install and validate real APKs, with no x86_64 host in the loop.

Who it is for

Developers on ARM64 Linux — Android devices via Termux/PRoot, Asahi Linux, ARM64 servers and boards — who need a complete, honest Android toolchain.

Build

aapt2 · aidl · Gradle/Flutter produce the APK

Sign

zipalign · apksigner sign and verify

Install

native adb pushes to a physical device

Verify

arm64-v8a selected · app alive · logs clean

02Features

Tools that only need a JVM execution path are architecture-independent at the Java level; everything else is a native aarch64 binary, built from source, or shimmed — and documented as such.

01SDK build-tools

ARM64-native aapt, aapt2, aidl, zipalign, dexdump and split-select, built from AOSP source for linux-arm64.

02Platform-tools

ARM64-native adb, fastboot and the full platform-tools set, used in the real-device validation.

03Host toolchain

GCC/Clang, CMake, Ninja and Make for native builds, with Git and source-management tooling.

04JVM tool paths

JDK plus apksigner, d8 and R8 through their JVM execution paths — architecture-independent.

05Flutter & Dart

Flutter and Dart alongside Android SDK platforms for application builds on ARM64.

06Offline artifacts

SHA256-verified ARM64 tarballs for expensive builds — install without rebuilding from source.

03Toolchain

Every component is classified by how it actually runs — a tool is not marked supported simply because it exists upstream.

Layer	Tools	Execution path	Status
build-tools 35.0.2	`aapt` `aapt2` `aidl` `zipalign` `dexdump` `split-select`	native ARM64, offline artifact	Verified
build-tools 36.0.0	`aapt2` `aidl` `zipalign` …	native ARM64, offline artifact	Verified
build-tools 37.0.0	`aapt2` `aidl` `zipalign` …	native ARM64, GitHub Release	Verified
platform-tools 35.0.2	`adb` `fastboot`	native ARM64, offline artifact	Verified
NDK `27.2.12479018`	`llvm-strip` shim	shim → system ARM64 llvm-strip	Verified
`apksigner` · `d8` · R8 · `sdkmanager`	signing · dex · shrink · packages	JVM, architecture-independent	Verified
cmdline-tools · platforms	`sdkmanager` downloads	Google-hosted, network needed	Verified
build-tools 35.0.1 · 34.x	older patches, deliberately not built	superseded by verified versions	Not yet tested

Per-version AOSP tags, CI runs and notes are tracked in versions.json. Everyday commands for every tool live in COMMANDS.md.

versions.json Command reference

04Installation

Works on any aarch64 Linux with glibc — the validated target is Termux + PRoot Debian on an ARM64 phone; Asahi, Raspberry Pi and ARM64 servers follow the same path. Idempotent: re-running updates an existing clone and skips what is already installed.

# one-liner — fetches the repo and runs the whole bootstrap unattended
curl -fsSL https://raw.githubusercontent.com/soobujmiah/adt/main/install.sh | bash
source ~/.bashrc

# from a clone — guided (asks before each step) or fully automatic
git clone --depth 1 https://github.com/soobujmiah/adt.git && cd adt
./setup.sh                    # guided

./setup.sh bootstrap --auto   # unattended, zero prompts

# verify afterwards — pinpoints the broken piece if anything misbehaves
./setup.sh doctor

Fully offline

build-tools and platform-tools 35.0.2, build-tools 36.0.0 (checked-in, SHA256-verified artifacts), NDK/CMake shims.

Network needed

cmdline-tools (Google zip) and platforms;android-* — any other build-tools version builds from AOSP source (~2–4 GB, ~15–30 min).

Validated profile

One command installs the exact verified bundle: ./setup.sh install-profile validated — build-tools 35.0.2 + NDK 27.2 + android-36.

05Workflows

The everyday developer paths. Exact commands — including wireless adb pairing, which trips most people — are in COMMANDS.md.

ADT Pipeline and Closed-Loop Automation Diagram

ABuild workflow

Native ARM64 aapt2/aidl compile resources and AIDL; Gradle or Flutter assemble the APK. On Termux, Android-targeted native code compiles with Termux Clang and an Android target triple.

Native build guide →

BAPK workflow

Package → align → inspect: aapt2 links resources, zipalign aligns the APK, dexdump inspects DEX. The validated Flutter/Gradle build finished in 1m 21s on the test device.

Validation record →

CSigning

apksigner (JVM, Debian-packaged — no native rebuild needed) signs and verifies APKs on ARM64. Used in the validated end-to-end pipeline.

Signing commands →

DADB & device

Native adb over USB or wireless debugging: install, launch, logcat, shell. Pairing and connect use different ports — COMMANDS.md documents the exact sequence.

ADB commands →

EClosed-loop automation

Current verified status: manual/scripted on-device execution. Potential future capability: authorized agent loops modifying code, building via ADT, deploying to the host device, and evaluating logcat for iterative fixes.

Handoff doc →

06Evidence — real results

The strongest test is the full path, not the presence of binaries. On 2026-09-01 this chain ran end-to-end on a real physical device:

native source → ARM64 shared library → APK packaging → signing →
ADB installation → ARM64 ABI selection → JNI loading → native execution →
log output → process remains alive

# final build      BUILD SUCCESSFUL in 1m 21s   (60 actionable tasks)
# install         adb install -r app-debug.apk → Success
# abi             Device ABI: arm64-v8a · APK primaryCpuAbi: arm64-v8a
# runtime         PID observed · crash/ANR scan clean · app alive

Validation record

REAL_DEVICE_BUILD_VALIDATION.md — status VERIFIED / CLOSED for the validated project state. Device topology, commands and outputs recorded in-repo.

Open record →

Releases

v35.0.2, v36.0.0 and v37.0.0 published by CI (build.yml on tags) with ARM64 tarballs attached and confirmed via gh release view.

Open releases →

Version registry

versions.json records per-version status, AOSP tag, CI run and honest notes — including what was deliberately not built and why.

Open registry →

Shared evidence vocabulary — Verified · Measured · Observed · Experimental · Not yet tested · Not supported:

Verified Measured Observed Experimental Not yet tested Not supported

Honesty boundary: the full chain is physically validated on one device family (Redmi Turbo 4 Pro, PRoot Debian). On any other host the scripts are identical, but "should work" is not "verified" — run ./setup.sh doctor as your first evidence check.

07ADT and Ternux — two layers of one ARM64 story

ADT — this repository

The development-toolchain layer: native SDK build-tools, platform-tools, signing and ADB workflows for Linux ARM64.

Ternux — the desktop layer

A no-root Debian + Xfce4 desktop on Android via PRoot and Termux:X11, with GPU acceleration (Mesa/Zink, Turnip on Adreno).

Ternux website →

Physical host target

The host Android device is the actual physical target machine. PRoot/Termux serves as the user-space environment. Builds run on bare metal; execution and debugging target that physical phone, not an emulator or external PC.

Verified vs experimental

ADT's pipeline is verified on the shared Termux + PRoot Debian host; Ternux verifies the desktop and GPU stack separately. Combined cross-project workflows are observed to coexist but are not yet tested formally — they remain experimental.

Ternux website Ternux repository

08Documentation

Simple first in the README; technical depth lives in the repository, linked here directly so what you read matches what the toolchain actually does.

README

What ADT is, evidence, the Ternux relationship and limits — the fast path.

Read →

Technical reference

Tool roles, native build strategy, NDK/PRoot reality, setup.sh surface, profiles.

Read →

Command reference

Everyday commands for every installed tool, device pairing, troubleshooting.

Read →

Validation records

Real-device evidence and dated session records, kept next to the work they describe.

Read →