Building for Android as it really is
Fragmentation is a testing problem
You cannot test on every Android phone, so we choose a device matrix on purpose. It usually covers the oldest OS version you agree to support, a small low-memory phone, a current Samsung and Pixel, one device from a maker with aggressive battery management, and a tablet or foldable if layout matters. Emulators handle OS versions cheaply. Physical phones and a cloud device lab catch what emulators miss: camera quirks, keyboard overlap, font scaling and vendor permission screens. Where you set the minimum SDK is a business decision. Each older version adds users and adds testing, and we look at the version spread in your market with you before you choose.
Background work has rules now
Android restricts what an app may do when it is not on screen. Doze and app standby delay network access and jobs, starting a service from the background is blocked in most cases, and foreground services must declare a type and show a notification. So we sort every background need into one of three groups. Deferrable work such as sync or uploads goes to WorkManager with constraints for network and battery. Work the user is actively aware of, like turn-by-turn directions or a workout, runs as a foreground service. Time-critical triggers arrive as high-priority push messages. Anything that only works by fighting the system gets redesigned, because it will fail on real phones.
Compose, views and old code
New screens are written in Jetpack Compose. It is less code, easier to test and the direction Google is investing in. Existing XML screens do not have to be thrown away, since Compose and views can live in the same app and even the same screen. For older Java apps we move in steps: Kotlin first, then coroutines, then Compose where a screen is being changed anyway.
Getting through Google Play
A release is an Android App Bundle signed through Play App Signing. It moves from the internal testing track to closed testing with your own testers, then to production as a staged rollout that starts with a small share of users. We watch crash and ANR rates in Android vitals and halt the rollout if they climb. Before that, the Play Console needs an accurate data safety form, a privacy policy, content rating answers and declarations for sensitive permissions such as background location. Newer developer accounts may also have to complete a closed test before production access is granted, so we open the account and start that clock early. Digital goods sold in the app go through Google Play Billing, and we cover the server side of that under mobile app API integration.