Android Development: Kotlin, Jetpack Compose & Play Distribution

Q: Where does AI fit in Android apps?

On-device via Gemini Nano (AICore) and ML Kit for vision/language basics, LiteRT (TensorFlow Lite) for custom models — or any server-side API. Android's breadth means testing on-device AI features across wildly different NPUs; graceful fallback to cloud is the standard pattern.

Android Development

Android development means building for the platform that runs on roughly seven of every ten smartphones on Earth — with Kotlin as the language, Jetpack Compose as the modern UI toolkit, and Android Studio + Gradle as the toolchain. Unlike Apple's single-vendor world, Android is an ecosystem: Google steers the OS and Play Store, but thousands of manufacturers ship it on hardware from $80 phones to folding flagships.

That diversity is the job's defining texture. The APIs are excellent and the tooling is free on any OS — and your app must survive fragmentation: dozens of screen shapes, API levels years apart, aggressive vendor battery managers, and an OS that will kill your process whenever it likes. Android rewards developers who design for the platform's rules instead of fighting them.

TL;DR

The modern stack is Kotlin + Jetpack Compose (declarative UI) — XML layouts and Java are the legacy you'll read, not write.
The architecture Google actually recommends: Compose UI → ViewModel (StateFlow) → Repository → Room/SQLite + network, with coroutines/Flow for async and Hilt for DI.
Process death is a feature: the OS kills backgrounded apps; state must survive via ViewModel + saved state + persistence — the #1 mental shift from web/desktop.
Gradle builds everything; API levels (minSdk/targetSdk) define your compatibility window, and Play forces targetSdk currency annually.
Distribution is the Play Store: app bundles (AAB), staged rollouts, and lighter-touch review than Apple — plus the freedom (and fragmentation) of sideloading and alternate stores.
Choose native Android for platform depth and performance; React Native/Flutter for shared codebases — with Kotlin Multiplatform as the "share logic, keep native UI" middle path.

Quick Example

A modern Android screen — Compose UI, ViewModel, coroutines:

State flows down, events flow up, and rotation/dark-mode/process-death are handled by the architecture rather than by heroics — this shape is modern Android.

Core Concepts

Jetpack Compose vs Views

Same story as SwiftUI on iOS: write new screens in Compose, read Views fluently, and bridge (AndroidView/ComposeView) where codebases mix. Material 3 components, theming, animation, and adaptive layouts for tablets/foldables all live Compose-first now.

The Architecture That Survives Android

Android's lifecycle is the platform's sharpest edge: activities are destroyed and recreated on rotation; the OS kills backgrounded processes for memory. Google's recommended architecture exists to make that survivable:

ViewModel + StateFlow: UI state outlives the activity; collectAsStateWithLifecycle respects the lifecycle.
SavedStateHandle covers full process death for the small state that must survive it.
Room (SQLite with compile-checked queries) as local source of truth makes offline-first the default posture.
Coroutines + Flow are the concurrency story — structured, scoped, cancelled automatically with their owners; Hilt wires the graph.
WorkManager for deferrable background work (background jobs, platform edition) — because Doze mode and vendor battery managers will kill anything less cooperative.

Gradle, API Levels, and Fragmentation

Gradle (Kotlin DSL + version catalogs) builds, flavors, shrinks (R8), and signs; it's powerful and famously the part everyone loves to hate — cache aggressively, keep plugins current.
minSdk sets your floor (26–29 covers the vast majority of devices now); targetSdk declares which platform behaviors you've adopted — and Play mandates near-current targetSdk yearly, so permission and background-behavior migrations are a scheduled fact of life.
Fragmentation in practice: test on small/large/foldable screens, at least one low-RAM device, and one aggressive OEM skin (Samsung at minimum) — emulators cover breadth, physical devices reveal truth.

Shipping via Google Play

Play review is mostly automated and fast (hours, typically), with policy enforcement arriving as periodic sweeps — the operational risk profile is "surprise policy emails," versus Apple's "up-front human gate." Staged rollouts plus Play's crash/ANR vitals (watch them — bad vitals throttle your visibility) make careful releases routine. And uniquely to Android: sideloading, alternate stores, and enterprise distribution exist when Play doesn't fit.

Native Android vs Cross-Platform

Kotlin Multiplatform (KMP) deserves its own line: it shares business logic (models, networking, persistence) between Android and iOS while keeping fully native UIs — Google officially supports it, and it's the fastest-growing answer for teams who want sharing without abandoning platform UX. Cross-platform teams still need native Android literacy for modules, build issues, and platform behaviors — this page is infrastructure either way.

Common Mistakes

Pretending Process Death Doesn't Happen

Works in dev (you never background the app), crashes in production (users do). If your app can't survive "background it, let the OS kill it, come back," state lives in the wrong place. Enable "Don't keep activities" in developer options and make that your smoke test.

Doing Work the Platform Will Kill

Long-running threads, unguarded services, and "just a background loop" die under Doze and OEM battery managers — silently, and differently per vendor. Deferrable work goes through WorkManager; user-visible ongoing work uses foreground services with the required types.

Ignoring Low-End Devices

The median Android device globally is not your Pixel. Overdraw, huge images, main-thread I/O, and 200 MB baseline memory usage translate to ANRs and uninstalls at the market's core. Profile on cheap hardware; Baseline Profiles and R8 shrinking are free wins.

Requesting Permissions Like It's 2015

Modern Android permissions are runtime, granular (scoped storage, notification permission, approximate location), and increasingly one-time. Request in context with rationale, degrade gracefully on denial — permission-spam at launch is a top uninstall trigger and a Play policy risk.

Shipping Without Watching Vitals

Play's ANR and crash-rate thresholds affect store ranking and can trigger warnings. Wire up crash reporting from day one, watch vitals per rollout stage, and treat ANR traces as the priority queue they are.

FAQ

Kotlin or Java for Android?

Kotlin, without hesitation — it's been Google's preferred language since 2019, Compose is Kotlin-only, and modern APIs (coroutines, KTX) assume it. Java remains readable-required for older codebases; see Kotlin for the language itself.

Do I need real devices, or do emulators suffice?

Emulators cover most development and screen-size testing well. You need physical hardware for: cameras, sensors, real performance on low-end chips, OEM-skin behaviors (battery managers!), and NFC/BLE. Minimum viable lab: one flagship, one budget device, ideally one Samsung.

How different is Android from iOS development, really?

The concepts rhyme (declarative UI, MVVM-ish architecture, async/await vs coroutines), and knowing one accelerates the other. The deep differences: Android's lifecycle/process-death model, fragmentation, background-work restrictions, and the open distribution model vs Apple's gate. Teams building both should read iOS Development alongside this.

What about Play Store fees and policies?

Same 15% (first $1M, most subscriptions) to 30% structure as Apple for in-app digital goods, with Play Billing required — and the same regulatory turbulence loosening edges by region. Policy enforcement is automated-first: keep data-safety forms accurate and SDKs current, because violations arrive as emails with deadlines.

Where does AI fit in Android apps?

On-device via Gemini Nano (AICore) and ML Kit for vision/language basics, LiteRT (TensorFlow Lite) for custom models — or any server-side API. Android's breadth means testing on-device AI features across wildly different NPUs; graceful fallback to cloud is the standard pattern.