What is the difference between compileSdkVersion and targetSdkVersion?

Question

I have looked at the documentation for building with Gradle, but I\'m still not sure what the difference between compileSdkVersion and targetSdkVersion

Answer 1

The compileSdkVersion should be newest stable version. The targetSdkVersion should be fully tested and less or equal to compileSdkVersion.

Answer 2

My 2 cents: Compile against any version of the SDK but take care not to call any APIs that your "minimum SDK version" does not support. That means you "could" compile against the latest version of the SDK.

As for "target version" it simply refers to what you planned to target in the first place and have possibly tested against. If you haven't done the due diligence then this is the way to inform Android that it needs to perform some additional checks before it deploys your lets say "Lollipop" targeted app on "Oreo".

So the "target version" is obviously not lower than your "minimum SDK version" but it can't be higher than your "compiled version".

Answer 3

I see a lot of differences about compiledSdkVersion in previous answers, so I'll try to clarify a bit here, following android's web page.

A - What Android says

According https://developer.android.com/guide/topics/manifest/uses-sdk-element.html:

Selecting a platform version and API Level When you are developing your application, you will need to choose the platform version against which you will compile the application. In general, you should compile your application against the lowest possible version of the platform that your application can support.

So, this would be the right order according to Android:

compiledSdkVersion = minSdkVersion <= targetSdkVersion

B - What others also say

Some people prefer to always use the highest compiledSkdVersion available. It is because they will rely on code hints to check if they are using newer API features than minSdkVersion, thus either changing the code to not use them or checking the user API version at runtime to conditionally use them with fallbacks for older API versions.

Hints about deprecated uses would also appear in code, letting you know that something is deprecated in newer API levels, so you can react accordingly if you wish.

So, this would be the right order according to others:

minSdkVersion <= targetSdkVersion <= compiledSdkVersion (highest possible)

What to do?

It depends on you and your app.

If you plan to offer different API features according to the API level of the user at runtime, use option B. You'll get hints about the features you use while coding. Just make sure you never use newer API features than minSdkVersion without checking user API level at runtime, otherwise your app will crash. This approach also has the benefit of learning what's new and what's old while coding.

If you already know what's new or old and you are developing a one time app that for sure will never be updated, or you are sure you are not going to offer new API features conditionally, then use option A. You won't get bothered with deprecated hints and you will never be able to use newer API features even if you're tempted to do it.

Answer 4

The Application settings of an Android project's properties in Visual Studio 2017 (15.8.5) has them combined:

Answer 5

compiledSdkVersion==> which version of SDK should compile your code to bytecode(it uses in development environment) point: it's better use last version of SDK.

minSdkVersion==> these item uses for installation of APK(it uses in production environment). For example:

if(client-sdk-version   <   min-sdk-versoin )
    client-can-not-install-apk;
else
    client-can-install-apk;

Answer 6

Quick summary:

For minSDKversion, see latest entry in twitter handle: https://twitter.com/minSdkVersion

TargetSDKversion: see latest entry in twitter handle: https://twitter.com/targtSdkVersion or use the latest API level as indicated at devel https://developer.android.com/guide/topics/manifest/uses-sdk-element.html

Compiled version: make it same as TargetSDKversion

maxSdkVersion: advice from Android is to not set this as you do not want to limit your app to not perform on future android releases