Develop Reference

SDK Version Specifications in Eclipse

I am an experienced Android developer using Eclipse, but one thing still mystifies me. Namely SDK version specifications. In particular, I find several places where SDK versions are specified:
Project Properties: Android: Project Build Target
Manifest: minSdkVersion
Manifest: targetSdkVersion
Manifest: maxSdkVersion
Below are my guesses about usage (probably wrong):
Project Properties: Project Build Type
Ok, seems fairly straightforward. I believe this specifies the API "library" to use.
Manifest: minSdkVersion
My guess is that this is the minimum level (as specified above) for checking methods used. Ok, but seems redundant. Wouldn't the compiler just bark at me if I used an unsupported method?
Manifest: targetSdkVersion
Can't figure this one out. If I call only supported methods, what additionally does this setting do?
Manifest: maxSdkVersion
Even more mysterious. Why would you ever want to limit the max version? Aren't they backward compatible?
The official doc is rather sparse on the functionality of these settings. Can anybody give me some insight?

Android: Project Build Target
When you select a project build target version it means you are apk or classes will be compiled according to selected SDK. for ex - if you select project build target 16 and try to use annotation #JavaScriptInterface it will not find because this annotation is available in above that target.
Manifest: minSdkVersion
If you define minimum SDK version, an Android users who are using below the specified minimum SDK version can't use your app.
For more info from google Docs:
An integer designating the minimum API Level required for the
application to run. 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. You should always declare this
attribute.
Manifest: targetSdkVersion
The targetSdkVersion has nothing to do with how your app is compiled or what APIs you can utilize. The targetSdkVersion is supposed to indicate that you have tested your app on (presumably up to and including) the version you specify. This is more like a certification or sign off you are giving the Android OS as a hint to how it should handle your app in terms of OS features.
For example, as the documentation states:
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...
The Android OS, at runtime, may change how your app is stylized or otherwise executed in the context of the OS based on this value. There are a few other known examples that are influenced by this value and that list is likely to only increase over time.
For all practical purposes, most apps are going to want to set targetSdkVersion to the latest released version of the API. This will ensure your app looks as good as possible on the most recent Android devices. If you do not specify the targetSdkVersion, it defaults to the minSdkVersion.
Manifest: maxSdkVersion
If you define maxSdkVersion users who are using an android phone running SDK version more than what you defined in maxSdkVersion can't use your app.
For more info from google Docs:
An application declaring maxSdkVersion="5" in its manifest is
published on Google Play. A user whose device is running Android 1.6
(API Level 4) downloads and installs the app. After a few weeks, the
user receives an over-the-air system update to Android 2.0 (API Level
5). After the update is installed, the system checks the application's
maxSdkVersion and successfully re-validates it. The application
functions as normal. However, sometime later, the device receives
another system update, this time to Android 2.0.1 (API Level 6). After
the update, the system can no longer re-validate the application
because the system's own API Level (6) is now higher than the maximum
supported by the application (5). The system prevents the application
from being visible to the user, in effect removing it from the device.

Project Properties: Project Build Type - Yes this will pick up the android.jar and also the build tools version.
Manifest: minSdkVersion - This is not just for the compilation purpose but also used by google play to filter the application.
Secondly, if you have any functionality which is not available below a certain version but required by your application.
Manifest: targetSdkVersion - 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).
Manifest: maxSdkVersion - not recommended. This will restrict your app onto any version higher that the specified maxSdkVersion.
In Android 1.5, 1.6, 2.0, and 2.0.1, the system checks the value of this attribute when installing an application and when re-validating the application after a system update.
However, future versions of Android (beyond Android 2.0.1) will no longer check or enforce the maxSdkVersion attribute during installation or re-validation
There is no need to set the attribute as means of blocking deployment of your application onto new versions of the Android platform as they are released. By design, new versions of the platform are fully backward-compatible. Your application should work properly on new versions, provided it uses only standard APIs and follows development best practices. Second, note that in some cases, declaring the attribute can result in your application being removed from users' devices after a system update to a higher API Level. Most devices on which your application is likely to be installed will receive periodic system updates over the air, so you should consider their effect on your application before setting this attribute.
https://developer.android.com/guide/topics/manifest/uses-sdk-element.html covers it all

Android: If I choose minSdkVersion=4 and targetSdkVersion="19" then in which sdk version my android app will be developed?

If I choose minSdkVersion=4 and targetSdkVersion="19" then in which sdk version my android app will be developed?
As if my application is supporting minSDK version=4 then how come it will have feature of SdkVersion=19?
So I'm confused about on which version of sdk my android application will be made if I choose minSdkVersion=4 and targetSdkVersion="19", if it supports all the features starting from version 4 to 19, then how it's doing as in version 4 we don't have features of version 9.
Thanks.

<uses-sdk android:minSdkVersion="integer"
android:targetSdkVersion="integer"
android:maxSdkVersion="integer" />
contained in:
<manifest>
description:
Lets you express an application's compatibility with one or more versions of the Android platform, by means of an API Level integer. The API Level expressed by an application will be compared to the API Level of a given Android system, which may vary among different Android devices.
Despite its name, this element is used to specify the API Level, not the version number of the SDK (software development kit) or Android platform. The API Level is always a single integer. You cannot derive the API Level from its associated Android version number (for example, it is not the same as the major version or the sum of the major and minor versions).
Also read the document about Versioning Your Applications.
attributes:
android:minSdkVersion
An integer designating the minimum API Level required for the application to run. 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. You should always declare this attribute.
Caution: If you do not declare this attribute, the system assumes a default value of "1", which indicates that your application is compatible with all versions of Android. If your application is not compatible with all versions (for instance, it uses APIs introduced in API Level 3) and you have not declared the proper minSdkVersion, then when installed on a system with an API Level less than 3, the application will crash during runtime when attempting to access the unavailable APIs. For this reason, be certain to declare the appropriate API Level in the minSdkVersion attribute.
android:targetSdkVersion
An integer designating the API Level that the application targets. If not set, the default value equals that given to minSdkVersion.
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).
There are many compatibility behaviors that the system may enable based on the value you set for this attribute. Several of these behaviors are described by the corresponding platform versions in the Build.VERSION_CODES reference.
To maintain your application along with each Android release, you should increase the value of this attribute to match the latest API level, then thoroughly test your application on the corresponding platform version.
Introduced in: API Level 4
android:maxSdkVersion
An integer designating the maximum API Level on which the application is designed to run.
In Android 1.5, 1.6, 2.0, and 2.0.1, the system checks the value of this attribute when installing an application and when re-validating the application after a system update. In either case, if the application's maxSdkVersion attribute is lower than the API Level used by the system itself, then the system will not allow the application to be installed. In the case of re-validation after system update, this effectively removes your application from the device.
To illustrate how this attribute can affect your application after system updates, consider the following example:
An application declaring maxSdkVersion="5" in its manifest is published on Google Play. A user whose device is running Android 1.6 (API Level 4) downloads and installs the app. After a few weeks, the user receives an over-the-air system update to Android 2.0 (API Level 5). After the update is installed, the system checks the application's maxSdkVersion and successfully re-validates it. The application functions as normal. However, some time later, the device receives another system update, this time to Android 2.0.1 (API Level 6). After the update, the system can no longer re-validate the application because the system's own API Level (6) is now higher than the maximum supported by the application (5). The system prevents the application from being visible to the user, in effect removing it from the device.
Warning: Declaring this attribute is not recommended. First, there is no need to set the attribute as means of blocking deployment of your application onto new versions of the Android platform as they are released. By design, new versions of the platform are fully backward-compatible. Your application should work properly on new versions, provided it uses only standard APIs and follows development best practices. Second, note that in some cases, declaring the attribute can result in your application being removed from users' devices after a system update to a higher API Level. Most devices on which your application is likely to be installed will receive periodic system updates over the air, so you should consider their effect on your application before setting this attribute.
Introduced in: API Level 4
Future versions of Android (beyond Android 2.0.1) will no longer check or enforce the maxSdkVersion attribute during installation or re-validation. Google Play will continue to use the attribute as a filter, however, when presenting users with applications available for download.

Firstly, you need to know what these mean.
minSdkVersion signifies the minimum SDK version (which in turn, refers to the version of Android) that your app needs to support it.
targetSdkVersion signifies the optimal SDK version (the version of Android you actually meant the app for) that your app runs on.
However, there's a third setting you missed out on.
compileSdkVersion is the thing that you are looking for. When you set compileSdkVersion to a value (that's between the minSdkVersion and targetSdkVersion) that points to a valid SDK, your app will compile with that SDK as the preferred SDK.
Check out any project's sample build.gradle file to understand how this works. I've linked one below:
https://github.com/googlesamples/android-UniversalMusicPlayer/blob/master/mobile/build.gradle

My config.xml has minSdkVersion as 16 but cordova build targets targetting android-23. Will it still work on a lower SDK android?

I have <preference name="android-minSdkVersion" value="16" /> in config.xml but when it builds it says it’s targeting android-23 and that i need to install that SDK. If I do what cordova build wants, will it still work on android with SDK 16?

Yes,it will work on 16 & above.
android:minSdkVersion
An integer designating the minimum API Level required for the application to run. 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. You should always declare this attribute.
android:targetSdkVersion
An integer designating the API Level that the application is targetting.
With this attribute set, the application says that it is able to run on older versions (down to minSdkVersion), but was explicitly tested to work with the version specified here.
Specifying this target version allows the platform to disable compatibility settings that are not required for the target version (which may otherwise be turned on in order to maintain forward-compatibility) or enable newer features that are not available to older applications.
This does not mean that you can program different features for different versions of the platform—it simply informs the platform that you have tested against the target version and the platform should not perform any extra work to maintain forward-compatibility with the target version.

yes it works on android with minimum version as specified in preferences.

I want update the Application on playstore with changed targetSdkVersion

I have already updated an app to playstore with below-mentioned uses-SDK:
<uses-sdk
android:maxSdkVersion="23"
android:minSdkVersion="17"
android:targetSdkVersion="23"/>
I want to downgrade my targetSdkVersion "23" to "22". I've done it. if I upload to playstore, will the update work for all the users properly?

You won't have any problem at all. What you are saying with your <uses-sdk> is that your app is fully tested to run in version 22 and can even run in lower versions until 17.
I suggest you to take a look to this documentation ver carefully.
android:targetSdkVersion
An integer designating the API Level that the application targets. If
not set, the default value equals that given to minSdkVersion. 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).
There are many compatibility behaviors that the system may enable
based on the value you set for this attribute. Several of these
behaviors are described by the corresponding platform versions in the
Build.VERSION_CODES reference.
To maintain your application along with each Android release, you
should increase the value of this attribute to match the latest API
level, then thoroughly test your application on the corresponding
platform version.

NO. You'll not be able to update your app by changing target SDK from
23 to 22.
PROBLEM
Users that have the APK with version code 6, which targets SDK 23 or higher, will receive an error when they attempt to upgrade to this APK because it targets SDK 22.
Now, as you all know, when we keep target SDK to <23, while installing the app by default all the permissions are granted for the app and if we keep target SDK 23 or higher, all the permissions are set to OFF while installing the app.
RESOLUTION
Ensure that your release including APKs targeting SDK 23 or higher to which all users that have the APK with version code 6 can upgrade.

If you didn't change the code(except the gradle file) and the app still works on the '23' version emulator then there shouldn't be any problem.
It really depends on which features(classes and methods) you used in your code.
If you didn't use any of Android 6's features in your code, then there shouldn't be any problem downgrading the target sdk version without having any change for android 6 users.

Is it run on android version 4.2.2 when I set target API 8 and minimum sdk API 8

Is it possible to run on jelly bean Android device when i set the target API -8 and minimum sdk api-8 in eclipse to make any project without any issue. If create any issue then what we have to do to resolve this.

When you set the target API to API-8 that means that your application is optimised to run on smartphone using API8, but still can run from minimum sdk to the last one out (or to the maximum set).
Android 4.2.2 relies on API level 17, so it should run without a problem.
See
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).
http://developer.android.com/guide/topics/manifest/uses-sdk-element.html#ApiLevels

This is possible as long as you do not set the maximum API. Though certain methods and constants may not be accessible or they are deprecated which may cause runtime errors once loaded onto the 4.2.2 device. One example is in < 4.2.2, AIRPLANE_MODE is under Settings.System.AIRPLANE_MODE_ON, as of 4.2.2 it is located in Settings.Global.AIRPLANE_MODE_ON therefore you no longer can change the airplane mode in your code.