Guide · Gradle

minSdk vs targetSdk vs compileSdk, explained

These three settings sit a few lines apart in your module's build.gradle, they all take an API level, and they are constantly confused for one another. They answer three completely different questions. Here is the short version, then the detail.

android {
    compileSdk = 36

    defaultConfig {
        minSdk = 24
        targetSdk = 36
    }
}

compileSdk — what you build against

compileSdk is the version of the Android SDK the compiler uses. It decides which APIs your code can even see and call. If you want to reference an API introduced in Android 16, your compileSdk must be at least 36. It has no direct effect on which devices can run the app, and it is never shipped inside the APK — it is purely a build-time setting. The practical rule: keep compileSdk on the latest stable API so you can use current APIs and get up-to-date lint checks. It should be greater than or equal to targetSdk.

targetSdk — the behaviors you opted into

targetSdk tells the system, "I have tested my app against the behavior changes up to this API level." Android uses it for backward compatibility: when your app runs on a device newer than your targetSdk, the OS may keep older behaviors so nothing breaks. When you raise targetSdk, you take on the behavior changes of every version up to it — new permission models, background limits, and so on — which is why bumping it needs testing, not just a number change.

targetSdk is also the value Google Play enforces. Play requires apps to target a recent API level to be published or updated, on an annual schedule tied to the latest major release. Because the exact required level and deadline move each year, check the current Google Play target API level requirement before a release rather than trusting a fixed number.

minSdk — the floor for installation

minSdk is the lowest API level a device can have and still install your app. Set it too low and you support ancient devices at the cost of extra compatibility work and larger code; set it too high and you exclude real users. This is a reach-versus-effort decision: check the current device version distribution for your audience, then pick the lowest level that still covers a worthwhile share without dragging down maintenance. Many teams today sit somewhere around API 24–26, but the right floor depends on your market.

How they relate

• minSdk ≤ targetSdk ≤ compileSdk — this ordering should always hold.
• compileSdk and targetSdk are usually the same on an up-to-date app; minSdk sits lower.
• Calling an API above minSdk is fine — just guard it with a version check (Build.VERSION.SDK_INT) or an annotation so older devices don't crash.