Most of the phones in use run Android. The platform held 69.17% of worldwide mobile operating system share in September 2026 (StatCounter Global Stats), and that audience is the reason developers keep writing for it.
The work means Kotlin or Java code, Android Studio and the Android SDK. What comes out is a signed package that goes to Google Play or another store. Phones and tablets are the obvious targets, but watches, TVs and cars run Android too.
What Is Android Development?
Android work sits inside the wider discipline of building mobile applications, though the platform rules, tooling and release process are their own thing.
Underneath it all is the Android Open Source Project (AOSP). Google leads the project, and according to source.android.com anyone can use the source code for any purpose.
A device only counts as Android if it passes the Android Compatibility program. Google Play and Google’s own apps ship separately from AOSP.
Google’s developer documentation sorts its guidance by device type.
- Phones, tablets and foldables
- ChromeOS devices
- Wear OS watches
- Android TV
- Cars, through Android Auto and Android Automotive OS
- Android XR
- Googlebook laptops
Customizing the operating system itself through AOSP is platform work, and it’s a separate job from app development.
How Does an Android App Work?
The system decides when each piece of an Android app starts and stops, never the app itself. Those pieces are components declared in a manifest file, and the whole app runs in its own sandbox.
The Android Runtime (ART) executes the compiled code as DEX bytecode. Since Android 7, ART mixes ahead-of-time and just-in-time compilation with interpretation, and usage profiles can guide the ahead-of-time step (Android runtime documentation, source.android.com).
App components and the manifest
Each type of component does something different, as the table shows.
| Component | Job | Has a screen |
|---|---|---|
| Activity | One screen the user interacts with | Yes |
| Service | Background work such as syncing data or playing music | No |
| Broadcast receiver | Responds to system-wide announcements | No |
| Content provider | Manages shared data other apps can query | No |
Activities and services need a manifest entry, and so do content providers. One that exists in the source but not in the manifest is invisible to the system and never runs.
Broadcast receivers are the exception, since code can register them at runtime. The manifest also lists the permissions and hardware features the app asks for.
The activity lifecycle
Android calls a fixed set of callbacks on every activity as the user moves in and out of it.
onCreate and onDestroy handle setup and release for the activity’s whole life. The visible stretch falls between onStart and onStop. Inside that, onResume and onPause bracket the time the user can interact.
Whatever a callback sets up, its paired callback should tear down. Mismatched pairs are a common cause of memory leaks.
Android can also destroy an activity to free memory, or after a configuration change such as rotation, and then recreate it. Any state that matters has to be saved before that happens.
Jetpack libraries and local storage
Room is the local database library in Android Jetpack, Google’s suite of libraries for app architecture. It puts an abstraction layer over SQLite and checks SQL queries at compile time. Google recommends it over calling the SQLite APIs directly.
Local storage matters most for apps that handle structured data. Cached content lets users keep browsing when the network drops.
Which Programming Languages Does Android Development Use?
Kotlin is the default for new Android apps.
Google announced a Kotlin-first direction at Google I/O 2019. It now designs new Jetpack libraries for Kotlin users first, and the samples and training content follow. Java stays supported and fully interoperable.
JetBrains created Kotlin, and the language’s null safety and concise syntax explain most of its appeal on Android.
Google’s Kotlin-first page on developer.android.com (as of October 2026) says Android apps that contain Kotlin code are 20% less likely to crash. The same page says over 70 of Google’s own apps are built with Kotlin.
Some beginner guides still describe Java as the language underneath all Android development. Google’s documentation has said otherwise since 2019.
For a new project, I’d pick Kotlin. No real debate. If the codebase is already Java, leave it alone and add Kotlin file by file. Heavy computation or reused C++ code is where native modules through the NDK come in.
Teams still deciding can read a direct comparison of Kotlin and Java for Android.
The NDK is a set of tools for using C and C++ code in an Android app. Android Studio compiles that code into a native library, Gradle packages it into the APK, and Kotlin or Java code calls it through the Java Native Interface (JNI).
According to the NDK documentation, it probably isn’t a good fit for most novice programmers who only need framework APIs. New native libraries should use CMake rather than ndk-build.
Python and JavaScript are not part of the standard Android toolchain. Apps in those languages depend on a framework layer.
Android Studio, the Android SDK and the Rest of the Toolchain
Almost every project touches the tools in the table below.
| Tool | Role | Used for |
|---|---|---|
| Android Studio | Official IDE | Writing, building and debugging code |
| Android SDK | Libraries and build tools | Compiling against a specific API level |
| Gradle | Build system | Dependencies, build variants, packaging |
| Android Emulator | Virtual devices | Testing screen sizes and Android versions |
| Android Debug Bridge | Command-line tool | Installing and debugging apps on a device |
Android Studio is the official IDE, built on the editor and developer tools of IntelliJ IDEA. New developers can start with a plain-language guide to Android Studio before opening a first project.
Gradle is the foundation of the build system, with Android-specific features added by the Android Gradle plugin. As of October 2026, Kotlin build scripts (build.gradle.kts) are the recommended format. Groovy (build.gradle) still works, though.
Android Debug Bridge (adb) ships in the Android SDK Platform Tools package. Wireless debugging works on Android 11 (API level 30) and higher, and a list of common adb commands covers the logcat and package work most projects need.
The IDE doesn’t handle backend services, analytics or crash reporting, which is where Firebase comes in. According to Firebase’s documentation, Crashlytics costs nothing to use.
How Do Jetpack Compose and XML Views Build an Android Interface?
Compose writes the interface as Kotlin functions that update when app state changes. The older View system defines screens in XML layout files and relies on code to update them.
Android’s documentation calls Compose its recommended modern toolkit for native UI (as of October 2026).
With Compose you get live previews inside Android Studio, and screens update automatically when state changes. XML views mean layouts in XML files with behavior in Kotlin or Java, and they’re still present in many older apps.
Compose targets phones, tablets, foldables, ChromeOS, Wear OS and TV from one toolkit.
Both toolkits implement Material Design, Google’s design system. Compose ships Material 3 components, and the principles behind Material Design apply the same either way.
Use Compose for every new screen. Reach for XML only when you’re extending a View-based app and a rewrite isn’t justified.
Mixing is supported. Compose can sit inside a View hierarchy through ComposeView, and Views can sit inside Compose through AndroidView, but the glue code and two mental models add up.
Google’s documentation says teams with views-based UIs can migrate to Compose or keep working with views.
What Are Android API Levels and How Do You Choose Them?
Each Android version supports exactly one API level, an integer that identifies one revision of the Android framework API (Android Developers, API levels reference).
You can’t derive the API level from the version number by arithmetic, so keep the mapping table open when you configure a project.
minSdk sets the lowest Android version the app runs on. targetSdk is the API level the app is designed for, and it switches on that level’s behaviors.
compileSdk is the level the code compiles against, which decides what APIs you can call.
minSdk is a reach decision. Lower values cover more devices, higher values let you delete compatibility code.
Android Studio’s New Project screen has a Help me choose link that shows the cumulative device distribution for each API level, and the Android Developers distribution dashboard carries similar data. Check one of them before picking a value.
targetSdk and compileSdk follow the store, not the audience. Raising the target does not force a higher minSdk, since an app that targets a recent API level still runs on older Android versions down to its minSdk (Play Console Help).
The requirements as of October 2026 (Play Console Help) look like this.
- Since August 31, 2026, new apps and updates need API level 36 (Android 16).
- New Wear OS and Android Automotive OS apps and updates need API level 35.
- New Android TV and Android XR apps and updates need API level 34.
- Existing mobile apps need API level 35 to stay visible to new users on newer Android versions.
- The extension you can request in Play Console ends on November 1, 2026.
A stale target level fails quietly. Installed users keep the app, but new users on newer Android versions stop finding it in Google Play.
Each release also changes behavior for apps that target it, and Google publishes a separate behavior-change list per version. Skipping releases means reading several of those lists at once.
Users on Android 10 and higher also see a warning at first launch when an app targets API level 22 or lower (Android Developers).
How Are Android Apps Packaged, Signed and Published?
You upload an Android App Bundle (AAB) to Google Play, and Google Play signs it and generates the APKs that devices install. Google Play has required bundles for new apps since August 2021, according to the Android App Bundle documentation.
The bundle holds all compiled code and resources, and each device downloads only what it needs. Developers no longer have to build and sign a separate APK for every configuration.
A bundle is a publishing format, not an installable file. Other stores still want APKs, and the practical differences between APK and AAB decide which one a given channel accepts.
The format does have limits. APK expansion (.obb) files aren’t supported, and on Android 10 and higher a partial set of split APKs fails to install.
With Play App Signing, the upload key signs the bundle you send, and Google manages the app signing key that signs what users install. Lose the upload key and Google can reset it, with no effect on users. Lose a signing key you manage yourself and it cannot be reset (Play Console Help).
You request the reset in Play Console under Manage Play app signing, after creating a new upload key and exporting its certificate as a PEM file.
Getting a Google Play Console account together involves the following.
- A Google Account and acceptance of the Developer Distribution Agreement
- A one-time registration fee of $25
- A choice between a personal or organization account
- Identity verification
Personal accounts created after November 13, 2023 face an extra gate. They must run a closed test with at least 12 testers opted in for 14 continuous days before production access (Play Console Help).
Releases move through tracks, starting small and widening.
- Internal testing takes up to 100 testers you choose, and builds are available within seconds.
- Closed testing uses a limited group you choose, for pre-release feedback.
- Open testing puts the build in front of testers on Google Play, and it opens up after production access for new personal accounts.
- Production reaches every Google Play user in your chosen countries.
Google Play also takes a service fee on digital sales, and the Google Play store fee tiers depend on revenue and product type.
Distribution outside Google Play has its own rules now. Android developer verification protections began on September 30, 2026 for users installing apps from participating stores in Brazil, Indonesia, Singapore and Thailand, on certified devices running Android 7 or higher.
Google plans a global expansion in 2027. Developers who distribute only outside Google Play register through the Android Developer Console, while Google Play registers 99% of its apps automatically (Android Developers).
Native Android or Cross-Platform: Which Fits?
Native wins for Android-only products and for apps that lean hard on device features. If one codebase has to ship on both Android and iOS, Flutter and React Native are the usual picks.
It mostly comes down to how many platforms you need and what the team already knows, plus how much of the app depends on Android-specific APIs.
Native, Flutter and React Native compared
| Approach | Language | Interface | Code reuse |
|---|---|---|---|
| Native Android | Kotlin or Java | Jetpack Compose or XML views on platform widgets | Android only |
| Flutter | Dart | Flutter’s own widgets, every pixel controlled | Mobile, web, desktop, embedded |
| React Native | JavaScript with React | Native platform components | Android, iOS and community ports |
A third option sits between them, and a broader comparison of native, hybrid and cross-platform apps adds the hybrid case.
Flutter’s homepage lists Google Pay and BMW among its users, and React Native’s showcase includes Microsoft Outlook and Shopify.
Both frameworks add a layer between your code and the platform. Flutter reaches native Android APIs through platform channels. React Native leaves routing and platform API access to you, and its documentation recommends a framework such as Expo.
When both cross-platform options fit, a direct Flutter and React Native comparison settles most of the remaining questions.
Android only, or heavy use of device features, goes native. If one team has to cover Android and iOS, the call depends on that team. Dart and a custom interface point to Flutter. A team that already writes JavaScript and React will get further with React Native.
When native Android development is the wrong choice
Native Android loses when the product is not really an Android product.
- The app must launch on iOS with identical features and there is no second team to build it
- The team already writes React, so React Native is the shorter path
- The brand needs one custom interface on every platform
- The goal is only a prototype to test demand
Cross-platform loses the other way. A single-platform Android product rarely gains from a framework layer, and Wear OS, Android TV and Android Auto are documented first in Google’s native guides.
How to Start Android Development, in Order
Installing Android Studio is the only setup most beginners need, because it brings the Android SDK with it. From there the path runs from a first project to a bundle on Google Play’s internal testing track.
- Create a project from a Compose template in Android Studio and run the generated app.
- Learn the Kotlin that the first screen needs. Google’s Android Basics with Compose course is the starting point for new developers.
- Run the app on a real phone. Developer options are hidden by default, so enable them, turn on USB debugging and connect the device.
- Add a second screen with navigation, then persist data locally.
- Set the target API level to the current Google Play requirement and build a signed app bundle in Android Studio.
- Upload the bundle to the internal testing track, then move through closed testing to production.
Google Play’s console flow has its own order, and a step-by-step guide to publishing an app on Google Play covers the store listing and release screens.
First apps tend to stall in a few predictable places. The closed-test window sets the earliest possible launch date for new personal accounts. Testing only on the emulator hides device-specific behavior. And a stale target API level blocks the submission.
Android Development FAQ
What does an Android developer do, and which skills matter?
Designing, building, testing and maintaining apps for Android devices is the job. The core skills are Kotlin, Android Studio, Jetpack Compose and Gradle, plus debugging with adb and shipping releases through Google Play Console.
Can you write Android apps in Python?
Not with the official toolchain. Python isn’t a supported language of the Android SDK, though third-party frameworks such as Kivy package Python code into Android apps.
Flutter (Dart) and React Native (JavaScript) are the usual alternatives to Kotlin.
Do I need to learn Java before Kotlin?
No. Kotlin works as a first language for Android, and Google’s beginner course teaches it.
Java still helps for reading older codebases, since the two languages interoperate and compile for the same runtime.
How does Android development differ from iOS development?
Almost everything differs. Android apps use Kotlin in Android Studio and publish to Google Play, while iOS apps use Swift in Xcode and publish to the App Store.
Xcode runs only on macOS, but Android Studio also runs on Windows and Linux.
Is Android development free?
Mostly yes. Android Studio and the Android SDK cost nothing, and neither does Kotlin. A Google Play Console account costs a one-time $25 with no annual fee.
Google also takes a service fee on digital sales.
Is Android development hard to learn?
It’s manageable with prior programming experience and slower from zero. Gradle builds, the activity lifecycle and state handling in Jetpack Compose tend to cause the most early friction.
Scope matters more than the platform. A single-screen app is far simpler than one with sync and local storage.
Keeping an Android App Current After Launch
Android work doesn’t stop at launch. Google Play accepts new apps and updates only when they target an API level within one year of the latest major Android release, so a maintenance cycle comes around every year.
Apps left without updates face a lower bar. The visibility floor for existing apps is API level 35, one level below the API level 36 that updates need (Play Console Help).
A typical cycle starts with raising targetSdk and reading the behavior changes. Next comes confirming SDK and Jetpack library support, then a staged rollout.
The order isn’t arbitrary. Target level goes first because it can block the submission, and an unsupported dependency fails at the new level, so library checks follow. The staged rollout comes last to limit exposure.
The price is a fixed block of engineering time every year, even without new features.
As of October 21, 2026, Android 17 (API level 37) has been out since June 16, 2026. If Google keeps the same schedule, the one-year rule puts the next target increase at roughly August 2027.
- SQLite cheat sheet - October 29, 2026
- Shared Hosting or VPS? A Practical Guide for Web Projects in 2026 - October 29, 2026
- Best Procore Alternatives: A Side-by-Side Comparison of Cost, Data Sharing and AI - October 28, 2026
