跪拜 Guibai
← Back to the summary

Android 2027: nine phases of fundamentals, from Kotlin to system design, with AI woven through every stage

This article is translated from "Android Developer Roadmap 2027: What to Learn, What Interviews Ask, and Where AI Fits", original link https://medium.com/proandroiddev/android-developer-roadmap-2027-what-to-learn-what-interviews-ask-and-where-ai-fits-240ba695584a, published by Mayank Kumar on October 30, 2026.

0.jpg

If you are an Android developer, you might now be asking yourself three questions:

  1. What should I learn next?
  2. Since AI can already write code, does this knowledge still matter?
  3. What will interviewers ask me?

The past year has not made things easier. In May 2026, Google announced that Android UI is now Compose-first, and put the View components that Compose replaces into maintenance mode: only critical bug fixes, no new features, but also no plans to remove them. The same day, Android CLI 1.0 was officially released, and AI agents can build and run Android applications. Additionally, Google is reportedly piloting the use of Gemini for programming interviews.

This article answers all three of those questions. It is a complete 2027 roadmap: what to learn, the order in which to learn it, how deep to go, what interviewers will ask at each stage, and where AI fits in.

Short answer: First learn Kotlin and the Android platform, then coroutines, Compose, and architecture, then data, testing, production, and system design. Use AI at every stage, but move fast enough to quickly verify its results. Interviews will cover these topics, plus coding questions and design questions.

I consulted the official Android Developers and Kotlin documentation, recent public interview transcripts from developers, and what I have observed working in real Android production environments to build this roadmap. This is my own roadmap, not one published by Google or JetBrains.

What changes are facing Android developers in 2027?

A product roadmap is only useful when it matches the platform you will be shipping on. The changes of the past year affect what you should learn, so prioritize the newest material.

None of these replace the fundamentals. They are mostly better suited to people who already understand lifecycle, state, and building.

How should you think about 2027?

Before listing topics, here are five rules. They matter more than any single library.

  1. Master the fundamentals before the tools. Libraries come and go every year. Lifecycle, state, threading, and data flow have not changed much in the past decade. Learn what will still apply in 2030.
  2. One project, rather than ten tutorials. Build one application and keep improving it at every stage. You learn far more from fixing your own designs than from completing someone else's projects.
  3. Use AI, but verify. Let AI write code, explain things, and make suggestions. Then verify its correctness with tests, profilers, or documentation. If you cannot verify it, you are not ready to ship it.
  4. Go deep in one area. Stay solid across all nine stages, then choose one area to go deep in: performance, architecture, testing, AI features, or Kotlin Multiplatform (KMP). Depth is key to being a senior engineer.
  5. Show your work. GitHub repositories, short documents, or talks are more convincing than certificates. They also give you real interview material.

Roadmap overview

Each stage depends on the previous one. Compose concepts do not make much sense before you understand state. State does not make sense before you understand lifecycle and process termination. Skip a stage and you can still ship features, but you will end up debugging by guessing. AI makes it worse, because it gives you more code to guess about.

1 (1).png

If you are already an Android developer, do not default to starting at stage one. Use the pass-bar checks as a test, and start at the first stage you fail.

The nine stages

Each stage contains 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 a self-test exercise.

Stage 1: Kotlin and DSA fundamentals

Kotlin is the language of Android. Mastering its syntax is easy, but understanding the language's capabilities and its limitations takes longer. This stage also covers data structures and algorithms (DSA), which most Android interviews still test in the coding round.

Must know

Go deeper

Where to start: First read the Kotlin documentation, then What's new in Kotlin 2.4 to see where the language is heading.

Interview questions

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

Stage 2: Android platform

This is the stage people often skip, and where many production bugs breed. The platform itself is also changing. Apps targeting Android 16 can no longer opt out of edge-to-edge display, predictive back is enabled by default, and orientation and window size restrictions are ignored on large screens. Apps targeting Android 17 lose the large-screen opt-out and require a new local network access permission.

Must know

Go deeper

Where to start: Activity lifecycle and Saving UI states guides.

Interview questions

Try this: Open your app, fill in a form, press Home, and then run adb shell am kill <your package name>. Open it again from recents. Did the form recover?

Stage 3: Coroutines and Flow

Many of the "happens sometimes" bugs in Android are concurrency bugs. This is also where AI-written code most often looks right while being wrong.

Must know

Go deeper

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

Interview questions

Try this: Use async in a coroutineScope to launch two requests, and make one of them fail. What happens to the other? Switch to supervisorScope and explain the difference.

Stage 4: Compose UI

Google now says all Android UI should be built with Compose. Views still work and receive critical fixes, but no new features are added. The goal of this stage is not creating screens, but predicting when and why a screen needs to recompose.

Must know

Go deeper

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

Interview questions

Try this: Enable recomposition counts in the Layout Inspector and scroll a list. Find a composable that recomposes too much, and fix it.

Stage 5: Architecture

Google's architecture recommendations are a good benchmark. They strongly recommend a data layer, including repositories, unidirectional data flow (UDF), and dependency injection. They recommend a domain layer only when business logic needs to be reused across multiple ViewModels, or when a ViewModel becomes too complex. Architecture should solve the problem you have. A small app does not need every layer.

Must know

Go deeper

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

Interview questions

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

Stage 6: Data, networking, and offline

In real applications, data is mostly delayed, missing, or stale. The genuinely interesting problems start with network failure.

Must know

Go deeper

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

Interview questions

Try this: Set up a list page to read only from Room and refresh via the network in the background. Turn on airplane mode. Does the content still display?

Stage 7: Testing and code quality

Just because something ran on your phone once does not mean it is done. Google's recommendation is to prefer fakes over mocks, and to test ViewModels, the data layer, navigation, and performance. The key is choosing what to test, not writing more test cases.

Must know

Go deeper

Where to start: Android testing basics.

Interview questions

Try this: Deliberately break a feature, for example by swapping two lines in a mapper. Does any test fail? If not, write a test that would fail.

Stage 8: Production engineering

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

Must know

Go deeper

Where to start: Performance overview.

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

Interview questions

Try this: Measure cold startup with Macrobenchmark. Add a Baseline Profile. Measure again and record both results.

Stage 9: System design and advanced skills

At this point, you stop asking "how do I build this screen" and start asking "what can go wrong, and who is accountable". System design is not just boxes and arrows; it includes requirements, data models, failure cases, and tradeoffs you can explain.

Must know

Common design questions

Chat app, news or social feed, photo gallery, offline notes or todo list, shopping cart with filters, maps or trip tracking, video player, file upload, LRU cache, SDK for other apps.

Go deeper

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

Interview questions

Try this: Design an offline-first chat app on paper. Then list three ways it could fail, such as duplicated messages, messages arriving in the wrong order, or messages lost when the process is killed, and explain how your design handles each one.

What role does AI play in the Android roadmap?

AI is not stage ten. It runs through every stage at the same time, in two different ways: using AI to do your work, and building AI into the applications you ship.

Part A: How Android engineers use AI

Google now ships the tools. Android CLI 1.0 lets agents such as Android Studio, Claude Code, or Codex create, build, and deploy Android applications. Android Skills give agents Google's best practices for tasks such as adaptive UI or test setup.

Must know

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

// 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
    }
}

runCatching catches every Throwable, including CancellationException. When the user leaves the page and the coroutine is cancelled, the first version treats it as a failure. It logs an error that never happened, and keeps executing code after the coroutine should have stopped. The Kotlin documentation is explicit: if you catch a CancellationException, you need to rethrow it.

Only someone who learned stage three can spot this. That is why AI makes fundamentals more valuable, not less important.

Part B: Building AI features into apps

Google's guide to choosing an AI solution opens with one rule: use the simplest model and tool that can do the job.

Option When to use it Caveats
On-device (Gemini Nano, ML Kit GenAI API, Prompt API) Privacy-focused, supports offline, no per-request cost Only supported on some devices; best for short text tasks
Cloud (Firebase AI Logic, your own backend) For large models, image and video input, complex tasks Network, latency, cost, user data leaves the device
Hybrid Use on-device when the device supports it, cloud as fallback Two code paths to build and test

Must know

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

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

AI interview questions

What do Android interviews look like now?

Based on recent Android interview experiences developers shared publicly in 2026 (from SDE-1 to SDE-2), some patterns stand out. These are individual stories, not surveys, but they all point in the same direction:

  1. Coding rounds still appear. Most interviews include a data structures and algorithms (DSA) round (e.g. sliding window, two pointers, hash tables). Some ask for a small coroutine task. Android experience does not let you skip these.
  2. Android interviews test depth, not breadth. ViewModel internals and state retention after configuration changes come up repeatedly. So do coroutines. Interviewers ask "how does it work" and "what happens if", rather than "what is it".
  3. Design rounds start early. Even SDE-1-level interviews may include a design round. Topics include image loading libraries, analytics SDKs, infinite image grids, and shopping apps.
  4. Some companies add a machine coding round. You build a small runnable app live in 45 to 60 minutes, or as take-home work.
  5. AI has entered interviews. It comes up as a topic (what tools you use, what MCP is, how you use AI at work). In May 2026, Google reportedly ran a pilot letting junior and mid-level candidates use Gemini to read, debug, and improve existing code.

How to prepare for each round

What gets asked in an interview depends on the company and your level. Do not count how many questions you memorized; count how many you can explain, build, and handle "what if" scenarios for.

What can you learn later?

A roadmap that treats everything as equally important helps no one. These topics are only worth learning when your product, team, or next role needs them.

The rule is simple: master the fundamentals first, then dive deep based on the product's specifics.

Where should you start based on your experience?

Should you build several small apps or one real project?

One project, improved iteratively, teaches you more than a dozen tutorial apps. It also gives you something real to talk about in interviews.

A good roadmap project should have:

Once the system is stable, add one AI feature that solves a real user problem, such as search or summarization. That one feature will cover streaming output, error handling, cost, privacy, and testing. Add it last, not first.

How long does this take? A sample 6-month plan

If you already know how to program, here is a sample plan with about 12 to 15 focused hours a week. At 8 to 10 hours a week, expect closer to 9 months. If you already pass any stage, skip it.

  1. Month one: Kotlin and DSA fundamentals, Git and Gradle
  2. Month two: Android platform, lifecycle and process termination
  3. Month three: Coroutines, Flow, and Compose UI
  4. Month four: Architecture, data, and offline features
  5. Month five: Testing, performance, and releases
  6. Month six: System design, project polish, and mock interviews

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

How I follow this roadmap in public

I have been developing Android apps for over six years. I still think a product roadmap is not a one-time thing, but something to constantly review and refine.

At work, I built a reminder feature that pings the user every few minutes until they open an urgent message. The simplest version used an in-app timer, but once Android terminates the process, the timer stops working, and Doze mode itself delays timers. What ultimately worked was handing the repeating loop to WorkManager and saving the current message ID to disk instead of memory. Process termination, Doze mode, and background restrictions are stage 2 interview topics, and this feature is when those concepts stopped being interview theory for me.

So now I am going through these steps again, this time at the production level: read the docs, build a small example, find what breaks, and then explain why from memory. AI helps at every step, but it does not replace testing or review.

Posts will be published on the blog, and videos on YouTube. I will keep updating this roadmap as Android changes.

FAQ

Will AI replace Android developers? I do not think the current evidence points in that direction. AI tools do write more code, but more developers are skeptical of their accuracy (46% vs 33%). In the end, someone still has to decide what to build, verify it runs on real devices, and own it in production. Some interviews are also moving in this direction: from writing code to reading, reviewing, and fixing it.

Do I need to learn Kotlin Multiplatform to get an Android development job? For most native Android roles, no. Kotlin Multiplatform helps when a team needs to share code with iOS or Web teams. It is recommended to learn Kotlin Multiplatform after mastering the fundamentals of Kotlin, coroutines, architecture, and testing, because Kotlin Multiplatform builds on those.

Do Android developers really need data structures and algorithms (DSA)? Generally yes. Even SDE-2-level Android interviews still commonly include a coding round. DSA also helps with daily work: choosing the right collection, keeping lists fast to update, and optimizing cache size. Practice a little each week rather than cramming before an interview.

Build the foundation first, then dive deep

No tech stack guarantees you an Android career in 2027. But the order is clear: Kotlin, platform, concurrency, Compose, architecture, data, testing, production, and finally system design. AI runs through all of it, as both tool and feature. Interviews will test this path, plus coding and design ability.

The goal is not to learn every tool.

The goal is to understand the problems, build something effective, and keep improving as Android changes.

Which stage are you working on now, and which one have you been putting off?

Originally published at https://imayankkumar.com on October 30, 2026.

Welcome to search and follow the WeChat public account "稀有猿诉" for more quality articles!

Protect originality, do not repost!