Android developer (Kotlin) roadmap

In Kotlin you use val for a value that never changes and var for one that can change. Each value has a type, like Int for whole numbers, Double for decimals, String for text and Boolean for true or false. Prefer val unless you really need to change the value.

if/else and when choose what to do based on a condition. for and while loops repeat code, for example to add up a list of prices. Kotlin's when is like a cleaner switch, and you will use it a lot in Android code.

A function takes inputs (parameters), does one job and can return a result. Kotlin also has lambdas, which are small functions you can pass around, for example to say what happens when a button is clicked. Name functions by what they do, like calculateTotal.

Null means "no value". Kotlin marks types that may be null with a question mark, like String?, and forces you to handle that case. Learn the safe call (?.), the Elvis operator (?:) and why you should almost never use !!.

A class groups data and behaviour together. A data class is a short way to hold data, like data class Product(val name: String, val price: Int). Learn constructors, properties, interfaces and inheritance at a basic level.

Learn List, Set and Map, and the difference between read-only and mutable versions. Practise filter, map, sortedBy and sumOf on lists. These make code short and clear, for example finding all products under ₹500.

Git records changes as commits so you can go back when something breaks. GitHub stores your projects online. Android Studio has Git built in, but also learn the basic commands.

Learn to create a project, run it on the emulator and on your own phone with USB debugging, and read Logcat for errors. Learn the project files: the app module, the manifest and the Gradle build files. Most early problems are solved by reading the error in Logcat carefully.

In Compose you build the screen with Kotlin functions marked @Composable, like Text, Button and Image. You describe what the screen should look like for the current data, and Compose redraws it when the data changes. Older apps use XML layouts, so learn to read them a little too.

Column stacks items top to bottom, Row places them side by side and Box layers them on top of each other. Modifiers add padding, size, background and click handling. Test your screens on small and large phones.

remember and mutableStateOf keep a value, like the text in a box or a counter. When the state changes, Compose redraws only what is needed. Learn state hoisting, which means keeping state in a parent and passing it down, so components stay simple.

LazyColumn shows only the items on screen, so even 10,000 rows scroll smoothly. Give each item a stable key. Build list items as small composables, like a ProductRow.

Material 3 gives you ready components like buttons, cards, top bars and dialogs, plus rules for colour and type. Set your theme once and use its colours everywhere. Support dark theme from the start.

An Activity moves through states like created, started, resumed and stopped. Rotating the phone can recreate it, so data kept only in the screen may be lost. Keep text in strings.xml so you can translate the app into Hindi or other languages later.

The ViewModel holds the data and logic for a screen and survives configuration changes like rotation. It exposes one UI state object that the screen draws. This keeps your composables simple and easy to test.

Navigation Compose moves between screens using routes, like home or product/42. Learn to pass ids between screens and handle the back button. Keep one clear navigation graph so the app flow is easy to follow.

A coroutine is a light way to run work in the background, like a network call, without blocking the main thread. suspend functions can pause and continue later. In a ViewModel, use viewModelScope so the work stops when the screen closes.

A Flow gives you values over time, like new rows from the database. StateFlow always holds the latest value and is the usual way a ViewModel shares UI state. In Compose, collect it safely with collectAsStateWithLifecycle.

Room is the official library for saving data in a local SQLite database. You define entities (tables), DAOs (functions that run queries) and the database class. Room can return a Flow, so the screen updates by itself when data changes.

Retrofit turns a Kotlin interface into real network calls to a REST API. A converter such as Kotlinx Serialization or Moshi turns JSON into Kotlin data classes. Always handle no internet, slow networks and server errors with clear messages.

A repository is one class that decides whether data comes from Room or from the network. Dependency injection with Hilt creates and passes these classes to where they are needed. Follow the official guide to app architecture: UI layer, data layer and, if needed, a domain layer.

DataStore saves small values like the chosen language, dark mode or whether onboarding is done. It replaces the older SharedPreferences. Use Room for real lists of data and DataStore for settings.

Firebase Authentication handles sign-in with email, phone number (OTP) or Google, without you building a login server. You get a user id that you can use to keep each user's data separate. Learn to handle logout and expired sessions.

Firestore stores data as documents in collections and can send live updates to the app. Security rules decide who can read or write each document, and they are your main protection. Never leave the database open to everyone, even for testing.

Firebase Cloud Messaging (FCM) sends notifications to phones. On new Android versions you must ask the user for permission first. Crashlytics reports crashes from real users with the line of code, so you fix the biggest problems first.

Unit tests check small pieces of logic, like a ViewModel or a price calculator, with JUnit. Use fake repositories instead of real servers so tests are fast. Test the edge cases: empty lists, zero amounts and errors.

Compose testing lets you find elements by text or tag, click them and check the result. Add a few tests for your most important flows, like adding an item. Keep UI tests few and focused because they are slower.

Ask for permissions like camera or location only when needed, and explain why. Fill the Data safety section in Play Console honestly. Collect as little personal data as possible.

You build a signed Android App Bundle (AAB) and upload it in Google Play Console, which needs a one-time developer registration fee. You add screenshots, a description, a privacy policy and content rating. Use internal or closed testing first, and check the current rules for new developer accounts in Play Console.

Measure start-up time, janky frames and memory with Android Studio profilers and Macrobenchmark. Baseline Profiles help the app start faster. Keep images small, avoid work on the main thread and test on a cheap phone, not only your own.

Learn recomposition, which is Compose redrawing a part of the screen. Use stable data, keys in lazy lists and remember to avoid extra work. Layout Inspector shows how often each part redraws.

Split the app into Gradle modules, for example core, data and one module per feature. This makes builds faster and stops one team breaking another team's code. Follow the official modularisation guide and keep dependencies pointing one way.

WorkManager runs tasks that must finish, like uploading a photo or syncing data, even after a restart. Android limits background work to save battery. Choose the right tool and respect these limits.

Never put secret API keys inside the app, because anyone can read them from the APK. Use HTTPS only, store tokens safely and shrink and obfuscate release builds with R8. Learn the OWASP mobile risks.

Run lint, unit tests and a build on every pull request with GitHub Actions. Automate uploads to a Play testing track. Use staged rollouts so a bad release reaches only a few users first.

Kotlin Multiplatform lets you share business logic, like networking and data rules, with an iOS app. You do not need to master it, but you should know what it is and when it helps. Learn it after your Android basics are strong.

Give reviews that are kind, specific and explain why. Write short design notes before big changes. Pair with juniors and share what you learn.