Zero-Desktop Android Dev: Compiling, Dexing, and Signing API 36 APKs On-Device with Termux

Chibuike Okoye — Thu, 06 Aug 2026 02:54:00 +0000

Who says you need a heavy desktop setup and bloated IDEs just to build Android apps?

I set out to prove that you can assemble, dex, package, and sign a native Android application directly on a mobile device targeting compileSdk 36 using pure CLI binaries inside Termux.

🛠️ The On-Device Build Pipeline

Instead of relying on desktop Gradle or Android Studio, the entire build toolchain was executed on-device:

Compilation (ecj): Java source files compiled directly against the android-36 platform JAR.
Dexing (d8): Converting compiled Java bytecode into Dalvik Executable (classes.dex).
Resource Linking (aapt2): Compiling and packaging resources, manifest, and assets into an unsigned APK container.
Binary Signing (apksigner): Generating a local keystore and signing the APK with proper v2/v3 signature schemes.

🚀 The Result

The generated binary installed cleanly and launched smoothly with zero runtime crashes or classloader errors—proving that full-stack Android compilation can live natively on ARM hardware.

Next step: Wiring this CLI toolchain up to a web-based Monaco Editor running on a local Node server right inside Termux to create a lightweight, self-hosted web IDE!

android #mobiledevelopment #termux #buildtools

Building an Edge-Computed Web Ad Network with Cloudflare Workers and Workers AI

Chibuike Okoye — Sat, 25 Jul 2026 08:26:21 +0000

Monetizing web traffic shouldn't mean slowing down your site with bloated ad scripts and long network round-trips.

When building Connectgold, my goal was to design a lightweight web ad server that executes auctions at the edge with sub-10ms response times—while giving publishers fast, transparent access to earnings.

Here is a look at the architecture behind it and how edge workers make ultra-fast ad rendering possible.

🏗️ The Problem with Traditional Ad Delivery

Standard web ad tags usually go through multiple heavy redirects and centralized server checks before rendering creative. This introduces layout shifts (CLS), drags down Core Web Vitals, and degrades user experience.

By moving the auction engine to edge nodes, ad requests are evaluated closest to the visitor, eliminating unnecessary cross-region network hops.

⚡ Core Features & Architecture

1. Edge Auction Engine

Requests are processed directly at edge isolates. The worker evaluates active campaign inventory, checks user consent status, and streams back lightweight HTML banners or native card payloads instantly.

2. Fair Campaign Rotation

To ensure all active advertisers receive equal opportunity and visibility—regardless of bid size—the server uses a balanced rotation model across funded campaign pools.

3. Dynamic Copy via Workers AI

To make ad units contextually relevant without bloating client scripts, the server integrates Workers AI. It dynamically generates localized ad headlines and call-to-action (CTA) text tailored to the visitor’s region and niche product keywords.

4. OpenRTB & Header Bidding Support

The engine includes standard endpoint routes for easy integration into standard OpenRTB 2.5 web header bidding pipelines.

5. Automated Local Payments

Handling advertiser balances and publisher payouts can be a major friction point. The backend integrates direct wallet funding and payout processing via Paystack, supporting instant account verification and seamless transfers.

💬 Looking for Community Feedback!

As I continue optimizing the platform, I'd love to hear from other web engineers:

What strategies do you use to eliminate Cumulative Layout Shift (CLS) when injecting asynchronous ad containers?
Have you experimented with edge-computed auctions or Workers AI in production?

Drop your thoughts or questions in the comments below! 👇

DEV Community: Chibuike Okoye