Native Android
application development
in Long Beach

An Android build can reach the public in minutes. That speed is useful and dangerous in equal measure. Play Console offers a ladder of testing tracks so that a release meets a small, forgiving audience first, and each rung catches a different kind of problem.

The internal track is the fastest. Up to a modest list of testers can install a build almost as soon as it is uploaded, usually without waiting for review. It suits the people who work on the app and a few colleagues who will open it every day. Its job is to answer one question quickly. Does the build install, start and behave like the last one?

The closed track is where a release meets people outside the team. Testers join through an email list or a Google Group, and they receive updates through the normal store. This matters. Bugs that appear only after an update from the previous version, rather than a clean install, show up here and almost nowhere else. A migration of the local database is the classic case.

The open track lets anyone opt in from the store page. It brings volume and variety: odd devices, unusual languages, people who use the app in ways nobody planned. Feedback from open testers is noisier, so it helps to give them a clear channel, such as a form linked from the settings screen, instead of hoping they write a review.

Every upload also gets a pre-launch report. Google installs the build on a set of real devices, crawls through the screens automatically and records what happened. The report lists crashes, screens that took too long to render, accessibility warnings such as small touch targets or missing labels, and security notes about outdated libraries. It costs nothing to read. Many teams never open it.

The crawler has limits. It cannot sign in unless it is given test credentials in the console, so an app that starts at a login wall gets a very shallow crawl. It will not complete a purchase or scan a real document. Treat the report as a smoke alarm, useful for the obvious fire and silent about the subtle one.

Production itself can be released gradually. A staged rollout offers the new version to a small share of users, then a larger one, while the team watches crash rates and the reviews coming in. If something goes wrong, the rollout can be halted. Halting stops new installs of the bad version; people who already received it keep it until a fixed build arrives, so the fix still has to be quick.

A sensible routine ties these pieces together. Internal on the day of the build. Closed for a few days, long enough to cover an update path and a weekend of real use. Then a gradual production rollout, widened only when the crash and ANR dashboards look the same as they did for the previous release. Written down once, the routine stops depending on who happens to be on duty.

Most Android apps older than a few years draw their screens with XML layouts, fragments and adapters. Jetpack Compose replaces that with Kotlin functions that describe the interface for a given state. New projects start in Compose almost by default. The harder question is what to do with an app that already works.

A full rewrite is rarely the answer. Compose and the old view system can live in the same app, even on the same screen. A ComposeView can sit inside an XML layout, and an old custom view can be wrapped inside a composable. That interoperability is what makes a gradual migration possible, and it is the main reason to plan one instead of stopping the product for a quarter.

Where to start matters. Good first candidates are self-contained screens with little shared state: settings, an about page, an onboarding flow, a new feature that has no XML version yet. Bad first candidates are the complex list with swipe actions and nested scrolling that every other screen depends on. Move that one later, once the team has learned how Compose behaves under pressure.

A design system helps more than any other preparation. If colours, type styles and spacing already live in one theme, the Compose version can map them into a MaterialTheme and both worlds stay visually consistent during the transition. If every XML file hardcodes its own values, the migration exposes that mess. Fixing it first is cheaper.

State is where teams stumble. Compose redraws parts of the screen when the state they read changes. Code that mutated views directly, setting text here and visibility there, has to be rethought as data flowing down and events flowing up. ViewModels that already expose state as a flow adapt easily. Activities full of imperative calls do not.

Performance needs attention of a different kind. Recomposition is cheap when it is scoped well and wasteful when a whole screen redraws because one value near the top changed. Layout Inspector shows recomposition counts. Baseline profiles, shipped with the app, cut the cost of the first launch after install, which matters because Compose code is compiled on the device.

Testing changes as well. Compose has its own testing APIs that find elements by semantics instead of view IDs. Old Espresso tests keep working on XML screens, so the test suite migrates alongside the screens, one file at a time.

Expect the app to get slightly larger during the overlap, because both toolkits ship at once. It shrinks again as XML screens disappear. Track that number.

A practical signal that the migration is paying off is the time needed for a routine change. When adding a field to a form takes one file instead of four, the team feels it within weeks.

Every Android app declares a target SDK version. It tells the system which generation of platform rules the app was written for. Google Play raises the minimum target it accepts roughly once a year, and an app that falls behind stops receiving updates through the store. For many owners, this is the first time they learn that an app needs maintenance even when nothing is broken.

The deadline usually falls in late summer. New apps and updates must target a recent API level from that point, and existing apps that lag too far behind become invisible to users on newer devices. The announcement arrives months earlier. It is easy to ignore, and the cost of ignoring it lands all at once.

Raising the target is more than changing one number in a build file. Each Android release changes behaviour for apps that opt in by targeting it. Recent examples include tighter limits on when an app may start a foreground service, a requirement to declare the type of each foreground service, stricter rules for exact alarms, changes to how broadcast receivers are registered, and edge-to-edge drawing by default. Any of these can break a feature silently.

The official behaviour changes page for each release is the checklist. Read it against the codebase, feature by feature. Search for every place the app registers a receiver, schedules an alarm or starts a service. Then run the app on an emulator image of the new version and walk through the flows that depend on those parts.

Libraries complicate the job. A payment SDK, an analytics library or an old image loader may itself rely on behaviour that the new target forbids. Updating the target often means updating those libraries first, and sometimes a library is abandoned and has to be replaced. That discovery is the part that eats time.

Build tooling moves in step. A new target usually needs a newer Android Gradle Plugin, which needs a newer Gradle and sometimes a newer Kotlin version. Teams that let the build toolchain age for two years face a chain of upgrades before they can touch the actual target.

The target SDK and the minimum SDK are separate settings. Raising the target does not drop support for older phones. The minimum decides which devices can install the app at all, and it can stay low for as long as the business needs it.

A calm approach is to raise the target shortly after each new Android release becomes stable, well before the Play deadline. The change set is smaller. The testing is less rushed. And the release does not coincide with every other team scrambling at the same time.

Put the date in the maintenance calendar. It comes every year.