What is the difference between "min SDK version", "target SDK version" and "compile SDK" version?
Asked Answered
M

7

355

What are the differences between "min sdk version", "target sdk version" and "compile sdk version"? I know what "min sdk version" and "target sdk version" means but what does "compile sdk version" mean?

In Eclipse, I have "min sdk version" and "target sdk version" set but in Android Studio there is also "compile sdk version".

Modred answered 1/7, 2014 at 12:23 Comment(2)
I am currently working on an app where i used targetsdkversion as 12 and all my layouts very working abnormally then i changes it back to 23 and it works like a charm so i think targetsdk version must be always same as compiled versionAconite
Related post - What is the difference between compileSdkVersion and targetSdkVersion?Extravasate
E
346

The min sdk version is the earliest release of the Android SDK that your application can run on. Usually this is because of a problem with the earlier APIs, lacking functionality, or some other behavioural issue.

The target sdk version is the version your application was targeted to run on. Ideally, this is because of some sort of optimal run conditions. If you were to "make your app for version 19", this is where that would be specified. It may run on earlier or later releases, but this is what you were aiming for. This is mostly to indicate how current your application is for use in the marketplace, etc.

The compile sdk version is the version of android your IDE (or other means of compiling I suppose) uses to make your app when you publish a .apk file. This is useful for testing your application as it is a common need to compile your app as you develop it. As this will be the version to compile to an APK, it will naturally be the version of your release. Likewise, it is advisable to have this match your target sdk version.

Euton answered 23/12, 2014 at 22:51 Comment(7)
My compile sdk version and target sdk version are the same. That is 21. My App crashes when I run it on devices with lower API level. I'm new to Android, how should I proceed now?Oat
@Oat If your app crashes on versions lower than 21, you should probably set your min SDK version to 21. This will not actually fix your application on targets lower than 21, it will just note that your app is unsupported on lower versions. You also have the option of determining what exactly is breaking your application (what changed in version 21,) and add support to take care of that dependency, but I suspect that will be a lot of work and not within the scope of an Android beginner project.Euton
What happens if I set my minSdkVersion =14; targetSdkVersion=23; and compile SDK to 19?Pouf
@Pouf your question is irrelevant because you should think a little bit that if you target to run on version 23 then how is it possible to compile it with 19! Please follow the formula minSdkVersion <= targetSdkVersion <= compileSdkVersionSwingeing
@Euton can it happen that when using compileVersion 26 for example, I accidentally use a feature or java API that is not supported on version 21, which is min sdk? sorry, not really getting some fundamental concepts hereKawasaki
I don't understand "The target sdk version is the version your application was targeted to run on". As I never target a specific API level, because I am supposed to and I have to make my app run properly on a range of devices with variety of API levels.Bearish
What does that mean for SDK makers? Is it wise to compile an SDK with the highest possible compile sdk version when we want to allow for a lower min sdk version ? Ex: I am making a closed sourced SDK that I compile with API 34 but want to allow it's integration into an app with min sdk version of 26 or a target sdk version of 33. Would that work ?Ralli
A
266

Android minSdkVersion, targetSdkVersion, compileSdkVersion

The formula is

minSdkVersion <= targetSdkVersion <= compileSdkVersion

minSdkVersion - is a marker that defines a minimum Android version on which the application will be able to install. Also, it is used by Lint to prevent calling API that doesn’t exist. Also, it has an impact on Build Time. So you can use build flavors to override minSdkVersion to the maximum during the development. It will help to make the build faster using all improvements that the Android team provides for us. For example, some features of Java 8 are available only when you are using specific versions of minSdkVersion.

targetSdkVersion - If AndroidOS version is >= targetSdkVersion it says Android system to turn on version specific features. *Please note that some of these new behaviors will be turned on by default even if thought targetSdkVersion is <, you should read the official documentation.

For example:

  • Starting in Android 6.0 (API level 23) Runtime Permissions were introduced. If you set targetSdkVersion to 22 or lower your application does not ask a user for some permission in run time.

  • Starting in Android 8.0 (API level 26), all notifications must be assigned to a channel or it will not appear. On devices running Android 7.1 (API level 25) and lower, users can manage notifications on a per-app basis only (effectively each app only has one channel on Android 7.1 and lower).

  • Starting in Android 9 (API level 28), Web-based data directories separated by process. If targetSdkVersion is 28+ and you create several WebView in different processes you will get java.lang.RuntimeException

compileSdkVersion - actually it is the SDK Platform version and tells Gradle which Android SDK uses to compile. When you want to use new features or debug .java files from Android SDK you should take care of compileSdkVersion. One more example is using AndroidX that forces to use compileSdkVersion - level 28. compileSdkVersion is not included in your APK: it is purely used at compile time. Changing your compileSdkVersion does not change runtime behavior. It can generate for example new compiler warnings/errors. Therefore it is strongly recommended that you always compile with the latest SDK. You’ll get all the benefits of new compilation checks on existing code, avoid newly deprecated APIs, and be ready to use new APIs. One more fact is compileSdkVersion >= Support Library version

You can read more about it here. Also, I would recommend you to take a look at the example of migration to Android 8.0.

[buildToolsVersion]

Adverse answered 13/11, 2017 at 16:28 Comment(9)
Best answer here because it actually explains the practical difference between targetSdkVersion and compileSdkVersionVanadous
@Adverse Thanks for your answer. I see many cases targetSdkVersion and compileSdkVersion are same. Why android made two as separate can't one be sufficient to handle or is there any specific reason behind making in to two separate fields?Chun
@Chun you can find more in SO thread #26694608Adverse
@Adverse what you mean 'Android system to turn on specific behavior changes' can you please explain ?Bouffard
@atishr 'specific behavior changes' are listed in 'For example' blockAdverse
I've doubt geofencingapi is showing deprecated but still working in newer versions of android, what it means ? please tell me I'm new to androidBouffard
As I see the 'GeofencingApi' is part of Google Play Services and was deprecated in release 11.0.(marked as @Deprecated). It out of this answer scope. Please look through another SO topicsAdverse
Great answer! I'd only add one more sentence about the compile SdkVersion - you can use Android API features included in that version of the API as well as all previous versions. (Taken from Vinay John's answer below)Caplin
We also have minCompileSdk nowSpring
P
99

The min sdk version is the minimum version of the Android operating system required to run your application.

The target sdk version is the version of Android that your app was created to run on.

The compile sdk version is the the version of Android that the build tools uses to compile and build the application in order to release, run, or debug.

Usually the compile sdk version and the target sdk version are the same.

Preparation answered 23/12, 2014 at 22:15 Comment(1)
And when they are not the same pros/cons?Finley
B
19

compileSdkVersion : The compileSdkVersion is the version of the API the app is compiled against. This means you can use Android API features included in that version of the API (as well as all previous versions, obviously). If you try and use API 16 features but set compileSdkVersion to 15, you will get a compilation error. If you set compileSdkVersion to 16 you can still run the app on a API 15 device.

minSdkVersion : The min sdk version is the minimum version of the Android operating system required to run your application.

targetSdkVersion : The target sdk version is the version your app is targeted to run on.

Broadbrim answered 1/7, 2019 at 17:12 Comment(1)
Cleanest and straight-to-the-point explanation! Thanks!Caplin
M
10

Reference- Medium Article by Paulina Sadowska

  1. compileSdkVersion defines which Android SDK version will be used by Gradle to compile your app.

For example:

In Android 12, so in SDK version 31, there was a new API introduced, that allows us to easily implement a splash screen. In this new API, the splash screen can be customized using those properties:

If you want to use that API in your app you first have to:

i)  download SDK version 31 in Android Studio,
ii) and then: update compileSdkVersion to 31 in your app.

Only then you can see these new properties. And only then you can use this new splash screen API in your code.

2.targetSdkVersion is a property that tells the system for which Android version the app was designed and tested on.

If the user runs your app on a device with an android version that is higher than the targetSdkVersion defined in your app, for new android features, the system may introduce some backward-compatibility behavior to ensure your app still looks and works in a way that you designed it.

For example:

In Android 12 the appearance of custom notifications was changed. Previously they could use the whole notification area, but in Android 12 system applies the standard template to all custom notifications so they look more consistent. If your targetSdkVersion is below 31 system will assume that you haven’t tested that feature and will display notifications in the old way to minimize the risk that notification will not be displayed properly. Only after you update the target SDK version to 31 the new notification appearance will be used.

Marchelle answered 13/8, 2021 at 10:45 Comment(0)
P
7

Lots of good explanations in earlier answers, but none link to the official docs. If curious, see https://developer.android.com/guide/topics/manifest/uses-sdk-element for:

  • minSdkVersion:

The Android system will prevent the user from installing the application if the system's API Level is lower than the value specified in this attribute.

Aside: if you use the NDK to run native code, minSdkVersion also impacts the NDK's API availability. (https://developer.android.com/ndk/guides/sdk-versions)

  • targetSdkVersion:

This attribute informs the system that you have tested against the target version and the system should not enable any compatibility behaviors to maintain your app's forward-compatibility with the target version. The application is still able to run on older versions (down to minSdkVersion).

As Android evolves with each new version, some behaviors and even appearances might change. However, if the API level of the platform is higher than the version declared by your app's targetSdkVersion, the system may enable compatibility behaviors to ensure that your app continues to work the way you expect. You can disable such compatibility behaviors by specifying targetSdkVersion to match the API level of the platform on which it's running. For example, setting this value to "11" or higher allows the system to apply a new default theme (Holo) to your app when running on Android 3.0 or higher and also disables screen compatibility mode when running on larger screens (because support for API level 11 implicitly supports larger screens).

So the assumption is that you developed the app with the target API in mind, and have tested that everything looks/behaves as you expected, esp if you're trying to use features introduced in this API. Furthermore, your code should be able to handle platforms that don't have that new feature (down to your minSdkVersion, e.g. checking your code handles missing APIs that you use gracefully, etc). But even newer Android versions may do things to keep your app running, which might otherwise break or look even funkier if the OS didn't enable "compatibility behaviors".

See https://developer.android.com/studio/build for:

  • compileSdkVersion:

compileSdkVersion specifies the Android API level Gradle should use to compile your app. This means your app can use the API features included in this API level and lower.

Ideally you'd set target & compile versions the same to the highest release, and of course you don't have to use any of the new features. But you may wish to keep your target at an older version you've already released, while using a newer compile version for better warnings/errors, until you're ready to update the target version. In the past it also let one use newer Java language features in their code with an Android Gradle plugin upgrade, independent of the target Android APIs.


Lastly, don't forget about Google's more recent target API level requirements, which basically require you to release a build targeting up-to-date API levels by a certain date if you want to still be available to users on the Play store that use an OS newer than your target API. This is to motivate the app dev community make available newer performance/security enhancements (like giving the user more privacy options when you request location info).

Every version of Android released since 9 lists behavior changes that will impact all apps regardless of your targetSdkVersion (e.g. here's Android 12's), and what changes when you specifically target it (e.g. Behavior changes: Apps targeting Android 12. When the next version is in preview is a good time to start checking your app's compatibility with the upcoming release, even if it's just that any compat modes are ok without changing your compileSdkVersion, if you aren't prepping to target it yet. The Compatibility framework tools can help with that and in the migration to using new APIs.

Preciosity answered 27/5, 2022 at 9:17 Comment(0)
W
0

Here is the little clear and easy way to understand -

minSdkVersion should be lower to target the max coverage of android devices on which the app will be installed.

compileSdkVersion is required while developing the app to use the latest and optimize APIs of android.

tarketSkdVersion is the latest/version of android OS on which you want to run your app to achieve the full optimization of android resources.

Note- please correct me if there is a mistake. thanks

Wanda answered 20/1, 2022 at 14:52 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.