Android App Development Services for US & EU Brands

New projects start on Kotlin 2.x with the K2 compiler, target SDK 35 (Android 15), and set minSdk to 26 (Android 8.0) which covers roughly 95 percent of active US/EU devices. Google Play's policy requires targetSdk to be within one year of the latest major release, so we plan SDK upgrade sprints into the annual roadmap. For B2B fleet apps on rugged devices we drop minSdk to 24 (Android 7.0) with isolated AndroidX backports. Jetpack Compose is the default UI layer; View/XML interop is kept for legacy modules and CameraX/PdfRenderer paths where Compose is still catching up.

We run a pre-flight against the most common rejection categories: Data Safety form mismatched against actual SDK behaviour, missing Account Deletion (required since May 2024 in-app and from the web), foreground service types not declared correctly on Android 14+, restricted permissions without a Permissions Declaration Form (SMS, Call Log, AccessibilityService, MANAGE_EXTERNAL_STORAGE), and Families policy violations. We also fix the Pre-Launch Report crashes Google runs on Firebase Test Lab devices before our internal release, which catches 80 percent of post-publish 1-star reviews.

Google Play Billing Library 7.x is the default for digital goods (Play policy still requires it inside the Play distribution channel for most categories). For EU users we implement the User Choice Billing pilot where eligible — users see Play Billing alongside the developer's own processor, with the corresponding service-fee reduction (3 percent). For DMA-relevant categories we support alternative distribution via direct APK install flows with the proper Install Unknown Apps user prompts, and we keep a separate Play track for the same app. Subscriptions use the new base-plan/offer model with proper price-change consent flows.

Compose-first since 2023 for all new code: Compose 1.7+ with the strong-skipping mode, Compose Navigation with type-safe routes, Compose Material 3 with dynamic color, and Compose for Wear OS where the product extends to watches. ViewModels use Kotlin Coroutines and StateFlow, dependency injection via Hilt, data layer with Room and DataStore. We still embed AndroidView/ComposeView interop for CameraX preview, AdMob native ads, ExoPlayer (Media3), and PdfRenderer until Compose-native equivalents are production-ready. Baseline Profiles are generated for every release to keep cold start under 500 ms on mid-range devices.

GDPR-aligned by design: lawful basis documented per data category, Google's User Messaging Platform (UMP) SDK for IAB TCF v2.2 consent in the EU, granular data export and account deletion (also a Play policy requirement), and DPAs with every third-party SDK. The Data Safety form is filled from a single source of truth that we audit against the actual SDKs in the bundle — mismatch is the #1 cause of policy enforcement actions. For EU customers we host backend infra in eu-central-1 or europe-west3, enable Android Privacy Sandbox where the product uses ad attribution, and keep PII out of Crashlytics/Sentry with breadcrumb scrubbing.

Android apps are fixed-scope and quoted all-in in USD, tiered by product ambition. An MVP runs from $3,500 (4–8 weeks): the first working app with one core flow on Kotlin 2.x and Jetpack Compose plus a Google Play release. A production app is from $5,800 (several features, backend integration, offline persistence, analytics). A full product is from $9,200 (multiple modules, roles, external integrations, CI/CD and device QA). A complex app with payments, offline-first sync, native SDKs and A/B experiments is from $11,500. What moves the number is form-factor count, integration and permission depth, billing complexity and compliance scope. You see the line-item budget before any code is written and sign off on it.

We build against the Android Device Matrix — phones (compact, medium, expanded window size classes), 7–12 inch tablets, foldables (inner and outer display continuity with WindowSizeClass and fold-aware layouts), and large screens — using WindowSizeClass and adaptive layouts from day one rather than bolting them on. minSdk 26 covers ~95% of active US/EU devices; we drop to 24 for B2B fleet use cases with isolated AndroidX backports. OEM battery optimizer quirks (Samsung, Xiaomi, OnePlus, Huawei) are tested on real hardware for background tasks, not just emulated. Baseline Profiles are generated per release to compensate for varying JIT compilation behavior across OEM builds, keeping cold start under 500 ms on a Pixel 6a-class device even after a Play Console auto-update.

Yes. Wear OS 4/5 with Compose for Wear, Tiles, and Complications is our standard path for smartwatch companions — health and fitness apps, notification bridging, and offline workout tracking that syncs to the phone via Wearable Data Layer. Android Auto and Automotive OS apps follow AAOS design guidelines for distraction-tested in-car UX, with voice interaction via Car App Library and turn-by-turn routing integrated with the phone app. Android TV uses the Leanback library and Compose for TV for 10-foot UI with remote and DPAD navigation. Each form factor goes through Google Play's large-screen and automotive quality tier reviews, which we pre-flight before submission.

Offline-first means the app is fully functional with no network, not just gracefully degraded. We use Room as the single source of truth with a reactive StateFlow layer so the UI updates instantly from the local database, then a sync engine that reconciles with the backend when connectivity returns. Conflict resolution strategy (last-write-wins, server-authoritative, or CRDT-based) is agreed in discovery based on the data model. WorkManager handles background sync with exponential backoff and network constraint awareness, so the sync job runs when the device has a suitable connection without draining the battery. We have shipped offline-first in logistics (xRouten, where drivers submit delivery confirmations in dead zones), HealthTech, and field inspection scenarios where connectivity is structurally unreliable.

Yes, and this is a common engagement for us. The standard approach is incremental: we convert Java files to Kotlin with IntelliJ's automatic converter, then clean up nullability, coroutines, and idiomatic Kotlin by module. The UI migration from XML Views to Compose is done screen-by-screen using ComposeView interop so the old and new UI coexist without a big-bang rewrite — your app keeps shipping to users throughout. We also migrate RxJava chains to Kotlin Coroutines and StateFlow, AsyncTask/Loader to ViewModel, and Groovy build scripts to Kotlin DSL with version catalogs. The migration is sized in our initial discovery assessment, and we commit to not introducing regressions by running the existing Espresso test suite against each Compose screen as it ships.

We apply the standard Android testing pyramid: unit tests with JUnit5 and MockK for business logic and ViewModels (fast, no device required); integration tests with Room in-memory databases, Hilt TestComponent, and Retrofit MockWebServer for data layer contracts; and UI tests with Compose Test and Espresso for end-to-end flows. Compose semantics make UI tests far more stable than screenshot diffing on View hierarchies. Macrobenchmark and Microbenchmark measure cold start and scroll performance on Baseline Profile targets. Pre-Launch Report failures on Firebase Test Lab are fixed before every internal release, catching device-specific crashes on Samsung and Pixel hardware in the test lab before real users encounter them. For regulated industries we add additional security test passes covering data-at-rest encryption, network traffic analysis, and certificate pinning verification.