Develop Reference

How to identify potential incompatibilies when increasing Android target SDK

I want to attempt to add a feature (notification channels) which requires target SDK level 26 to an open-source Android project that currently targets SDK level 22.
Looking at the documentation for notification channels, I saw something disturbing: apparently increasing the target level can cause previously valid uses of the API to function differently — in this case, notifications that don’t specify a channel will no longer be displayed. That tells me there could be other things that would break as well just from changing the target level.
How can I find every API call in the project that I need to examine for possible incompatibility when changing from level 22 to level 26? Alternatively, is there a way to isolate sections of code so that the code I’m not changing still uses level 22, and only the new code uses 26?

I want to attempt to add a feature (notification channels) which requires target SDK level 26
If you have targetSdkVersion set to 26 or higher, then notification channels are required. If your targetSdkVersion is set below 26, notification channels are not required, but AFAIK you can still set them up, if you are running on an API Level 26+ device. Personally, I have never tried this; keeping your targetSdkVersion up to date is fairly important in modern Android app development.
How can I find every API call in the project that I need to examine for possible incompatibility when changing from level 22 to level 26?
In general, you can't. You are welcome to read the release notes for Android; in the past couple of releases, Google has been better about specifically calling out the changes that are triggered by targetSdkVersion. You can also read the JavaDocs for the associated Build.VERSION_CODES value (e.g., the JavaDoc for M), as they list changes triggered by targetSdkVersion. The IDE might give you some warnings. Beyond that, it's a matter of testing.
Alternatively, is there a way to isolate sections of code so that the code I’m not changing still uses level 22, and only the new code uses 26?
Put them in completely independent apps. Otherwise, no. The targetSdkVersion is a per-app setting, not a per-file or per-class setting.

Do I have to write explicit code to ensure the backward compatibility?

If I specify the minimum SDK as 2.0 and the target SDK as 4.1,will I have to write explicit code to ensure backward compatibility. Like if I want to use a gesture detection feature introduced in SDK level 7 and I set the target as 7 and minimum to 3. I am asking will I need to write explicit code(which doesn't include the gesture detection features) so that it runs in targets less than 7 but greater than 3?

Yes, you will have to avoid calling future APIs when running on older versions of Android. You can organize your code to select an appropriate code path at runtime, depending on the version of your OS.
An example of how to preserve backwards-compatibility when using a new API.

Yes, you will need to, but I don't see any logical reason to still support any API before 8 (2.2).
It's literally 1.6% of the market. It's not worth the effort to maintain and support such early versions any more.
That said, if you need to do version specific code, this is the way to handle it:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.ECLAIR) {
//Use API 7+ code
} else {
//Use backwards compatible code
}

You should check out the Android official site on how to guarantee backwards compatibility to minimum level 4 (which is negligible up until api level 7 anyway. The slightly more significant share is usually api level 8 upwards), and always use the latest support library.
Of course there are some minor code changes (such as getSupportFragmentManager() in replace of getFragmentManager(),etc). The worst you it can happen is NoSuchMethodException so you have to be real careful not to call API's that does not exist in lower platforms. The sdk should be very clearly advising that when it happens.

Higher API calls when lower SDK targeted

My app supports minSdkVersion=10 and targeting 16. I want to call methods specific to API level >= 14 if a specific device supports them. I could check running OS version at runtime and whether call or not higher API methods but when I specify min SDK version, methods that exist only in versions higher than 10 are not visible.
Is there any way to use higher API methods than minSdkVersion?

You can test the device's API with this:
if(android.os.Build.VERSION.SDK_INT >= 14) {
// Do something fancy
}
else {
// Do something regular
}

In addition of checking the current version you should also add #SuppressLint("NewApi")to your method so the compiler want yell about it.

Methods from higher API are invisible and inaccessible because project's target SDK is lower than SDK which methods are going to be used. For example: if you want to use methods from API 14 Android project target SDK should be at least 14 or even better the latest (currently 16). That is kind of obvious but I missed it. After that the solution Sam gave a reference to is in use.

Difference between targetSdkVersion and Project build target

What is the difference between targetSdkVersion set in the Manifest file and the Project build target set in the building environment (e.g. Eclipse) ?
I have tried to find more information on these two features, but I couldn't find any clear and specific explanation.
It seems like the Project build target decides on the API compatibility level, to be used during the compilation. When the targetSdkVersion only affects the visibility of the manifest elements of the given API level.
Could anyone confirm/expound this?
EDIT: Thanks guys for prompt responses. I forgot to mention in my question that I have read all the topics on Android Dev regarding these features and also googled it and searched it on Stack Overflow. So I understand the basic purpose of min/target/maxSdkVersion to be used in Android Market and in the Android System itself. However, according to other posts from people having problems with this Manifest option, it seems uses-sdk does actually have impact on how the the API level is interpreted. At least that is what I suspect.
A really good explanation is given here:
http://developer.android.com/guide/appendix/api-levels.html
However, it is still unclear for me whether the targetSdkVersion does affect the compilation/runtime of the APK on Android System? Or it is only for validation as the uses-sdk documentation suggests?

The targetSdkVersion attribute does indeed affect an application's runtime behavior.
Depending on what you set it to will determine whether compatibility features are enabled/disabled in the Android framework.
For example, once you set targetSdkVersion=11, your application's default theme will be set to #android:style/Theme.Holo -- meaning your application will have a Honeycomb-style UI widgets, will get an Action Bar, and will not have an Options Menu button at the bottom of the screen.
If you set targetSdkVersion to a lower value than, your default theme will continue to be #android:style/Theme -- regardless of which API level you're actually building against.
The targetSdkLevel also affects what the default values are for the <supports-screens> element, which in turn will determine whether your application runs in density compatibility mode.
Interesting note: Android Market doesn't actually use the targetSdkLevel attribute for anything at the moment. It's purely used at runtime for compatibility purposes, and possibly at compile time -- though I haven't looked into the behavior there. If people are curious about the compiler, I could check with the SDK team to get more information.
Of course, it's entirely possible that Market could decide to do something with this in the future.

The Build Target is used to know which SDK to compile your APK with. This means that if there are any Classes or methods that aren't available in your min SDK version, but are in versions after that, those Classes or methods will still be available to use. You will just have to make sure to check when you're using those and do alternate approaches if the user's SDK version isn't compatible with those classes/methods.
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.
You can find more information by referring to this URL:
http://developer.android.com/guide/topics/manifest/uses-sdk-element.html
There's also a good article written by google on checking to make sure you're current users Android OS version will use the appropriate Classes/methods
http://android-developers.blogspot.com/2010/07/how-to-have-your-cupcake-and-eat-it-too.html

In your "Create Project"-dialog in Eclipse, you specify the minSdkVersion. This is the API-Level that is required to run your application.
The targetSdkVersion-attribute only tells the Android Market that your App was developed (and maybe optimized) to run under the specified API-Level.

Build target is the one on which you will be testing the app. targetSdkVersion is the one your app was specifically developed for. Both are same most of the times.
You will find a detailed explanation here.

targetSdkVersion attribute informs the system that you have tested your app against the given version (api level) 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).
For further detail - http://developer.android.com/guide/topics/manifest/uses-sdk-element.html

This question has already been adequately answered, but I want to point out that it is no longer entirely correct that the Google Play store does not use targetSdkVersion at all.
In the specific case where you set targetSdkVersion to 23 (Marshmallow 6.0) and upload your APK, even if you are uploading a Beta version, you will not be able to ever again submit an APK for that app that has a lower targetSdkVersion than 23.
This is because of changes to permissions between 22 and 23 which are not allowed to be reversed for a given app.
This can be a bit of a trap if you were just trying out 23 in Beta and not sure you were ready to support it yet.

Confused about Android API's and compatability

I have purchased an HTC Incredible and have dived into the world of android! Only to find myself totally confused about the API levels and backward compatibility.
My device runs the 2.1 OS, but I know that most of the devices out there run 1.5 or 1.6; and soon the 2.2 OS will be running on new devices. The SDK has gone through such enormous changes, that even constants have been renamed (from VIEW_ACTION to ACTION_VIEW for example). Methods have been added and removed (onPause replacing the earlier call, etc al).
So, If I want to write an application that will work from 1.6+, does that mean I have to install and write my code using the 1.6 API; then test on later versions? Or can I write using the 2.1 SDK and just set the minSDK level and not use "new" features?
I have never worked with an SDK that changes SO drastically from release to release! So I am not sure what to do....
I read through an article on the Android Development site(and this posting on stack overflow that references it: Should a legacy Android application be rebuilt using SDK 2.1?), but it was still not very clear to me.
Any help would be appreciated

The SDK has gone through such enormous
changes, that even constants have been
renamed (from VIEW_ACTION to
ACTION_VIEW for example). Methods have
been added and removed (onPause
replacing the earlier call, etc al).
Those were two years ago, on a beta version of the platform, before there were any shipping devices. Since Android 1.0, there has been very little that breaks forward compatibility, mostly in the area of settings that were moved into a secure API so SDK applications cannot mess with them.
So, If I want to write an application
that will work from 1.6+, does that
mean I have to install and write my
code using the 1.6 API; then test on
later versions? Or can I write using
the 2.1 SDK and just set the minSDK
level and not use "new" features?
You make it seem like those are mutually exclusive. In fact, they are largely identical.
Keep your toolset on the latest version of the Android development tools
Put the minSdkVersion in your manifest to state what is the lowest API level you want to support
Put the targetSdkVersion in your manifest to state what your "target" API level is, so Android can apply some compatibility helpers if your app runs on a newer version of Android (typically, you "target" the then-current API level)
Write your code mostly to the API level you specified in minSdkVersion, optionally using reflection or conditional class loading to access newer APIs on devices that support them
Test on everything you can get your hands on, at least emulators for the different API levels

You can use the current SDK and set minSDK level to whatever level you want. If you do this then you cannot use any functionality that is not in the minSDK. It is also a good idea though to test it on all versions of the SDK with the emulator.
<uses-sdk minSDK="4" targetSDK="8"/>
That lets it know that you are targeting 2.2 but the minimum SDK level you want your app to run on is 1.6. By doing that you can use some of the new xml stuff in the newer versions like supports-screen and different drawables for different screens, etc.