Android apps that work on the phones your users actually own
Kotlin and Jetpack Compose, tested on old hardware and odd OEM skins, shipped through staged rollouts. Built by senior engineers who respect how messy Android really is.
Android is not one platform. It is thousands of devices, a dozen OS versions in active use, and manufacturer skins that each break something different. We build in Kotlin and Jetpack Compose because native code gives us the control to handle that mess: adaptive layouts for odd screen sizes, graceful fallbacks on old hardware, and workarounds for the aggressive battery managers some manufacturers ship. Cross-platform frameworks hide those problems until your one-star reviews find them. Etlon has been building software since 2001, and we test on the phones your users own, not just the flagship in an engineer's pocket. That includes the four-year-old budget device with 3 GB of RAM, because for many audiences that is the median phone, and an app that stutters there is an app that gets uninstalled.
Shipping on Google Play is its own discipline. We run staged rollouts: release to a small percentage of users, watch crash rates and ANRs in the Play Console, and widen only when the numbers hold. That habit has saved more launches than any amount of pre-release testing. We design background work around Android's real limits, using WorkManager and foreground services correctly so your sync jobs survive Doze mode and OEM task killers instead of dying silently. Play policy gets the same attention: data safety forms, permission declarations, and target SDK deadlines are handled before they become emergencies. Once you are live, you get a release pipeline that builds, signs, and promotes through testing tracks automatically.
- A Kotlin and Jetpack Compose codebase you own outright, organized so any experienced Android engineer can work in it immediately
- A device test matrix that covers old OS versions, low-RAM hardware, and the OEM skins your analytics say your users run
- Staged rollouts with clear go or hold gates, so a bad build reaches five percent of users instead of all of them
- Background sync and notifications built on WorkManager, engineered to survive Doze mode and manufacturer task killers
- Play Console compliance handled for you: data safety forms, permission declarations, and target SDK deadlines met on time
- An automated pipeline that builds, signs, and promotes releases through internal, closed, and production tracks
How we work
Scope and device matrix
We define the app, then decide exactly which OS versions and device classes it must support, based on your users rather than habit.
Build on real hardware
Weekly builds go to your testers through Play testing tracks, and we test on physical devices, including old and low-end ones.
Staged rollout
We launch to a small slice of users, watch crashes, ANRs, and reviews in the Play Console, and expand only on clean numbers.
Monitor and iterate
After full rollout we track stability and engagement, fix what the data flags, and keep releases moving on a steady cadence.
Work we have shipped
DraftEdge
Machine-learning player projections that keep pace with live injury news right up to lineup lock.
ML pipeline in production Read the case studyStockZ & The Whisper Number
Real-time market data, earnings estimates, and whisper numbers — where a stale figure costs the user money.
Real-time through peak load Read the case studyCommon questions
As far as your users require and no further. We pull the version and device breakdown from your analytics, or from market data if you are pre-launch, and set a minimum SDK that covers the audience you actually have. Supporting ancient versions has a real cost in testing and workarounds, so we show you the tradeoff in numbers and let you decide.
Manufacturer skins change how Android behaves, especially around background work. Several OEMs kill background processes aggressively to stretch battery life, which silently stops sync jobs, notifications, and alarms. We build background work to the platform's documented limits, add the known OEM workarounds, and verify on the affected devices themselves.
Often, yes. We start with a paid audit of the code, the crash and ANR data, and the reviews, then tell you plainly whether the app needs surgery or a rebuild. Ratings usually recover once crashes stop and background features start working reliably. We fix stability first, then features, and use staged rollouts so the recovery never goes backward.
Tell us where Android is hurting you. An engineer replies within one business day.
One business day. From an engineer. No sales sequence.
or email customers@etlon.net