targetSdkVersion: Audit Behavior Changes Before Raising the Number

Create a before-and-after matrix

Use the same source revision and dependencies where practical, with only the necessary target migration changes. Compare the previous production target and the intended target on representative OS versions.

Keep app data and test accounts controlled. Randomly reinstalling until an error disappears loses the conditions that caused it.

Audit the features your app actually uses

Review the migration notes for each crossed target level. Prioritize background services, alarms, notifications, media selection, edge-to-edge UI, deep links and native-code requirements when they are relevant. Do not add permissions merely because another tutorial includes them.

Third-party SDKs can also be affected. Check their supported target levels and test initialization after consent, during process recreation and on a release build with shrinking enabled.

Verify the final artifact

A correct Gradle file does not prove the uploaded variant uses it. Inspect the merged manifest and final APK or bundle. APKLint's Target SDK Checker can help confirm the declared value; it cannot simulate every target-triggered behavior.

When a crash appears after the change, retain the stack trace, device API, permission state and exact version code. Determine whether the failure is an API behavior change, a simultaneously upgraded library, or a pre-existing race exposed by new timing.

Release with an observable exit condition

Define which startup, crash, ANR and core-flow measurements will halt expansion. A target-compliant build can still be unreliable. Conversely, a passing smoke test cannot exempt an outdated target from Play's submission rules.

Use Android's build configuration, the relevant platform behavior-change documentation, and the dated Play target requirement together. Record the migration target explicitly rather than writing “supports the latest Android” without evidence.