As of October 2026, 43.6% of active Android devices still run Android 13 or older, while Android 16, now the most common version, sits at 25.4% and Android 17 has crawled to 1% since its June release. Even Android 8.1 still has a bigger slice than the newest release. That spread is the job. On Android, launch day is the easy part, and the partner you choose shows its quality in month six, not week one.
I’ve shipped and maintained Android apps long enough to stop judging builds by their first week in the Play Store. Week one looks fine almost every time. The install curve climbs, the screenshots look sharp, the founder posts a launch thread on LinkedIn. Then the real users arrive, on phones nobody at the agency owned, running OEM skins nobody tested, and the app starts collecting one-star reviews that all say some version of “it just stopped working.”
So I use a simple filter now. I call it the month-six test: ignore the demo, ignore the launch, and ask what the app looks like half a year later. By then it has lived through at least one Android release, one target API deadline, a couple of Play policy emails and a few million background tasks killed by battery savers. A weak partner passes week one and fails that. A good one planned for it before anyone drew the first screen.
Porting the iOS app is how Android projects get into trouble
“An Android app is just the iOS app ported over.”
You hear some version of this in nearly every scoping call, usually from someone trying to cut the estimate in half. It’s half true for the UI layer, and that’s the dangerous half. Shared business logic through Kotlin Multiplatform or Flutter can save real money, and I’ve recommended both. The problem is everything under the UI, which is where Android apps actually live or die, and where the estimate quietly assumes nothing will happen.
Apple ships its OS to a few dozen device models from one manufacturer, and most of them update within months. Android ships to thousands of models from Samsung, Xiaomi, Oppo, vivo, Motorola, Google and a long tail of brands you’ve never heard of, each with its own skin, its own battery manager and its own opinion about what “background” means. Notifications. Background sync. Runtime permissions. Predictive back. Foldable hinges and split-screen. None of that ports. It has to be designed for, and then tested on hardware that behaves badly. An iPhone build that passes QA on three devices has covered a meaningful share of its audience. An Android build that passes QA on three devices has covered three devices.
That’s why I don’t start partner evaluations with the portfolio. Portfolios show launches. When I review proposals, from solo freelancers and from firms that sell full Android app development services alike, I ask one question first: what broke in your last Android app after launch, and how did you find out? A team that has maintained apps for years has a specific, slightly embarrassing answer ready. A team that only builds them talks about the launch party.
Here’s what the first year actually looks like, month by month.
Month 1: Android vitals grades you on phones your partner never touched
The first month is when Play Console starts filling Android vitals with real data, and Google doesn’t grade on a curve. The published bad-behavior thresholds are a 1.09% user-perceived crash rate and a 0.47% user-perceived ANR rate across all devices, plus 8% for either metric on any single phone model. Cross them and Google Play may reduce the app’s visibility and show users a warning on the store listing. Play judges the trailing 28 days, so one bad release lingers for a month.
The per-model threshold is the one that catches weak partners. An app can look healthy overall and still be falling over on one popular budget Galaxy or a Redmi running HyperOS, because the agency tested on two Pixels and the founder’s own phone. I’ve watched exactly this play out. The overall crash rate was clean. The ANRs clustered on one chipset family, and the cause turned out to be a database read on the main thread that only got slow on cheaper storage. Nobody on the team owned a phone with that storage.
A good partner handled month one before launch. They pulled the Play Console device catalog to see which models the target market really uses. They ran the pre-launch report and Firebase Test Lab across a spread of API levels, not just the latest two. They turned on StrictMode in debug builds, so disk and network calls on the main thread fail loudly in development instead of quietly in production. And they wired up crash reporting with mapping files uploaded, so a stack trace from a Xiaomi in Jakarta points to a real line of code instead of obfuscated noise.
The weak partner finds out about ANRs from the reviews.
Month 3: OEM battery savers are quietly killing your background work
By month three, the support inbox has a theme. Reminders arrive late. Step counts reset overnight. Chat messages appear only when the app is opened. Users blame the app, and honestly they’re right to, even though the cause lives in the phone’s firmware.
Don’t kill my app, the community-run tracker for this exact problem, puts it bluntly: many manufacturers “prefer battery life over proper functionality of your apps.” Its ranking gives Huawei, Xiaomi, OnePlus and Samsung the worst possible score, with Meizu, Asus and Oppo one notch better. Pixel and Android One devices score zero. Your users don’t buy Pixels in the proportions your developers do.
A weak partner writes background code that works on stock Android, ships it, and bills the fix as a change request in month three. A good partner treats OEM behavior as a requirement from day one. That means WorkManager for deferrable jobs, high-priority FCM messages only for things the user is actually waiting on, foreground services declared with the right foregroundServiceType (mandatory for apps targeting Android 14 and up), and an onboarding screen that walks Samsung and Xiaomi owners through the battery exemption with brand-specific steps. That last screen looks unglamorous in a design review. It also saves a support person a good chunk of every week.
Not a bug. Not a crash. A silent failure, which is worse, because vitals won’t flag it and your dashboards will say everything is fine.
Month 6: the target API deadline finds every shortcut
Month six is where the test earns its name, because for a lot of apps it overlaps with Google Play’s yearly target API bump. This year’s rules sit on Google’s target API level requirements page, and they’re stricter than most founders realize.
The dated numbers worth taping to a monitor:
- Since August 31, 2026, new apps and app updates must target Android 16 (API level 36) or higher to be submitted to Google Play.
- Existing apps must target at least API level 35 to stay available to new users on devices running a newer Android version than the app targets.
- November 1, 2026 was the latest an approved extension could push the deadline, so there is no more room to wait.
Raising targetSdkVersion is never just changing a number in Gradle. Each level changes platform behavior for your app, and API 36 carries a big one for large screens. According to Google’s adaptive apps guidance, on any display with a smallest width of 600dp or more, which covers tablets and the inner screens of book-style foldables, Android 16 ignores an app’s portrait lock, its resizeableActivity flag and its aspect ratio limits. There’s a manifest opt-out for now. The same guidance says it disappears at API level 37.
Picture the portrait-only app a cheap partner built. It looked great on phones. After the target bump, it opens on a Galaxy Z Fold’s inner display stretched across a nearly square screen, with a bottom sheet floating in the middle and a camera preview rotated the wrong way. Nobody wrote new code. The platform just stopped covering for the old shortcut.
A good partner built with window size classes and adaptive layouts from the start, so the bump costs a week of testing instead of a redesign. They also kept dependencies current through the year. That matters more than people expect, since an ad SDK or payments library pinned to a two-year-old version is often the thing that blocks the upgrade, and you can’t ship your fix until the vendor ships theirs.
Month 12: policy emails and ownership gaps show up together
At the one-year mark, the problems stop being technical and start being administrative, which is somehow worse. Play policy deadlines keep arriving on their own schedule. On September 30, 2026, Android developer verification began rolling out on certified devices for apps from participating stores in Brazil, Indonesia, Singapore and Thailand, and Play Console started asking developers to register any apps that weren’t registered automatically. On January 27, 2027, Play’s SMS and Call Log policy stops accepting phone-call account verification as a reason to request READ_CALL_LOG. Each change is small. Each one needs someone who reads the email, understands what it means for this specific codebase, and ships before the date.
Then there’s ownership. I’ve helped founders recover apps where the agency held the upload key, registered the Play Console account under its own name and kept the Firebase project inside its own organization. Nobody acted in bad faith. It’s just what happens when nobody writes the setup down. When the contract ended, the founder owned a store listing they couldn’t update.
A good partner set up Play App Signing on day one, created every account under the client’s organization, documented the release pipeline and left a runbook a new developer can follow on a Monday morning. They also plan the next bump before anyone asks. Google has raised the target requirement every year so far, so I expect API 37 to become mandatory for updates sometime in 2027, which would also end the large-screen opt-out for good. That last part is my inference, not Google’s published schedule.
The difference between a partner and a vendor fits in one table
| Partner capability | Failure it prevents | How to check it before signing
|
| Device matrix built from real market data | Crash or ANR rates above 8% on a single phone model | Ask for the device list from their last project and where it came from |
| Android vitals monitoring with alerts | Reduced visibility on Google Play and store-listing warnings | Ask to see a vitals dashboard they maintained, with the ANR trend over several months |
| OEM-aware background work | Late notifications and broken sync on Samsung and Xiaomi phones | Ask how they handle battery exemptions and which brands they test on |
| Yearly targetSdkVersion planning | Blocked updates after the August deadline | Ask what broke when they last moved an app to API 36 |
| Adaptive layouts for large screens | Stretched or broken UI on foldables and tablets | Ask for a demo of their latest app on a tablet or an sw600dp emulator |
| Client-owned accounts and signing keys | Losing the ability to update your own app | Ask who owns the Play Console account and upload key under their standard contract |
Notice that not one row asks about the launch.
Score your shortlist before you sign anything
Use this as a 0 to 2 scorecard for each candidate, 14 points in total. Anything under 10 means you’ll end up paying for month six twice.
- They answer the post-launch question with specifics. Score 2 if they name a real bug, the device it hit and how they caught it. Score 0 for “we test thoroughly.”
- Their device matrix comes from data. Full marks if it was built from the Play Console device catalog or analytics for your market. Zero if it’s whatever phones are on the office desk.
- They know the vitals thresholds cold. A partner who quotes 1.09% and 0.47% from memory has been burned by them at least once. Give 1 point if they know vitals exist but not the numbers.
- They’ve shipped a target API bump recently. Ask about the move to API 36 and what it broke. A clear story about specific behavior changes scores 2.
- Background work comes with an OEM plan. Score 2 if they bring up dontkillmyapp.com or brand-specific battery settings without prompting.
- Large screens are in the estimate. Foldables and tablets should appear as line items with hours attached, not as “phase two.”
- You own everything from day one. Play Console account, upload key, Firebase project, repository, CI. Anything held in their name scores 0, no matter how friendly the sales call was.
Launch day tells you who can build an Android app, and month six tells you who can keep one alive.
Join The Discussion: