What should I set for compileSdkVersion, minSdkVersion, and targetSdkVersion?

Question

I am concerned about what should I set the compileSdkVersion, minSdkVersion, and targetSdkVersion to be.

1. My concern

Answer 1

Your CompileSDKVersion and your TargetSDKVersion should be the same:

android {
compileSdkVersion 24
buildToolsVersion "24.0.2"

defaultConfig {
    applicationId "com.judeochalifu.dribsndrabs"
    minSdkVersion 15
    targetSdkVersion 24
    versionCode 1
    versionName "1.0"
}

If you are confused on which version number to use, go to Android SDK Manager, locate the API level you are using (Which must always be the latest) and there you will find the version to use (Android 7 (API 24) as at time of writing).

As for the minSDKVersion, the best place to check which to use is to go to the Create New Project window (Android Studio here), Google will help you choose the best one to use at that moment:

Answer 2

minSdkVersion: This is the minimum API level your application need to run the app (i.e. if you set it at API level 16 (Jelly Bean) then your app can't run on API level 15 (IceCreamSandwitch)). In fact Google Play will not show your app on the phone running on API level lower than your minSdkVersion API level. Using API level 15 (IceCreamSandwitch) covers more than 90% of Android phone.

targetSdkVersion: API level for which you design your app to run. Recommendation is to use the latest version (at present 26 - O)

compileSdkVersion: API level you want to compile your app (if you use features of API level of 26 then you need to use 26, lower version will give you error). Android supports backward compatibility (i.e. app compiled on 23 can also run on phone having API level 22 or lower). So answer to your first question is YES. Recommendation is to use the latest version (at present 26 - O)

Answer 3

I set the compileSdkVersion to be 23 which is the latest right now, will older device be able to run it?

Yes. compileSdkVersion on its own has nothing to do with what devices can and cannot run your app. Usually, you set this to be the latest version of the Android SDK.

How do I exactly know what should my minSdkVersion be in order to make sure that phone running lower api or version be unable to access it?

Frequently, the development tools will warn you on the fly when you try using something that is newer than your minSdkVersion. You can run a full Lint check to reconfirm periodically.

How should I set my targetSdk?

In the absence of any particular reason to choose something else, I usually pick the latest or next-to-latest value at the time I create my project (e.g., 22 or 23 now). targetSdkVersion helps with backwards compatibility, and usually my description is "it's the version of Android that you were thinking of at the time you were writing the code".

Answer 4

Google just posted a detailed article about these. In short:

compileSdkVersion is your way to tell Gradle what version of the Android SDK to compile your app with. Using the new Android SDK is a requirement to use any of the new APIs added in that level. It should be emphasized that changing your compileSdkVersion does not change runtime behavior. While new compiler warnings/errors may be present when changing your compileSdkVersion, your compileSdkVersion is not included in your APK: it is purely used at compile time.

If compileSdkVersion sets the newest APIs available to you, minSdkVersion is the lower bound for your app. The minSdkVersion is one of the signals the Google Play Store uses to determine which of a user’s devices an app can be installed on. It also plays an important role during development: by default lint runs against your project, warning you when you use any APIs above your minSdkVersion, helping you avoid the runtime issue of attempting to call an API that doesn’t exist. Checking the system version at runtime is a common technique when using APIs only on newer platform versions.

The most interesting of the three, however, is targetSdkVersion. targetSdkVersion is the main way Android provides forward compatibility by not applying behavior changes unless the targetSdkVersion is updated. This allows you to use new APIs (as you did update your compileSdkVersion right?) prior to working through the behavior changes.