How I Build Android Software Without a PC
I don't have a PC.
For most Android development, that sounds like a pretty inconvenient starting point.
I still wanted to build Android software, though. So instead of waiting until I had better hardware, I started figuring out how much of the workflow I could move onto a phone.
Eventually, this became more than an experiment. I started building actual Android projects this way, including AppBlur, while keeping the source and project evidence public on GitHub.
This is how that workflow came together, what I learned from it, and where the approach starts to hit its limits.
The constraint
My main development device is an Android phone with limited hardware.
That means I can't just open Android Studio, start an emulator, run a large build and forget about the machine underneath it.
I had to think about the workflow differently.
The phone became the place where I:
- write and edit code
- manage project files
- run local tools where practical
- test applications
- inspect the results
- manage the development process
GitHub became the place where I could keep the source public, maintain project history and use remote infrastructure when needed.
The important part was not making the phone magically behave like a PC.
I was figuring out which parts of development actually needed to happen on the phone and which parts could be handled elsewhere.
What does the workflow actually look like?
At a high level, it became:
Phone → source code → GitHub → build/release → Android device
The phone is still the main development environment.
GitHub isn't replacing the development process. It gives me a reliable place to keep the source and handle parts of the workflow that are difficult to do locally.
The result is what matters most: an actual application that I can install and run on the same kind of device I used to build it.
The first problem: editing a real project on a phone
Writing code on a touchscreen is obviously not the same experience as sitting at a desktop keyboard.
But typing wasn't the hardest part.
The harder problem was managing a real project.
Once an Android project grows beyond a few files, you have manifests, resources, Gradle configuration, dependencies, assets and other pieces that all need to work together.
So I started treating my phone more like a small development workstation rather than simply a code editor.
The workflow became:
- edit the project
- inspect the files
- run what I can locally
- test on the device
- commit the changes
- use GitHub as the public source of truth
It isn't the most conventional setup.
It works.
AppBlur became a real test
AppBlur was one of the projects where this approach had to become real instead of remaining an experiment.
The idea is simple: an Android privacy utility that can obscure the display after inactivity.
But implementing it meant dealing with actual Android behavior rather than just creating a UI.
There are services, overlays, lifecycle behavior, timing and the usual Android-specific problems that appear once an application has to interact with the system.
That made it a much better test of the workflow than a simple demo application.
The point wasn't to prove that a phone is better than a PC.
It isn't.
The point was to see how far I could push the hardware I actually had.
The second problem: producing something usable
Development doesn't mean much if the result never becomes an application you can actually run.
That's why I care about the complete path from source code to a working Android application.
I keep the source and project evidence public in my repositories, and the repositories also contain screenshots showing the actual applications and interfaces.
That gives someone two ways to look at the work:
Visual: see what the application actually looks like.
Technical: inspect the source and project structure.
I prefer this over simply saying that something works.
You can actually look at it.
What I learned
The biggest lesson wasn't:
«"You don't need a PC."»
I wouldn't make that claim.
A better conclusion is:
«Constraints change the architecture of your workflow.»
Instead of expecting one machine to handle everything, I started dividing the work between the tools available to me.
Phone
Development, editing, testing and control.
GitHub
Source control, public evidence and remote project infrastructure.
Android device
Real-world testing.
That separation made the workflow much more practical.
It changed how I think about tooling
When resources are limited, convenience becomes an engineering problem.
You start asking questions that are easy to ignore when you have a powerful workstation:
- What actually needs to run locally?
- What can be automated?
- What can be moved to remote infrastructure?
- How do I verify the result?
- What happens when something fails?
- How do I keep the source of truth accessible?
Those questions are useful even if I eventually work on a conventional development machine.
The constraint forced me to think about the development process itself.
AI is part of my workflow, but it isn't the workflow
I also use AI tools while developing.
That doesn't mean I treat generated code as finished code.
My workflow is closer to:
requirements → architecture → AI-assisted implementation → code review → integration → debugging → testing → build → release
If the generated code doesn't compile, behaves incorrectly, breaks another part of the project or doesn't fit the architecture, it isn't useful just because an AI produced it.
The code still has to work.
That distinction has become increasingly important as I work on more complex projects.
Where this approach works well
For me, this workflow works particularly well for:
- Android utilities
- experimentation
- prototyping
- learning unfamiliar technologies
- small and medium-sized projects
- workflows where remote infrastructure can handle heavier tasks
It also makes experimentation cheaper.
If I have an idea, I don't necessarily have to wait until I have the ideal development setup before trying it.
Where it gets difficult
There are obvious limits.
A phone doesn't suddenly become a workstation with unlimited RAM and CPU.
Large builds, heavy tooling, complicated debugging and software that depends heavily on desktop environments can become difficult.
So I don't see this as a universal replacement for conventional development.
It's simply the environment I had, and I wanted to find out what I could build inside it.
More than one project
AppBlur isn't the only thing I've explored this way.
I've also worked on Android tooling, systems, graphics, AI and robotics-related experiments.
Some are shipped.
Some are active.
Some are architectural concepts.
Some are experiments.
I deliberately keep those categories separate because I don't want an unfinished experiment to look like a finished product.
The goal isn't to make every project look impressive.
The goal is to make the actual state of the work clear.
What I'm interested in next
The interesting part of this experiment isn't really the phone itself.
It's the idea that development constraints can lead to different engineering decisions.
A limited environment forces you to question assumptions about tooling, automation, testing and infrastructure.
That's something I want to keep exploring across Android, systems, graphics and AI.
Inspect the work
I keep the source and project evidence public.
You don't have to take my word for what I built.
You can inspect the repositories and the applications themselves.
The interesting question for me isn't whether a phone is better than a PC.
It isn't.
The interesting question is:
How much can you actually build when you stop waiting for ideal conditions?
Top comments (0)