Do you write Android apps in Kotlin or Java?

New work is Kotlin, with Jetpack Compose for screens and Coroutines or Flow for asynchronous logic. When we inherit a Java codebase we keep it running, migrate module by module as we touch it, and avoid a big-bang rewrite that stalls feature work for months.

Why does my app stop working in the background?

Android suspends background work through Doze, app standby buckets, and limits on starting services, and several manufacturers add their own battery managers on top. The fix is usually WorkManager for deferrable jobs, a correctly typed foreground service for continuous ones, and clear handling when a vendor kills the process anyway.

Will my app pass Google Play review?

Store review outcomes depend on policy compliance, not on our wishes. We prepare the data safety form, permission declarations, privacy policy, target API level, test credentials, and listing claims so that what the app does matches what the review team is told. We cannot promise an approval date if Google changes its rules mid-review.

How many Android versions and devices do you support?

We agree a minimum API level with you before the build starts, usually covering the large majority of active devices without dragging old platform bugs into the codebase. Testing covers phones, large screens and foldables in both states, and the manufacturer builds your users actually own.

Can you take over an unfinished Android app?

Yes, and we see two common cases. An older Java or Kotlin codebase that needs a current target API and dependency cleanup, or an AI-assisted prototype that runs on the developer's phone but has no signed release build and no store paperwork. The audit decides which parts we keep.

Native Android App Development

Kotlin and Jetpack Compose Android apps built for real device variety, current permission rules, background limits, and Google Play review.

See our work:

CalculatorX (HideX)→Calculator Lock - Android App→Easy VPN Free→

A native Android app has to run on hardware you have never held: a Samsung flagship, a Xiaomi mid-ranger sold in Paphos, a foldable opened halfway through a task, and a five-year-old phone still on an older Android version. Google moves the rules as well, raising the minimum target API level each year and tightening background execution and permissions.

Most of the money in an Android project sits between the build that works on the developer's phone and the release that behaves everywhere else. Closing that gap is our work: Kotlin and Jetpack Compose, background jobs that survive Doze and manufacturer battery managers, and a Play Console submission that answers the questions review teams ask.

What native Android development means here

Native means Kotlin against the Android SDK, Jetpack Compose for new screens, and platform libraries where they fit: WorkManager, Room, DataStore, CameraX, Hilt or Koin. Gradle carries debug, staging, and release variants, and each release is a signed Android App Bundle.

Native is the right route when the product leans on the platform: cameras, a VPN service, Bluetooth hardware, sensors, on-device files, or long-running background work. For a list-and-form app with no special device access, cross-platform mobile app development reaches both stores for less money, and we will say so.

Who it is for

We build Android-first products for utilities, privacy and vault tools, VPN clients, camera and media apps, and booking or field-service tools. We also take over existing apps that must reach a current API level, keep failing review, or crash on manufacturer builds their own testing never covered.

Where the project starts

A plain idea or a Figma file is a build from zero: discovery fixes scope and data model, and the first milestone is a running build on a real device.

An existing codebase, often Java or an older Kotlin stack, starts with an audit of Gradle state, dependencies, target API level, and the riskiest screens, then a decision to refactor in place or rewrite.

An AI/vibe-coded prototype starts differently again. We keep what works and repair what real devices, review, and security will break. Prototypes usually arrive without a signed release build or Play data safety answers, and with background work that a battery manager kills. Hardening it costs less than rebuilding.

What we deliver

A signed release build and the source that produces it:

Kotlin application with Compose screens, navigation, theming, and adaptive layouts for phones, large screens, and foldables
Background work through WorkManager, foreground services with declared types, and scheduled jobs that respect battery limits
Permission flows written per Android version, with rationale, refusal paths, and no requests the feature does not need
Local storage and encryption for sensitive user data, with keys held in the platform keystore
Networking and backend integration, including the work covered under API development and integration
Crash reporting, staged rollouts, and an internal testing track before production users see a release
Play Console preparation: listing assets, data safety form, content rating, target API level, and review notes with test credentials

Screens, foldables, and manufacturer builds

Android screens range from compact phones to tablets and foldables that change shape while the app is open. We use window size classes and adaptive layout instead of one fixed phone grid, and we test resizing on real hardware rather than only in the emulator.

Manufacturer builds add their own behaviour. Samsung One UI, Xiaomi HyperOS, Oppo and Realme ColorOS, Honor, and Huawei devices without Google Play services change notifications, background process limits, and autostart rules. Some markets we work in have phones with no Play Services at all, which changes the choice of push messaging, maps, and billing.

Background work and battery optimisation

Android has been trimming background execution since Android 8, and Doze plus app standby buckets decide how much work an idle app may do. A job that runs in the emulator may be deferred for hours on a phone whose owner has not opened the app in two days. We place deferrable work in WorkManager, keep continuous work in a foreground service with a correctly declared type, and use exact alarms only where the product cannot function without them.

Battery manager exemptions exist, and asking for one is a decision rather than a default. We request it only where the core feature depends on it, since an app that demands broad permissions during onboarding loses users.

Permissions across Android versions

The permission model has changed in steps: runtime permissions in Android 6, one-time grants and automatic permission reset in Android 11, approximate location in Android 12, the notification permission and split media permissions in Android 13, and declared foreground service types plus selected-photo access in Android 14. Background location is a separate, stricter grant. We ask at the moment the user needs the feature, explain the reason in the interface, and keep every feature usable in a reduced state when access is refused.

Play Store policy areas that cause rejections in utility apps

The data safety form must describe what the app and its third-party SDKs actually collect, and reviewers compare it against observed network traffic. Sensitive permissions need a stated purpose, and some categories require a declaration form or a demonstration video. Minimum functionality rules reject apps that wrap a website or duplicate a listing with minor changes. Deceptive behaviour rules apply to disguised interfaces: a vault app with a calculator icon is fine when the listing and onboarding explain it, and a problem when the app hides its purpose from its own user. Ad rules stop full-screen ads on launch and ads drawn outside the app. Accounts must offer in-app deletion and a reachable privacy policy, digital goods must use Google Play Billing, and the minimum target API level rises every year, so an untouched app eventually stops accepting updates. Reviewers also need working test credentials, since a login wall stops the review.

What it costs

We quote at the flat rate of $39 per hour, or as a fixed scope once requirements are clear. Teams with continuous work use the monthly capacity plans from $2,699.

A single-platform Android build is a smaller order than a two-platform MVP. The pricing page lists a mobile MVP typical order of $4,800 to $8,500 across four to six weeks for roughly 20 to 25 screens on iOS and Android with a backend; an Android-only first release usually sits below that, while payments, hardware integration, and heavier compliance work push it above. The scope drivers are discovery, device and manufacturer testing, permission and background-work engineering, store paperwork, and how much backend the app needs. We describe those phases in weeks and estimate each one before you commit.

Proof

Calculator Lock is an Android vault app on Google Play that hides photos, videos, and files behind a disguised calculator icon, with fingerprint access, a decoy vault, and intruder alerts. It shows a privacy utility shipped through Play review with sensitive permissions and a listing honest about the disguise.

CalculatorX (HideX) is the same product idea on the other platform, with PIN-protected vault access, a deceptive vault, a recovery flow, and subscription packaging. That pairing matters when an Android build has to stay in step with an existing iOS app.

Easy VPN Free is our open-source Android VPN app, built on VPN Gate and OpenVPN, with the code public on GitHub under GPL-3.0. It covers long-lived platform integration, including the VPN service and the foreground service that keeps a connection alive while the phone is idle.

Related services

Mobile apps development for the wider practice across iOS and Flutter
SDK and API version upgrades when an existing app needs to reach the current target API level before the next submission
App Store and Google Play publishing support for listings, assets, signing, submissions, and rejection follow-up
App security audit and hardening for local storage checks, key handling, and API protection on the device

Next step

If you have an Android product to build, an app stuck below the current target API level, or a prototype that runs on one phone and nowhere else, send us the details. We will tell you what it takes to reach a signed release.