Docs

Google Play Target API Discoverability Tracking

From 31 August 2026, Google Play hides non-compliant apps from users on newer Android — track discoverability loss before install numbers explain it.

Acquisition

Google Play’s target API level policy has a hard deadline this year: from 31 August 2026, existing apps must target Android 15 (API level 35) or higher, and any new submission or update must target Android 16 (API level 36) or higher, to stay visible on the Store. The enforcement mechanism is quieter than a rejection — it isn’t that the app gets pulled outright. Instead, it stops appearing in search and browse results for any user whose device runs an Android OS version newer than the app’s target API level. Existing installs are untouched; the app keeps working for people who already have it. New discovery just silently stops for a growing share of the Android install base as newer OS versions spread.

That distinction matters for anyone reading acquisition numbers without a Play Store discoverability signal in the mix. A slow decline in organic installs from Android devices looks exactly like a demand problem, a keyword ranking drop, or a seasonal dip — the kind of thing a growth team investigates with ASO tweaks and creative refreshes. None of that will move the number if the real cause is that a meaningful and growing slice of the Android install base simply can’t find the app in search anymore. Google does offer a one-time extension to keep distributing to all users until 1 November 2026, but that’s a deadline extension, not a fix, and it’s easy to lose track of exactly which extension state an app is in across a portfolio of several apps or SKUs.

Data Points to Track

  • Target API level per live build, checked against the current Play Store minimum on every release, not just at submission time — the bar moves annually and a build that was compliant in January can fall behind by August
  • Organic install rate segmented by installer’s Android OS version, so a decline concentrated in newer OS cohorts is distinguishable from a genuine falloff in demand across all cohorts
  • Search/browse impression share on Play Console, tracked specifically for devices running an OS version above the app’s current target API level, since that’s the exact population being excluded
  • Extension status and expiry date per app, if a compliance extension has been requested, tracked as a first-class field rather than something buried in Play Console correspondence
  • Existing-user retention versus new-user acquisition, split out explicitly, since a compliant-vs-non-compliant transition affects only the acquisition side and a blended metric will understate how sharp the effect actually is

Setup Steps

  1. Add target API level as a tracked build property in your release pipeline, surfaced on every deploy dashboard alongside version number and build date, not just in the manifest.
  2. Pull Play Console’s OS-version breakdown for organic installs on a recurring basis and build a specific view for “installs from devices above current target API level” so the at-risk population is visible before it starts shrinking.
  3. Set an internal compliance deadline at least one release cycle ahead of Google’s enforcement date, since a rejected or delayed release close to 31 August leaves no buffer to fix and resubmit.
  4. Log extension requests and their expiry dates in the same system you track releases, not as a one-off support ticket, so the runway is visible to whoever owns the acquisition number.
  5. Instrument a discoverability-specific alert that fires if organic install share from newer-OS devices drops sharply in a short window, distinct from your general install-volume alerting, so this specific failure mode gets flagged with the right cause attached.

Actionable Insights

If organic installs are declining specifically among users on OS versions newer than your current target API level, that’s a compliance gap, not a marketing problem — the fix is a target API bump and a new submission, not a bigger acquisition budget. If the decline is flat across all OS-version cohorts, the target API level isn’t the cause and the investigation should stay on demand and ASO as normal. And treat the one-time extension as a countdown, not a resolution: log its expiry alongside your release calendar so the actual compliance fix ships well before the extension itself runs out, rather than discovering the deadline has already passed when discoverability data starts moving.

Expert help

Need help tracking this in your app?

Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.

Talk to an expert