TLDR

Introducing a Lightweight Android Build tool. A very extensible and simple project that is dedicated for the android build process. 

I am about to yap for the next few paragraphs about the backstory so you can skip to the technical details if you do not need it or go to the git project.

Why?

I love programming, especially on Android! Over the years, however, my experience developing apps hasn’t always been smooth sailing. My development setups often feel like they could crumble at any moment. Unlike seemingly everyone else, I don’t have a supercomputer and a gigabit connection to run Android Studio.

My Little story.

Back in 2018, I was a high school student with big dreams for an upcoming science fair project. The idea was to create a portable chemistry simulation right at your fingertips (I know it sounds a bit ambitious, but I knew I could pull it off). I teamed up with a partner for the project, He was responsible for the chemistry research, while I would handle the programming. We designed some algorithms to balance equations, calculate energy levels and general simulation stuff. All this without internet because East Africa.

Finally, after a few weeks, our science patron was to hand us a modem for internet research. This is to be shared among all groups. While others needed the modem for research or perhaps to message the neighboring girls' school , we needed it for ANDROID STUDIO!

Getting Android Studio is fairly simple—just head to its release page, download, and install. But in my situation, it wasn’t quite that easy. Let me tell you about the modem. If you know how modems work, at least in my country, they use ISP SIM cards, which means they are metered. Our patron had purchased a whopping 1 GB of data for a 30-day duration. Yes, that’s just 1024 MB! This data had to be shared among all the groups, allowing everyone to download the images and documents they needed , and maybe some bit of gooning.

Now, back to our little adventure. We were "lucky" enough to receive the modem fifth in line. We got to work and managed to download the JDK (over 100 MB)—easy enough! But Android Studio didn’t even reach halfway before we had already depleted the allocated data. Still five more groups to go and we had already wasted the entire thing. So, we reluctantly passed the modem down the line, hoping the next group would notice and return it to our patron. We had to speak to our IT teacher about the situation, and they offered to install Java and Android Studio at home since he had Wi-Fi , and we could work from his laptop.

Boss Fight and Shattered dreams.

• Java Installed
• Android Studio Installed
• Agreed to borrow the laptop during after-class free time and weekends.
• Done my assignments.
• Life is good!

So, we finally got the laptop, booted up Android Studio, created a new project, and we were ready to ball! I had written some code on paper during those boring afternoon classes because I knew we didn't have enough time. Just a normal day in Android Studio with red squiggly lines everywhere.

"This is just a Hello World project, so we should just hit compile and everything will be fine," - Probably me.

I hit run, and oh boy, horrors.

"This is just a Hello World project! Why do you need the internet ?" - Probably annoyed me.

Luckily, our chemistry teacher was there with us and offered to hotspot. Fifteen minutes later, it compiled successfully. I know, very lucky bastards ! But spending 15 minutes just to compile in a boarding school where you have a maximum of 2 hours of continuous idle time—time that should probably be spent on assignments—isn't ideal. The next day , a weekend, we faced the same issue. That day, we had uninterrupted access to the modem, so it couldn't have been an internet problem. I basically spent the whole day fighting Gradle. I could have been out with the boys on the field playing, or trying to improve my poor grades in biology. A 16-year-old should never have to worry about Gradle build failures! Spoiler alert: we ended up abandoning the project and switched to a PHP one instead! That dream died that day. Maybe we could have won a Nobel Prize for whatever abomination of algorithms we invented during that adventure.

Why Did the Build Fail?

I don't know, that is a mystery that we will never know.

I had written three apps before without Android Studio, and all this Gradle shenanigans. That is where the entire idea of creating an app for a project came from. I learned Android development through reverse engineering pay-to-win offline Android games. If you know anything about reverse engineering, you often learn how things work to the point where you can just rawdog without appropriate tools. I had these elaborate tools like AAPT, DEX, and Javac that I knew built APKs.

So, why Android Studio? It was supposed to be better—enhancing dev experience, allowing for faster iterations, and catering to real developers, not the caveman tools I had been using. All these IT events and hackathons I attended, people would be flexing their Android Studios, and I wanted to be part of the Android chads. Plus, being in a school setting with very constrained time frames and upcoming science fair deadlines, I thought Android Studio would speed up development.

Fast Forward After High School

I was a very young developer with big dreams, armed with my very own laptop and university Wi-Fi. I could finally join the ranks of those who could tame Android Studio and its Gradle. Except, Android Studio was still massive, and every time I booted it up, the laptop fans would start screaming. I had to chill for about 10 minutes before it finally stabilized, and only then would I know my fate with Gradle. Unfortunately, the laptop didn’t last long because I tried doing something that probably fried the entire motherboard.

Despite not having a machine, I landed a gig for Android development. I took it anyway, as I had this Android smartphone that was clearly overpowered. With an ARMv7 processor, 2.5 GHz, 8 cores , 6 GB of RAM, and 128 GB of "SSD" internal storage, it was a god compared to my last laptop. And what is Android? Linux! I could probably run Android Studio on this device , but why would I do that? This is a lithium-based device, I don't want it to burst into flames in my hand.

I downloaded Termux, installed Java, the individual Android build tools, and Neovim. Of course devs like their libraries a.k.a dependencies. To tackle this, I manually translated the Gradle dependencies and wrote an Ant Maven extension that used Apache Ivy to resolve all the dependencies. I managed to navigate the entire project without needing Gradle at all! I shared my toolkit with one of my bros who also had a potato PC, and he loved it.

The Inspiration

I had become a certified Gradle hater. My bro had seen the light; in a thousand years, he never imagined he would be building Android apps fully offline from VSCode, only requiring an active connection occasionally for new dependencies and to access a large language model. This got me thinking: what if I created a build tool that:

• Could build apps offline
• Was fully extensible
• Had a simple and straightforward workflow
• Didn’t require a supercomputer or a gigabit connection to build a "Hello World" app
• Could run on Termux without bursting into flames
• Was independent of any IDE or editor

This tool could save all developers from this perpetual abuse!

My solution

You remember the Ant extension I developed earlier? I decided to turn it into a standalone project, specifically designed for Android. To build an app, you need to fetch your dependencies (if any), compile the source code into Dalvik bytecode, compile your assets, and bundle everything into an APK, which is just a fancy ZIP file. It’s that simple!

I wrote the first iteration in C, then Zig, and finally Rust . It’s not a skill issue; I just wanted to learn Rust. The first version did everything on its own—just a single binary that would take your source code and produce an APK. However, that approach felt against the spirit of understanding how it works.

The tool ensures that everything you need to build the project is available at all times, and it’s up to you to decide how you want it built. You can compile it manually, write your own build pipeline, or simply use an existing plugin if you prefer. The build process is designed to require at most one plugin to build your app, with maybe an extra custom behavior you can add to the build stages.

Technical details.

LABt consists of an SDK manager, a dependency resolver, and a plugin system.

Sdkmanager

The SDK manager provides basic management for Android SDK packages. These are common packages required for building Android apps, such as AAPT, D8, android.jar, and emulators. Most of these packages are offered by Google, and LABt uses Google as the default repository to fetch them. However, LABt also allows the addition of custom repositories for third-party tools, such as the R55 project I created, which skips passing R.java files to the Java compiler by outputting bytecode directly for the next DEX stage.

Dependency Resolver

LABt features a basic dependency resolver compatible with Maven repositories. It is simple to use and prioritizes caching during resolution. The resolver can detect circular dependencies and resolve conflicts using a "nearest definition wins" approach. This resolver is still in beta, as Maven POM files are quite complex, and we currently handle only a subset of their features. We welcome any feedback or issues that arise.

The plugin system

LABt offers a powerful plugin system designed to be as simple as possible. The system separates plugin execution into six steps, and all plugins are required to specify code that runs in each step. You can use this example plugin.toml for reference. The steps, in order, are:

1. PRE - Good for generating dynamic code (e.g., Protobuf files).
2. AAPT - Compilation of Android assets.
3. COMPILE - Compilation of Java/Kotlin or any language of your choice into bytecode.
4. DEX - Converting the bytecode into a format that Android understands.
5. BUNDLE - Combining all previous outputs into an APK file and signing it.
6. POST - You can perform any action here, such as pushing your app to a device or emulator using ADB.

Plugins are expected to execute independently of each other, meaning there are no dependencies between plugins. In a typical project, you may need at most one plugin to build the project, with perhaps an additional one for custom behavior. However, since we can have an infinite number of plugins under a single project, we need a predictable way to execute each plugin.

Execution steps.

LABt reads all the plugins specified by a project and splits each plugin into its specified stages. It then groups all the stages together. For each stage, LABt sorts the plugin code based on their specified priority. LABt proceeds to execute all the stages in sequential order, eliminating the need to compute a complex task dependency graph. This allows for fast and immediate execution of plugins that is easily debuggable.

Plugins can also specify what files each stage depends on and LABt will only run the stage if the specified files change.

The plugin system also includes Foreign Function Interface (FFI) capabilities, extending the flexibility of the languages you can choose or allowing you to interface with existing native libraries from the SDK manager.

Publishing Plugins

To ensure maximum flexibility to plugin developers we use git as our plugin repository. This means you can manage your plugin versions through Git tags. You just need to provide the repository url and users can:

labt plugin https://gitlab.com/lab-tool/plugins/labt-java@latest

 

The plugin system also comes with FFI capabilities which extends the flexibility of languages you can choose or interface with the existing native libraries from sdkmanager.

You can learn more about the plugin system though the documentation or learn from the first LABt plugin we created for building java based apps.

The Future

There are few things that we may need to add, remove or fix from this project as it evolves. The plan is to make every component stable and working and then afterwards do some optimizations like removing unecessary cargo dependecies. I love this project very much and would appreciate any feedback to make it better.

Can I run Android Studio Now?

No. My pc is still a potato. I use an ISP mobile connection that is very unstable with some breakneck speeds of 500Kbps max. It is very expensive to a point where running android studio for a week will probably push me into poverty. I also don't want to contribute to global warming. Happy hacking!