The Itel P12. Android 6. A screen that felt small even by the standards of the time. A processor that made no promises about speed and kept every single one of them.
That was my development machine. Not a metaphor — literally the machine on which I learned Java, wrote code, and compiled my first Android APKs. I was studying Forestry and Environmental Management at Mzuzu University at the time. Nobody around me was writing software. The phone was not bought for programming. It just happened to be Android, and Android happened to be what I needed.
A phone spec sheet that shouldn't work
~/device/itel-p12
APKBuilder was the tool. It is an Android app — you install it from the Play Store, and it gives you an editor and a compiler running entirely on-device. No PC required. No Android Studio. No Gradle. You open the app, write Java, tap compile, and either get an APK or get an error. That was the whole workflow.
On an Itel P12, compiling was not fast. You would tap the build button and wait. Sometimes a long time. And then either an APK appeared, or an error message told you something you already suspected — that a semicolon was missing, or a class was not closed properly, or you had called a method that did not exist.
What strikes me now is how honest that experience was. The compiler told you the truth. It did not suggest alternatives, it did not autocomplete, it did not underline your mistakes in real time. You wrote the code. You built it. You found out what was wrong when the build failed. That forced a kind of careful reading I might not have developed with a modern IDE watching over my shoulder.
The first build that succeeded
The first Android app I compiled myself had one screen. A TextView that displayed
text. A Button that did something when pressed. The layout was written by hand in XML.
The activity logic was written by hand in Java. No templates. No wizard. Just a blank file and
the knowledge — barely assembled at that point — of what had to go inside it.
When the build succeeded and the APK installed on the same phone I had just written the code on, I stayed on that screen for a while. The app was genuinely useless. It did almost nothing. But the fact that it existed — that I had produced it, on that device, through nothing but typing and reading and fixing errors — felt disproportionately significant.
The build cycle on a low-end phone
Write Java in APKBuilder → tap Build → wait → read the error → fix it → tap Build again. No hot reload. No incremental compilation. Every change, a full rebuild. Slow feedback made every line deliberate. You did not write code carelessly when a mistake cost you another two-minute wait.
After that first one, more followed. I wrote apps for friends — small utilities, things that
solved specific problems they had. Computer skills quiz apps. Personal offline tools. Each one
was boilerplate from top to bottom. Every Activity scaffolded by hand.
Every layout element written individually. Every Intent, every
SharedPreferences call, every string — typed out in full, every time.
It sounds tedious. It was tedious. It was also, in retrospect, the best possible way to internalize what Android actually does. When you have written the same boilerplate fifty times with your thumbs, it stops being boilerplate. It becomes structure you understand.
What the constraint gave me
People who learned Android on a PC with a large screen, Android Studio, and Gradle had something I did not — and I had something they did not.
What I had was no scaffolding. Every file in every project was one I had personally created and understood. There were no generated files I skipped past. No configuration I did not touch because the wizard handled it. The apps were simple, but they were entirely mine.
The Itel P12 is long gone now. The APKs I compiled on it have mostly been replaced by better versions built with better tools on better hardware. But the understanding of what an Android app actually is — the files, the manifest, the activity lifecycle, the way layouts connect to code — that came from that phone, and it has not left.
If you are reading this on a low-end Android phone wondering whether you can actually build something real on it: you can. It will be slower than you want. The tools will frustrate you. The constraint is real. But the constraint will also make you read every line you write, because on a slow machine with no autocomplete, that is the only way to write code that actually compiles.