An SDK upgrade most often forces compileSdk upward, sometimes minSdk, and rarely targetSdk. They mean different things: compileSdk is what you compile against, minSdk is the oldest Android you run on, and targetSdk says which platform behaviours you have tested.
What each setting means
According to the Android developer documentation:
- compileSdk names the Android SDK version used to compile your Kotlin or Java source. Each version of Android supports a specific JDK version and a subset of Java APIs, so this also limits which symbols are available in your code.
- minSdkVersion is the lowest API level your app supports. Code that uses newer APIs must be guarded with a version check.
- targetSdkVersion tells the system you have tested against that API level. If it is lower than the running platform, the system can enable compatibility behaviours so your app keeps working as it did. Setting it to match the platform turns those behaviours off.
What a library upgrade can push
| Setting | Can an SDK upgrade force it? | Typical cause |
|---|---|---|
| compileSdk | Often | Library was compiled against a newer API level and the build checks metadata |
| minSdk | Sometimes | Library dropped older Android versions, manifest merge fails |
| targetSdk | Rarely | Mostly your decision, driven by store policy and behaviour changes |
The reason compileSdk moves most is simple. Raising it is cheap, because it changes what you compile against, not how the app behaves on a device. That makes it the easy change to say yes to, so check what else came with it.
A minSdk bump is bigger. It removes devices from your supported set. Weigh it against your install base before accepting.
targetSdk is where behaviour changes. Moving it means the platform stops applying older compatibility behaviours to your app, so permissions, background work and networking rules may change. Treat it as a project, not a side effect. For the store side, see what target API level Google Play requires in 2026.
Steps before merging
- Read the SDK release notes for new minSdk and compileSdk requirements.
- Build once and read the manifest merge report. A conflict on minSdk fails the build and tells you which library asked.
- Compare the merged manifest with the previous release, looking for new permissions, services and receivers.
- If compileSdk rose, check the deprecation warnings in your own code, because newer platform versions can mark more APIs deprecated.
- Leave targetSdk alone unless you have scheduled the behaviour testing.
Why this belongs in a deprecation plan
A library that raises its minimum is signalling that it no longer supports the older Android versions. If your users are still there, you either hold the old release, which stops getting fixes, or raise your own floor. Write that decision down with a date, so the hold does not become permanent.
Where Safeguard fits
Safeguard's dependency scanning and SBOM output show which library versions are in a build, which helps when you need to trace a manifest or version change to a specific SDK. A free scan is at gold.safeguard.sh/scan.
Quick check
Does raising compileSdk change how my app behaves?
Not by itself. It changes what you compile against. targetSdk is the setting that changes runtime behaviour.
Why did my build fail on minSdk after an upgrade?
A library you added declares a higher minSdk than your app. The manifest merge report names it.
Sources
- Android Developers, Configure Java versions (compileSdk): https://developer.android.com/build/jdks
- Android Developers, uses-sdk element: https://developer.android.com/guide/topics/manifest/uses-sdk-element
- Android Developers, Version your app: https://developer.android.com/studio/publish/versioning
Last reviewed: 19 October 2026.
