Develop Reference

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

Firemonkey: can we update targetSdkVersion in AndroidManifest.template.xml?

I read that berlin is compatible with marshmallow, but i see that by default in the AndroidManifest.template.xml we have :
<uses-sdk android:minSdkVersion="%minSdkVersion%" android:targetSdkVersion="%targetSdkVersion%" />
i don't know where delphi took the variable to update %targetSdkVersion% but it's seam to be all the time 14 and i don't see any way to configure it
i would like to replace %targetSdkVersion% by 23 (marshmallow api level, to support the app permissions), but is it safe to do so or it's will introduce many other bug ?

FireMonkey was developed to work against a certain range of Android functionality. As you can see from the RAD Studio Platform Status page FireMonkey apps built with Delphi 10.1 Berlin have a lowest supported Android version of 4.0.3, which corresponds to Android API Level 15.
The minSdkVersion field is supposed to be set to the earliest Android version your apps will work with so in truth this should probably be set to 15 but actually is set to 14 (Android 4.0-4.0.2).
If you look back at an Android manifest file generated by Delphi XE7, which supported Android 2.3.3 (API Level 10) it specifies a min SDK version of 9 (Android 2.3-2.3.2), which is the version of Android that introduced the NativeActivity type underlying every Delphi FireMonkey Android app. Again, this seems a little bit out of kilter with what is documented as lowest supported version.
Anyway, minSdkVersion can be used by Google Play store to filter your app out of the listings for someone running a lower version of Android. It is also checked when you install an app on a device; Android won't let you install on a lower version of Android.
targetSdkVersion, on the other hand, indicates what version of Android your app has been tested with and works sensibly with. It can often be higher than minSdkVersion if your your app needs to use features introduced in Android versions later than minSdkVersion.
If you want to use a feature from API Level 23 then sure, you'll need to update that manifest part. Just remove the %targetSdkVersion% template from the Android manifest template file and replace it with the required version.
Problems that you might run into:
You'll either need to check the Android version and, if lower than your targetSdkVersion, not use those features that aren't available or set minSdkVersion to a suitably higher version to ensure the app can only run on devices that have the features you wish to use.
FireMonkey code not aware of differing behaviour in API Levels may
function adversely. In your case you may get issues because of the
different runtime permissions behaviour enabled in API Level 23.
Actually I can't currently think of any more issues, though a good amount of testing is recommended. You might have more to think about in a regular Android app using visual activities and so on, when different API levels may affect the theming or other UI elements. You can see the various things that change when you target target SDK versions on this Android documentation page.
By the way, the use of the SDK Manager in the Tools. Options... dialog is entirely irrelevant to the question of how to update the value in the generated manifest file. The only evident way to change it is to manually edit the Android manifest template file as per the documentation, and mentioned in a comment.
The only relevance of the SDK Manager is that the default Android SDK installation for Delphi 10.1 Berlin installs the Platform libraries for API Level 22. If you want to use a feature from API Level 23 you might think that updating those platform libraries might be necessary, but of course if you're doing the coding in Delphi then you're (presumably) actually just compiling against import definitions of the features in that higher API level, and so whether or not those features are contained in the android.jar file is of no consequence.**
** I'm happy to be proved wrong on this count, but I have never observed a connection between the manifest and what the SDK Manager is set up against.

Will my application be visible to devices higher than my targetSdkVersion in Google Play Store?

I have gone through the following links but they don't provide a clear and definitive answer to my question. This is what I could derive from the answers:
targetSdkVersion indicates that the app is tested against the target version and will run on all android versions from minSdkVersion to targetSdkVersion
with no compatibility issues.
Android Min SDK Version vs. Target SDK Version
what is the difference between "min sdk , target sdk and compile with " ? in android
My app's minSdkVersion=11 and targetSdkVersion=19, Now I am not sure whether devices with higher SDK versions will see my app on Google Play Store or not.
UPDATE: For those who may encounter this question here is a great article I found:
http://www.thedroidsonroids.com/blog/android/compile-min-max-and-target-sdk-versions/

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).
Android Developer, So the answer is yes, but you might want to consider testing and updating to current SDK version.

Yes, devices with higher SDK versions will see your app. Features of newer SDKs like granular permissions in Android 6.0 will not be available if they are not supported in your code.
The documentation for android:maxSdkVersion makes the situation clearer:
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.

It works on SDK 11 and upwards, as in your first Link stated.

Yes. Your app will be visible to the devices with higher sdk versions than your targetSdkVersion.
By specifying targetSdkVersion you can restrict google by applying default compatibility behaviours.So that you will get along with the api level of the device in which your app is running.

Yes, newer devices will see it. Let's do a thought experiment. Let's go back in time one year. We build an app, setting the minSDKVersion and targetSdkVersion to X, the highest available number in the toolset. Six months ago, X+1 got released. And today I just bought a new phone that runs X+1, and I'm very excited! Wait, what? That brand new app isn't in the store? But it worked on my old phone!
That would be crazy. :)
As a more concrete example, here's an app that has minSdkVersion 15
targetSdkVersion 17: https://play.google.com/store/apps/details?id=com.nasarallysport.rallyracetimer I just verified that I can see it in google play with my Nexus 6 on api 23.

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.

Android : Consequences of having targetSDK > BuildTarget

I wanted to know the consequences of having targetSDK > buildTarget.
I recently observed that if I keep the buildTarget=16 and targetSDK=17 the tabs on my tablet (running 4.1.1, API Level 16) moves to the center of the actionBar. I was unable to rationalize the behavior. Can somebody shed some light on why this happened?

Nice question! I had a similar behavior some time ago, when buildTarget and targetSDK differed in the described way. It took me some time, to figure it out, but I will try to summarize my understanding.
You have to distinguish between three important values:
minSdkVersion:
This is the lowest available version, on which the app will (or should!) run. When installing an .apk onto Android, the value will be checked and if the Android version you're running on, is lower than the specified version, it won't install.
buildTarget:
That's the SDK on which the application's .apk will be compiled (and Eclipse will be target that value too, for checking for compilation errors). If the buildTarget is higher than the minSdkVersion, you will be able to install the app even if your Android version does not support all methods. By default, this is set to the latest version of Android available in your SDK. You can still build your app to support older versions, but setting the build target to the latest version allows you to enable new features and optimize your app for a great user experience on the latest devices.
You need to check if the methods you are using are present at runtime if running on a lower API level, otherwise the application might crash!
targetSdkVersion:
The targetSdkVersion specifies on which SDK platform your app should run fine. So, if you tested against API 17, you can add API 17 as targetSdkVersion. If using an Android version > targetSdkVersion, the Android system will enter into some kind of forward-compatibility mode to ensure support for the application. This compatibility behavior will be entered to ensure that your app continues to work the way you expect, as there might be some changes in behavior between never API levels (here are some of the most important changes). So, any application developed for a lower API level will be able to run on a higher version, as the old behavior (like obsolete values) might be "simulated" within the compatibility mode.
For example:
If you set targetSdkVersion to HONEYCOMB (API 11), the default theme will be changed to Theme_Holo (that's the dark holographic UI). Setting targetSdkVersion to a lower value will affect the system to stay on the default light theme, regardless which build API you will use!
In your case, there don't seem to be many noticeable changes between API 16 and 17, that should affect in a design change, but I guess, the higher targetSdkVersion will affect in some additional changes at compile time (like including additional classes, themes, values, ...), that will affect in a different behavior, just like in the theme example above.
I hope, that helped you a bit, to figure out the weird behavior. Here is some more related information to read in the Android Developer documentation.
PS: There is some kind of forward-backward-hell: The Android system is backward-compatible, so that the forward compatibility of Android applications is ensured. That means: If you update your Android version via OTA e.g., all old applications should stay running (so they will stay forward compatible).

The build target is for app development, the target SDK is for app compatibility.
The build target specifies which API you have access to while implementing the app. Like if you set the build taget to android API level 10 then as far as your code is concerned, there is no such thing as an ActionBar. The API you use during development is just a stub implementation of Android, this is way it has to be emulated or run on a real device. Therefore, the build target defines (to the compiler and your IDE) Android interface you are using. Once compiled, there should be no difference based on build target (the Android system doesn't see the build target, it's a compile-time flag). This is a strict contract between you and the android compiler (and your IDE) that defines which components in Android you are able to use in your application, as you will get compilation errors if you try to use something that is beyond the Android version set as your build target.
The target SDK is a contract you sign with the Android system, assuring it that your app is prepared to work properly from you minimum SDK up through to the target SDK (effective the maximum SDK, as the maximum SDK setting should generally be avoided). I believe there are a few things that don't get forward-compatibility, like some of the security changes (probably changes the come from beyond app development and are system-wide). This contract is an agreement that means you have performed measures to make sure that your app handles any changes in the Android API in that range, such that it provides behavior you expect in all situations. The other end of the contract is from the Android system, it agrees to use Android implementation that does not exceed your target SDK, even when on a device running a higher version of Android (this excludes the few changes that I mentioned previously).
The note on forward-compatibility implies that your build target should always at least match your target SDK. You are saying that you have tested your app to run at your target SDK, so why build it against a lower API level?
Real life example of build target and target SDK in action:
ActionBarSherlock provides backward-compatible ActionBar. Here are quotes from requirements to use the library at this time.
The library itself must be built against Android 4.0 (API level 14). Your project should be built using the latest version of the SDK as possible as long as it is 4.0 or newer.
Targetting API level 11 or newer is required as it will cause Android to automatically add the native action bar when run on newer devices. Since you will be compiling against new APIs but your app will likely be run on devices with older versions of Android extra care must be taken to either avoid using or properly check and call any methods that were introduced after your minimum SDK version.
The first paragraph shows that a build target that contains the 4.0 ActionBar API is required, as the library makes use of it and can't compile without it. The second paragraph shows that a target SDK that contains the 3.0 ActionBar API is required as the library uses the native ActionBar on such devices, but the Android system won't provide the ActionBar if your target SDK is lower than 3.0 since that tells it not to use anything newer than your target (like the 3.0 ActionBar).
Some references:
Build Target
Target SDK