Most "roadmaps" for Android are a flat list of keywords: Kotlin, Compose, Coroutines, Room, Retrofit, MVVM. A flat list hides the thing that actually matters — that these topics have an order, and learning them out of order is why most people stall. You can't understand a `ViewModel` before you understand the `Activity` lifecycle it survives. You can't understand `Coroutines` before you understand what a thread is and why blocking the main one is bad. The roadmap's value is the arrows, not the boxes.
The stages, in dependency order
- 1 · Foundation — Java and Kotlin, and Android Studio. The language and the tool; everything else is written in and built with these
- 2 · Core concepts — Activity, Service, BroadcastReceiver, ContentProvider, Intents, and the Activity lifecycle. This is how an Android app is *shaped*, before you ever draw a pixel
- 3 · UI — Views/ViewGroups, RecyclerView, Fragments, and (later) Compose. How pixels get on screen and how lists stay smooth
- 4 · Persistence — SharedPreferences, DataStore, Room, files. How data survives process death
- 5 · Threading & concurrency — threads, then Coroutines, then Flow, then WorkManager. The #1 crash source and the #1 interview topic
- 6 · Networking — OkHttp, Retrofit, JSON, OAuth, status codes. Talking to the outside world reliably
- 7 · Architecture — MVVM/MVI, dependency injection, Clean Architecture. How code stays maintainable as it scales
- 8 · Testing & quality — unit vs instrumentation tests, debugging, memory leaks. Code you can trust tomorrow
- 9 · Advanced & release — Compose, Firebase, security, signing, the Play Store. The final mile to production
Why order beats completeness
A roadmap that lists a hundred topics in no particular order produces engineers who know the names of things but not the relationships between them — who can write a `when` expression but not explain why a `Service` got killed. The fix is to treat each stage as a prerequisite: you are never asked to understand something that assumes a topic you haven't reached yet. That's what makes the path survivable and, more importantly, what makes each new stage feel like an unlock rather than a fresh wall.
How to actually use it
- Work top-to-bottom; don't skip ahead — stage N is the foundation for stage N+1, and a gap at stage 3 will quietly destabilise you at stage 7
- Revisit a stage when you hit a wall later — the wall is usually a prerequisite you glossed over, not the current topic
- Each stage has a small, runnable example associated with it (the repos in this collection map one-to-one onto stages 1–7), so 'learn it' always means 'build and run something'
- Measure progress by what you can build, not by how many checkboxes are ticked
In this note
Prefer it hands-on?
This note has a matching interactive topic with diagrams and a runnable repo.
References & resources