Android Developer Roadmap 2027: What to Learn, What Interviews Ask, and Where AI Fits

Posted on Oct 31 • Originally published at imayankkumar.com

If you are an Android developer right now, you are probably asking three questions:

The last year did not make this easier. In May 2026, Google said Android UI is now Compose-first and moved the View components that Compose replaces into maintenance mode: critical bug fixes only, no new features, but no plan to remove them. The same day, Android CLI 1.0 went stable so AI agents can build and run Android apps. And Google was reported to be piloting coding interviews where candidates use Gemini.

This post answers all three questions. It is a complete roadmap for 2027: what to learn, in what order, how deep to go, what interviewers ask at each stage, and where AI fits.

Short answer: Learn Kotlin and the Android platform first, then coroutines, Compose and architecture, then data, testing, production and system design. Use AI at every stage, but only as fast as you can check what it gives you. Interviews test the same things, plus coding problems and design.

I built this from the official Android Developers and Kotlin documentation, recent interview write-ups that developers posted publicly, and what I have seen in production Android work. It is my own roadmap, not one published by Google or JetBrains.

A roadmap is only useful if it matches the platform you will ship on. These changes from the last year affect what you should learn, newest first.

None of this replaces the basics. Most of it rewards people who already understand lifecycle, state and the build.

Before the topic lists, five rules. They matter more than any single library.

Each stage depends on the one before it. Compose makes little sense until you understand state. State makes little sense until you understand lifecycle and process death. Skip a stage and you can still ship features, but you end up debugging by guessing. AI makes that worse, because it gives you more code to guess about.

If you already work as an Android developer, do not start at stage 1 by default. Use the last column as a test, and start at the first stage you cannot pass.

Every stage has the same parts: why it matters, what you must know, what to learn when you want to go deeper, where to start, the interview questions it prepares you for, and one exercise to test yourself.

Kotlin is the language of Android. Knowing the syntax is easy. Knowing what the language does for you, and what it does not, takes longer. This stage also covers DSA (data structures and algorithms), which most Android interviews still test in a coding round.

Go deeper Kotlin and Java interop ( @JvmStatic, @JvmOverloads, platform types) Reading the bytecode Kotlin generates DSL builders, contracts, context parameters Annotation processing with KSP

Where to start: the Kotlin docs, then what's new in Kotlin 2.4 to see where the language is going.

Try this: Write a sealed UiState with four states and a when that handles them. Add a fifth state. Notice what the compiler does, and explain why that is the point of sealed types.

This is the stage people skip, and it is where many production bugs live. The platform also keeps changing under you. Apps that target Android 16 can no longer opt out of edge-to-edge, get predictive back by default, and have orientation and resize limits ignored on large screens. Apps that target Android 17 lose the large-screen opt-out and need a new permission for local network access.

Go deeper Binder and inter-process communication Zygote and how an app process starts App Startup library, multi-window, App Bundles and feature delivery Reading every Android version's "behavior changes" page as a habit

Where to start: the Activity lifecycle and saving UI state guides.

Try this: Open your app, fill a form, press Home, then run adb shell am kill <your.package>. Open it again from Recents. Did the form come back?

Many Android bugs that "happen sometimes" are concurrency bugs. This is also where AI-written code most often looks correct while being wrong.

Go deeper Continuations and the state machine the compiler generates Channels and select flowOn, buffer, conflate and backpressure (when a producer is faster than its collector) Threads, thread pools and Java memory model basics RxJava interop for older code

Where to start: the Kotlin coroutines guide, then Android's coroutines best practices.

Try this: Start two requests with async inside coroutineScope, and make one fail. What happens to the other? Switch to supervisorScope and explain the difference.

Google now says all Android UI should be built with Compose. Views still work and get critical fixes, but no new features. The goal of this stage is not to make screens. It is to predict when a screen recomposes and why.

Go deeper The three phases: composition, layout and draw Custom layouts, Modifier.Node and Canvas drawing The snapshot system and the slot table (where Compose keeps state between recompositions) Compose compiler stability reports View interop for existing apps, Glance for widgets

Where to start: Thinking in Compose, then the Compose performance guide.

Try this: Turn on recomposition counts in Layout Inspector and scroll a list. Find one composable that recomposes more than it should, and fix it.

Google's architecture recommendations are a good baseline. They strongly recommend a data layer with repositories, one-way data flow (UDF) and dependency injection. They recommend a domain layer only when business logic is reused across ViewModels or a ViewModel gets too complex. Architecture should solve a problem you have. A small app does not need every layer.

Go deeper Modularization: feature and core modules, api and impl modules Gradle convention plugins Clean Architecture and its trade-offs Other DI options and when manual DI is enough Google's Now in Android sample app as a reference

Where to start: the guide to app architecture and the recommendations page.

Try this: Take a ViewModel that calls Retrofit directly. Move the call into a repository, write a fake repository, and test the ViewModel without the network.

Real apps are mostly about data that is late, missing or out of date. The interesting problems start when the network fails.

Go deeper WebSockets and push with FCM GraphQL and the Ktor client SQL indexes and query performance Conflict resolution for data edited on two devices Encrypting data at rest

Where to start: the data layer guide and the offline-first guide.

Try this: Make a list screen read only from Room and refresh from the network in the background. Turn on airplane mode. Does the screen still make sense?

A feature that worked once on your phone is not done. Google's guidance is to prefer fakes to mocks and to test ViewModels, the data layer, navigation and performance. The skill is choosing what to test, not writing more tests.

Go deeper Screenshot tests Robolectric Coverage tools, and why coverage is not the goal Gradle Managed Devices and device farms Finding and fixing flaky tests

Where to start: Android testing fundamentals.

Try this: Break a feature on purpose, for example by swapping two lines in a mapper. Does any test fail? If not, write the one that would.

Shipping is a separate skill from building. In 2027 it also includes rules that did not exist a few years ago: 16 KB page support, yearly target API deadlines and developer verification.

Go deeper Perfetto and custom trace sections; logging and network inspection tools such as Timber and Chucker Native crashes Gradle build speed and the configuration cache Feature flags and safe rollouts Privacy reviews and the Play Data safety form

Where to start: the performance overview.

This is the area I care most about, because "the app feels slow" is not a bug report you can fix. You need numbers first.

Try this: Measure cold start with Macrobenchmark. Add a Baseline Profile. Measure again and write down both numbers.

This is where you stop asking "how do I build this screen" and start asking "what breaks, and who owns it". System design is not boxes and arrows. It is requirements, data models, failure cases and trade-offs you can defend.

Chat app, news or social feed, photo gallery, offline notes or to-do, cart with filters, map or ride tracking, video player, file upload, LRU cache, an SDK for other apps.

Go deeper Android internals: ART and garbage collection, Looper and MessageQueue, the rendering pipeline (Choreographer, RenderThread, vsync) Leading migrations across a large codebase Writing design docs and mentoring

Where to start: the guide to app architecture and the modularization guide.

Try this: Design an offline-first chat app on paper. Then list three ways it fails, such as messages sent twice, out of order, or lost on process death, and how your design handles each.

AI is not stage 10. It runs alongside every stage, in two different ways: using AI to do your work, and building AI into the apps you ship.

Google now ships tools for this. Android CLI 1.0 lets agents such as Gemini in Android Studio, Claude Code or Codex create, build and deploy Android apps. Android skills give agents Google's best practices for tasks like adaptive UI or testing setup.

Here is the kind of code AI tools often write. It compiles, the happy path works, and the review looks clean:

// Almost right fun loadProfile () = viewModelScope. launch { runCatching { repository. fetchProfile () }. onSuccess { _uiState. value = UiState. Data ( it ) }. onFailure { crashReporter. log ( it ) // also logs normal cancellations _uiState. value = UiState. Error } } // Right fun loadProfile () = viewModelScope. launch { try { _uiState. value = UiState.

Data ( repository. fetchProfile ()) } catch ( e: CancellationException ) { throw e // let cancellation finish } catch ( e: IOException ) { crashReporter. log ( e ) _uiState. value = UiState. Error } } Enter fullscreen mode Exit fullscreen mode runCatching catches every Throwable, including CancellationException. When the user leaves the screen and the coroutine is cancelled, the first version treats that as a failure.

It logs an error that never happened and runs code after the coroutine should have stopped. The Kotlin docs say it directly: if you catch CancellationException, rethrow it.

You only spot this if you learned stage 3. That is why AI makes the fundamentals more valuable, not less.

Google's guide to choosing an AI solution starts with one rule: use the simplest model and tooling that does the job.

Go deeper: embeddings and retrieval, evaluating model output with test sets, building agents.

Every item on that list is a stage 3, 6, 7 or 8 skill with a model in the middle. AI features do not replace the roadmap. They test it.

Based on recent Android interview experiences that developers shared publicly in 2026, from SDE-1 to SDE-2, a few patterns stand out. They are personal stories, not a survey, but they point the same way:

What is asked depends on the company and the level. Do not count how many questions you memorized. Count how many answers you can explain, build and defend against "what if".

A roadmap that makes everything look equally important does not help anyone. These are worth learning when your product, team or next role needs them.

The rule is simple: fundamentals first, then go deep where the product takes you.

One project, improved stage by stage, teaches more than ten tutorial apps. It also gives you something real to talk about in interviews.

Once it is stable, add one AI feature that solves a real user problem, such as search or summaries. That single feature will touch streaming, errors, cost, privacy and testing. Add it last, not first.

A sample plan for about 12 to 15 focused hours a week, if you can already program. At 8 to 10 hours a week, expect closer to 9 months. Skip any stage whose check you already pass.

Three things run through all six months: a few coding problems every week, both AI tracks, and your one project.

I have built Android apps for more than six years. I still do not think a roadmap is something you finish. It is something you go back to.

At work I built an alert that keeps reminding a user every few minutes until they open an urgent message. The easy version, a timer inside the app, stops the moment Android kills the process, and Doze would delay it anyway. What worked was handing the repeat loop to WorkManager and saving the active message ID to disk instead of keeping it in memory. Process death, Doze and background limits are stage 2 topics, and that feature is where they stopped being interview theory for me.

So I am going through these stages again, at production depth: read the docs, build a small example, break it, and explain it from memory. AI helps at every step, but it does not replace the testing or the checking.

The posts will be here on the blog, and the videos on YouTube. I will keep this roadmap updated as Android changes.

Will AI replace Android developers? I don't think the evidence points that way. AI tools write more of the code, but more developers distrust their accuracy than trust it ( 46% vs 33% ). Someone still has to decide what to build, check that it works on real devices and own it in production. Some interviews are starting to move the same way: from writing code from scratch toward reading, checking and fixing it.

Do I need Kotlin Multiplatform to get an Android job? Not for most native Android roles. It helps when a team shares code with iOS or the web. Learn it after you are solid in Kotlin, coroutines, architecture and testing, since KMP builds on all of them.

Do Android developers really need DSA? Usually, yes. A coding round is still common in Android interviews, even at SDE-2. DSA also helps in daily work: picking the right collection, keeping list updates fast, sizing a cache. Practice a little every week instead of doing it all just before your interview.

There is no single stack that guarantees an Android career in 2027. But the order is clear: Kotlin, the platform, concurrency, Compose, architecture, data, testing, production, then system design. AI runs alongside all of it, as a tool and as a feature. Interviews test the same path, plus coding problems and design.

It is to understand problems, build things that work, and keep up as Android changes.

Which stage are you working on right now, and which one do you keep putting off?

This post first appeared on imayankkumar.com, where you'll find new posts first.