Google Play requires all new apps and updates to target API level 36 (Android 16) by 31 August 2026, with only narrow exceptions for platforms like Wear OS and Android TV. Missing the deadline means updates get rejected outright, which forces most teams to retarget on a schedule set by Google rather than by their own release calendar. That’s the easy part to plan for. The harder part is that Android 16 changes real runtime behaviour — predictive back gestures, permission timing, background execution limits — and a retargeted build can pass every manual test while quietly shipping a crash or ANR regression that only shows up at scale, days after the forced rollout is already complete.
Teams that treat this purely as a compliance checkbox — bump the number, resubmit, move on — lose the one advantage they actually have: the ability to compare the retargeted build against the previous one before the whole install base is on it. Without that comparison, a spike in crash-free rate or a jump in ANRs looks like a mystery regression weeks later, disconnected from the SDK bump that actually caused it, and far harder to trace back and fix.
Data Points to Track
- Target API level per released build, tracked against the 31 August 2026 deadline so retargeting isn’t left to the last viable release window
- Crash rate segmented by target SDK version, comparing the Android 16-targeted build against the prior target as both cohorts exist side by side during rollout
- ANR rate segmented by target SDK version, since background execution and main-thread timing changes in Android 16 are a common source of new ANRs specifically
- Permission dialog outcomes tied to any Android 16 behavioural change the app touches, since new runtime permission flows can shift grant and denial rates independent of any UX change on the app’s side
- Play Console rollout percentage and rejection or warning events, so target-API compliance status is visible alongside the technical rollout, not just checked once at submission
Setup Steps
- Confirm the current targetSdkVersion in build config and schedule the retarget to 36 with enough runway before 31 August 2026 to leave room for a staged rollout, not a last-minute forced push.
- Tag crash and ANR reporting with target SDK version as a first-class dimension, separate from OS version, so a regression can be attributed to the retarget specifically.
- Add an event around any permission dialog affected by Android 16 changes, logging outcome and timing, to catch grant-rate shifts that aren’t visible in crash data.
- Stage the retargeted build behind a percentage rollout in Play Console and hold it there until crash and ANR rates are confirmed stable against the previous target before expanding.
- Set an alert threshold on the crash/ANR delta between target SDK cohorts, so a regression surfaces automatically rather than waiting for a support ticket or a bad review.
Actionable Insights
If crash or ANR rates climb specifically on the Android 16-targeted cohort, treat it as a retarget-caused regression until proven otherwise — predictive back handling and background execution limits are the most common culprits, and both are fixable before the deadline forces a full rollout regardless. If permission grant rates drop after retargeting, check whether a new Android 16 dialog is firing at a worse moment in the user journey than the old one did — that’s a UX fix, not a tracking problem. And if the staged rollout shows no meaningful delta between cohorts, that’s the signal to move faster: expand rollout ahead of the deadline instead of holding at a conservative percentage out of caution the data doesn’t support.
Related Resources
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