Android app development services
Android app development for real-world devices
Comtau builds custom Android apps in Kotlin with Jetpack Compose. They are tested on the phones and OS versions your users actually have, and they handle background work within Android's limits. We keep them compliant with Google Play's yearly requirements.
Compactphone
Mediumfoldable, unfolded
Illustrative example - not a client project
Android in practice
Where Android projects get hard
Building the screens is the predictable part. The engineering effort goes into four areas that experienced Android app developers recognise, and that any Android app development company should plan for.
- 01
Thousands of devices
Different screen sizes, manufacturer skins and OS versions behave differently. Coverage is planned from usage data, not guessed.
- 02
Background limits
Doze mode and manufacturer battery savers stop naive background code. Syncing and location tracking have to use the APIs Android allows.
- 03
Runtime permissions
Users can deny camera, location or notification access, or grant it only once. The app needs a working path for every answer.
- 04
Google Play's moving rules
The target API level, data safety form and policy updates change every year. Falling behind blocks new releases.
Designing for Android
Asking for access the way Android users expect
A courier app needs the camera to scan labels, but the courier can say no. The app explains why before Android asks, and it still works if access is refused.
Explain first
The app shows why the camera is needed at the moment it is needed, not on first launch.
Asked only when needed
The system asks
Android's own dialog appears. Users can allow access while the app is in use, allow it only this time, or deny it.
Denied? Still works
Work either way
If access is denied, the courier types the label code instead, and the delivery is still recorded.
Device coverage
Built for phones, foldables and tablets
Layouts are designed for window sizes, not device models, so the same app works on a compact phone, an unfolded foldable and a tablet.
Compact width
Phones
Compact layouts with bottom navigation; tested across the manufacturers and OS versions in your data.
Medium width
Foldables
List and detail side by side when unfolded; state is kept when the device folds.
Expanded width
Tablets & managed devices
Navigation rail and multi-pane screens; rugged and kiosk devices for enterprise use.
- Minimum version
- Chosen from your analytics or market data, not a fixed rule. Each older version supported adds testing.
- Test matrix
- Emulators for breadth, physical devices for the most common models, and a cloud device lab for the long tail.
- After release
- Android vitals and crash reporting show problems by device, manufacturer and OS version.
What we build
Custom Android app development services
From consumer apps on Google Play to tools for company-owned device fleets, built in Kotlin with Jetpack libraries.
Phone & tablet apps
- Compose interfaces with Material Design
- Adaptive layouts for tablets and foldables
- Deep links and app shortcuts
Offline & background sync
- Local Room database as the source for screens
- WorkManager jobs that survive restarts
- Conflict rules agreed with you
Hardware integration
- Camera, barcode and document scanning
- Bluetooth LE devices and NFC
- Location with battery-aware tracking
Managed-device apps
- Apps for company-owned fleets
- Managed configuration from your MDM
- Private distribution through managed Google Play
Payments & billing
- Google Play Billing for digital goods
- Card processors for physical goods
- Subscriptions and receipt validation
Legacy modernization
- Java to Kotlin, file by file
- XML views to Compose, screen by screen
- Raising old target API levels
Apps for field and warehouse teams are covered in more depth on enterprise mobile app development.
Engineering choices
The Android stack we use, and why
| Area | Our usual choice | Why |
|---|---|---|
| Language & UI | Kotlin with Jetpack Compose; existing XML views kept where they work | Google's recommended path. Less code, and previews and tests for every screen. |
| Architecture | Unidirectional data flow: ViewModels with StateFlow, repositories, use cases | Screen state is predictable and testable, and it survives rotation and process death. |
| Data & offline | Room for local data, DataStore for settings, WorkManager for sync | Reliable offline behaviour within Android's background execution limits. |
| Dependency injection | Hilt | A standard structure that new Android developers recognise quickly. |
| Testing | JUnit for logic, Compose UI tests for journeys, device-lab runs before release | Catches device-specific breakage before a staged rollout does. |
| Delivery | Gradle builds in CI, Play App Signing, internal testing track on every merge | Your team always has an installable build, and signing keys are protected. |
Scroll sideways to see the full table.
Google Play release
From internal testing to a staged rollout
Releases reach a small share of users first. If crash or ANR rates rise on a device group, the rollout stops before most users see the problem.
Google Play
Android phones, tablets and foldables
- Build bundleCI produces a signed Android App Bundle; Play generates optimized APKs per device.
- Testing tracksInternal and closed testing tracks put the build on real devices first.
- Play reviewGoogle reviews the release against policy, target API level and data safety declarations.
- Staged rolloutThe update reaches a chosen percentage of users first and can be halted.
- MonitorAndroid vitals show crash and ANR rates by device and OS version.
- Automated
- Review or decision point
- Live with real users
- Phones · Android 14 and later0.21%
- Foldables and tablets0.26%
- Rugged scanners · managed0.18%
- Android 10–11 devices1.10% · hold
App Bundle & signing
Releases ship as Android App Bundles with Play App Signing. The upload key and the app's ownership stay with your organization.
Data safety
The data safety form matches what the app and its SDKs actually collect. We review it whenever an SDK is added or updated.
Target API level
We track Play's yearly target API deadline and raise the target before it blocks your next update.
Questions
Frequently asked questions
How much does it cost to develop an Android app?
On Android, cost depends on the usual factors: journeys, offline needs, integrations and backend. Three Android-specific factors add to them:
- how wide a range of devices and OS versions you must support;
- whether the app uses hardware such as scanners, Bluetooth devices or NFC;
- whether an older Java app has to be modernized along the way.
When comparing quotes from an Android application development company, check that device coverage and Play compliance are included. We estimate after discovery, against a written first-release scope. See what drives mobile app development cost.
Is Kotlin or Java better for a new Android app?
Kotlin. Google has recommended it for Android since 2019. New Jetpack libraries and Compose are designed around it, and its null safety and coroutines prevent whole classes of crashes. Java code still runs and interoperates, so existing Java apps can move to Kotlin one file at a time.
Do you build with Jetpack Compose?
Yes. New interfaces are built with Jetpack Compose, Android's modern UI toolkit. In apps that still use XML views we add Compose screen by screen, because the two can live side by side. A full UI rewrite is rarely needed.
What replaced the APK on Google Play?
New apps on Google Play are published as Android App Bundles (AAB). Play uses the bundle to generate APKs optimized for each device's screen, language and processor, which keeps downloads smaller. APKs are still used for direct installation and some enterprise distribution, but not for new Play listings.
Does Google Play require a minimum target API level?
Yes. Google Play requires new apps and updates to target a recent Android API level, and the deadline moves forward every year. Apps that fall behind can no longer be updated, and may become hidden from users on newer devices. Raising the target level is a routine part of mobile app maintenance, because it can change how permissions and background work behave.
Which Android versions and devices will the app support?
We set the minimum version from your own analytics or your market's data rather than a fixed rule, because each older version supported adds testing. The device test matrix covers the screen sizes, manufacturers and OS versions your users actually have. It combines emulators, physical devices and a cloud device lab.
Planning an Android app?
Tell us about your users, their devices and what the app has to do. We'll suggest an approach and the first release that makes sense.
- Tell us who will use the app and what it has to do.
- We suggest a first release and the approach that fits it.
- You get an estimate tied to a written first-release scope.