Android 17 and targetSdk 37: What Founders Need to Plan

Android 17 reached stable release on June 16, 2026, at API level 37. For four months it has been the engineers' problem. It stops being only theirs when two things happen: Google Play asks you to raise your target level, and a policy change makes the upgrade more than a version bump.

The second one is close. Google Play's new Contacts Permissions policy and updated Location Permissions policy take effect on October 28, 2026, four days from now. From October 27, new pre-review checks in Play Console are meant to flag contact and location permission problems before you submit. For apps targeting Android 17 or later, Google's guidance says an app may request READ_CONTACTS only if the Contact Picker cannot support its core feature, and apps that keep the permission must submit a declaration in Play Console explaining why.

A note on sources. The release date and API level agree across the coverage I found, and the policy dates come from Google's own Play policy announcements. I did not find a confirmed Play deadline for when apps must target API 37, so I will not invent one. Check the target API requirements page in Play Console for your account's date. If you have not touched your Android build since last year, expect to be asked within the next year, based on how Google has handled earlier levels.

This article is the founder version. It covers what changes, what it costs, who should do it and in what order. It is not a code walkthrough.

Engineers use these two settings differently, and founders get confused when a status update says "we're on 37."

• compileSdk decides which Android APIs your code can call. Raising it to 37 is low risk. It gives developers access to new APIs and rarely changes how the app behaves for users.
• targetSdk tells Android which version's behavior your app was built for. Raise it to 37 and the system stops applying compatibility shims, so your app runs under the newest rules. That is where things break.

Google's setup guide says the same: update compileSdk to 37 to use the APIs, and move targetSdk to 37 when you are ready to opt in to the new runtime behaviors. So an app can be "on Android 17" in a changelog and still be running old behavior. Ask which setting moved.

The Play requirement is about targetSdk. That is the one with consequences, and the one worth scoping carefully.

Some changes apply to every app, whatever its target. The reported list includes RAM-based app memory limits, stricter rules for background audio, and a three-hour delay on WebOTP text messages for apps that are not the verified recipient. These can hit you even if you never touch targetSdk, so a smoke test on an Android 17 device is worth doing now.

The three changes most likely to matter to a product team:

Large-screen orientation and resizing

For apps targeting 37, Android 17 removes the developer opt-out for orientation and resizability restrictions on large screens. Games are exempt. In plain terms, if your app locks to portrait and refuses to resize, on a tablet or a foldable it will now be forced to behave. Screens that were never designed for a wide orientation or a half-width window will stretch, clip or overlap.

This is the change with the biggest visible effect. A phone-only app can look broken on a Pixel Tablet or a foldable, and reviewers and users do test on those. If your analytics show less than 2 percent of sessions from large screens, you may still decide to do the minimum. But the minimum is a real piece of work, and it is the main cost driver of the upgrade.

The lock-free message queue

Apps targeting 37 get a new lock-free MessageQueue. Most apps never notice. A small number of apps and libraries that poke at the queue's internals through reflection can break. This is a dependency question: ask the engineer to check which libraries touch it.

Contacts, location and the policy overlay

The Play policy is a separate track from the OS change, but the two arrive together in practice. If your app asks for READ_CONTACTS to power an invite-friends screen, the Contact Picker usually does the job with no permission and no declaration. That is both the easiest compliance path and a better prompt for users. If you need broad contacts access, such as a dialer or a CRM, expect to explain why in the declaration.

One more item came up in third-party coverage: a new ACCESS_LOCAL_NETWORK permission for apps that talk to devices on the local network. I could not confirm it in Google's official pages, so treat it as a question for your engineer to verify against the behavior-changes documentation. If your product controls smart-home devices, printers or media players, check it early.

You can size the work without writing any code. Ask your Android engineer or agency for the following, in this order. Each takes under an hour.

1. The current compileSdk and targetSdk. If targetSdk is two or more levels behind, the jump is bigger than it looks. Each skipped level carries its own behavior changes.
2. The manifest permissions list. Every permission with a one-line reason. Anything nobody can explain is a candidate for removal. This is also the list Play will read.
3. Large-screen sessions. A count from your analytics of sessions on tablets and foldables, and the top five screens used on them.
4. Orientation locks. A grep for screen orientation settings in the manifest and code. Each lock is a screen to retest.
5. Third-party SDK versions. Analytics, ads, payments, maps, push. List any that have not shipped a release in 12 months. Those are the ones that break.
6. Test devices. What the team actually has. At minimum: one current Pixel on Android 17, one mid-range phone from a different maker, one tablet or foldable (a cloud device farm works if buying hardware is not an option).

With those six answers you can ask for a real estimate. Without them, any number you are given is a guess, and I would be skeptical of a fixed price offered before the audit.

Market ranges, not our pricing, and they depend on how far behind you are and how many screens you have.

• Already on 35 or 36, simple phone app, under 30 screens: roughly 2 to 5 engineering days, including regression testing. Expect $2,000 to $6,000 at typical agency or contractor rates in the US.
• Phone-first app with a portrait lock and a meaningful tablet audience: 2 to 4 weeks, because layouts need adaptive treatment. $8,000 to $25,000 is a common band.
• Several levels behind, with old SDKs and a legacy architecture: 4 to 10 weeks. $20,000 to $60,000, and at that point you are close to a modernization project rather than an upgrade.
• Cross-platform apps (React Native, Flutter): the native shell is a smaller job, but you wait on the framework release that supports 37, and your plugins have to catch up. Budget a week for the shell and an unknown for the dependencies.

The cost drivers are screens that need responsive layouts, untested third-party SDKs, missing automated tests, and how far behind targetSdk is. The cheapest fix by far is not letting it slip. An annual upgrade of three to five days beats a four-week rescue every time. For a broader picture of what running an Android product costs across a year, see how much Android app development costs.

One planning point: do not bundle the upgrade with a feature release. If the build crashes on a foldable, you want to know which change caused it.

This is the sequence I would give a team that has never done it.

Step one: smoke test on Android 17 today. Install the current production build on a device running 17 without changing any settings. Check login, push notifications, audio playback, any one-time-code flow, and anything that uses the camera or a contacts picker. This tells you what the all-apps changes already do to you.

Step two: raise compileSdk and update dependencies. Do this on a branch. Update the Android Gradle plugin, Kotlin and the SDKs on your list. Ship it to internal testers before you touch the target.

Step three: fix permissions. Replace READ_CONTACTS with the Contact Picker wherever the feature is sharing or inviting. Move one-time location requests to the location button. Remove permissions nobody can justify. Fill in the Play Console declaration for any that remain.

Step four: raise targetSdk to 37 on its own branch. Walk the top screens on a tablet and a foldable in both orientations and in a split window. Fix what breaks. Add screenshot tests for the top five screens at three window sizes so the next upgrade is cheaper.

Step five: staged rollout. Release to 5 percent, watch crash-free sessions and ANR rate for a few days, then widen. Our write-up on staged rollouts and crash thresholds has the numbers I use to decide when to stop a rollout.

If your Play account is also working through developer verification, run it in the same quarter so the team context is shared. The Android developer verification action plan covers that side.

If you have an in-house Android engineer who has shipped a targetSdk bump before, let them do it. Give them the audit list and two weeks of protected time rather than an afternoon between tickets.

If your app was built by an agency that has gone quiet, or by a contractor who left, start by confirming you own the repository, the signing keys and the Play Console account. Without the upload key you cannot ship an update at all. That is a bigger problem than API 37, and it is better to find it now than the week Play asks for a new target.

If your app is cross-platform, talk to whoever owns the framework upgrade. The shell change is small, but the order matters: framework first, then plugins, then target.

Founders sometimes ask whether to skip the work and let the app sit. You can, for a while. Apps that fall behind on target level lose the ability to publish updates, and in time can become hidden from new users on newer devices. Both outcomes cost more than the upgrade. A stale Android build is also a security problem, since the OS closes holes that old targets keep open. Our guide to mobile app security best practices covers why.

The upgrade is routine work with a deadline you can see coming. Do the half-day audit this week, get a number, and put the work in the next sprint. If you want help sizing it or running it, book a free strategy call and bring your manifest and your Play Console target API page.