Learning Android development in 2026: a practical path

Where to start with Android development has a different answer in 2026 than it did a few years ago, because the platform has changed: the recommended language, the recommended way to build screens, the official course and even the certification I once earned are all different now. This is the path I’d suggest to someone starting in 2026. It leans on Google’s own material, which is free to read and is where the platform’s recommendations are actually written down, and it ends with putting a real app in front of real people.

Start with Kotlin

Google announced at I/O 2019 that Android development would be increasingly Kotlin-first, and its developer site says it has stood by that. In practice, new Jetpack libraries, samples, documentation and training are designed with Kotlin users in mind.

Java hasn’t gone away. Google still supports calling the platform APIs from Java, and Android Studio still supports it. But Google’s comparison is blunt about the rest: training and samples for Java are “best effort”, and Jetpack Compose and the Kotlin-specific extensions are Kotlin-only. Kotlin is fully interoperable with Java, so existing Java code isn’t a reason to avoid learning it.

If you already program in another language, Kotlin is quick to pick up. If you don’t, that’s fine too. The official course below starts from programming basics.

Take one structured course end to end

Google’s Android Basics with Compose is a self-paced online course that teaches app building with current best practices. Its listed prerequisites are basic computer skills, basic maths skills and a computer that can run Android Studio. An Android phone is listed as optional; the emulator in Android Studio can stand in for one.

The course has eight units:

1. Your first Android app
2. Building app UI
3. Display lists and use Material Design
4. Navigation and app architecture
5. Connect to the internet
6. Data persistence
7. WorkManager
8. Views and Compose

Google lists a time estimate for each unit, and together they add up to about 100 hours. Several units end with a project you build yourself, such as a business card app or a Bookshelf app that reads from the internet. Do those projects properly, without copying the solution. They’re where the course stops being reading and starts being practice.

Finishing one course is worth more than starting three. Tutorials elsewhere can fill gaps later, but a single path that runs from “hello world” to networking and a local database gives you a complete picture of how an app fits together.

Learn Compose, and don’t skip the last unit

Jetpack Compose is now Google’s recommended toolkit for building Android interfaces, and the course teaches it from the first unit. You describe what the screen should look like for a given state, and Compose updates it when the state changes.

The last unit, Views and Compose, covers the older View-based toolkit and how the two work side by side in one app. It’s short, and it’s easy to skip. Don’t. Plenty of apps you’ll work on, or read the source of, still have screens built with Views, and knowing how to mix the two is a practical skill.

Read the architecture guide before your app gets big

Small exercises fit in one file. Real apps don’t. Google’s guide to app architecture is the clearest description of how Google expects apps to be structured, and it’s worth reading as soon as your first project starts to sprawl.

The guide recommends at least two layers: a UI layer that displays data on screen, and a data layer that holds the app’s business logic and exposes its data. An optional domain layer can sit between them when the same logic is reused in several places. Four principles run through the rest of the guide:

• Separation of concerns. Split the app into parts with clearly defined responsibilities.
• Drive the UI from data models, preferably persistent ones, so the screen reflects data rather than owning it.
• A single source of truth for each type of data, which is the only place allowed to change it.
• Unidirectional data flow. State flows down to the UI, and events flow back up to change it.

Google says these recommendations aren’t mandatory. They’re still the shared vocabulary of Android teams, and most teams will assume you know them.

Write tests from your second project

Testing feels optional when an app has three screens. It stops feeling optional the first time a change breaks something you thought was finished.

Google’s testing fundamentals describe two kinds of test by where they run. Local tests run on your development machine and are usually small and fast. Instrumented tests run on a real or emulated device, and are usually UI tests that launch the app and interact with it. Tests are also described by size: small unit tests for a single class or function, medium tests for how a few parts work together, and big end-to-end tests for a whole screen or user flow.

Start with small local tests for the logic in your data layer. They’re quick to write, quick to run and catch the bugs that are hardest to spot by tapping around.

Build something you’d actually use

After the course, build one app of your own that solves a real problem for you or someone you know. A lot of my own work started this way, from certificate tools for colleges and universities to ZyadaShop, which let merchants build a website and an Android app from a phone. A real problem forces decisions no tutorial makes for you: what to leave out, what happens offline, what to do when the data is wrong.

About certificates

I earned Google’s Associate Android Developer certification earlier in my career.

That leaves a portfolio as the clearest evidence of skill. An app on the store, with code you can walk someone through and decisions you can explain, says more than a badge. There’s more about my own path on the about page.

Ship a first app

Publishing is part of learning, because it’s where you meet the things courses skip: store listings, privacy forms, crash reports and real people using your app in ways you didn’t expect.

To publish on Google Play, you register a developer account with a one-time fee of US$25 and complete identity verification. Personal accounts also have to verify access to an Android device through the Play Console mobile app, and new personal accounts must run a closed test with at least 12 testers for 14 days before they can publish to everyone. I’ve written up how that closed testing requirement works, and how to fill in the store privacy disclosures that every listing needs.

The path, in order

1. Learn Kotlin basics.
2. Work through Android Basics with Compose, including every project.
3. Read the guide to app architecture.
4. Build one small app of your own, with tests for its logic.
5. Publish it, starting with a closed test.
6. Read the feedback, fix what matters, and build the next one.

The platform will keep changing, and the course and guides will change with it. When something you’re reading feels out of date, go back to Google’s own pages, which is where every recommendation in this piece came from.