Develop Reference

Android #TargetApi return

I'm using a method with boolean return type for api 19 while my app supports min sdk 15, what will the method return incase the api is less than 19 ?
#TargetApi(19)
public static boolean isFeatureXEnabled(Context context) {
some logic
return true/false;
}
what do I get in return for API <19 when calling?
classInstance.isFeatureXEnabled(context);

let's understand #TargetApi(19)
You are using a feature which is not available on minimum SDK so
Compiler : you cannot use this feature , it is not supported by min sdk
You: i know what i am doing so hush , take this #TargetApi(19)
Compiler : so now it is your responsibility to check the API level and call this function accordingly
what will the method return incase the api is less than 19
If the code inside this function is not supported by minsdk then most likely a crash otherwise your result of your logical calculation
you can do something like this
#TargetApi(19)
public static boolean isFeatureXEnabled(Context context) {
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
some logic
return true/false;
}
return false;
}

#TargetApi
Indicates that Lint should treat this type as targeting a given API level, no matter what the project target is — https://developer.android.com/reference/android/annotation/TargetApi.html
It means it is just used by Lint to hide/suppress the warning. It has ho effect in the return value.

Checking multi window support

I've a problem with checking is device supports Mutli Window Mode. I'm using this function to check it isInMultiWindowMode() but it've added in API 24, and when i'm runs my app on device with lower api version it cause an exception. There is any replacement for this function for lower api versions?

There is any replacement for this function for lower api versions?
Not in the Android SDK. There is no multi-window mode (from the Android SDK's standpoint) prior to API Level 23. And, for whatever reason, Google elected not to add isInMultiWindowMode() to ActivityCompat, perhaps because they cannot support the corresponding event (onMultiWindowModeChanged()).
So, here's a free replacement method:
public static boolean isInMultiWindowMode(Activity a) {
if (Build.VERSION.SDK_INT <= Build.VERSION_CODES.M) {
return false;
}
return a.isInMultiWindowMode();
}
Add that to some utility class somewhere and call it as needed.
Also note that isInMultiWindowMode() suffers from a race condition that makes it unreliable, IMHO.

What #CommonsWare explained is true, it is a race condition. Hence, isInMultiWindowMode() will give actual result if you call it from inside post method:
View yourView = findViewById(R.id.yourViewId);
yourView.post(new Runnable() {
#Override
public void run() {
boolean actualResult = isInMultiWindowMode();
}
});

Does android always use the newest API to run an app?

I was messing around with MeasureSpec when I came across this bit of text:
Note: On API level 17 and lower, makeMeasureSpec's implementation was such that the order of arguments did not matter and overflow in either value could impact the resulting MeasureSpec. RelativeLayout was affected by this bug. Apps targeting API levels greater than 17 will get the fixed, more strict behavior.
So that got me wondering: If I build an app for API 14 but I run it on an API 22 device will it fix the bug or will < API 17's bug still exist on the 22 device?

makeMeasureSpec(API 17<) method's implementation is the following:
public static int makeMeasureSpec(int size, int mode) {
if (sUseBrokenMakeMeasureSpec) {
return size + mode;
} else {
return (size & ~MODE_MASK) | (mode & MODE_MASK);
}
}
As you can see it's return value is depending on the value of sUseBrokenMakeMeasureSpec which value is assigned in the View class's constructor:
sUseBrokenMakeMeasureSpec = targetSdkVersion <= JELLY_BEAN_MR1;
So only the app's target will determine the behaviour. By doing it this way a newer system can maintain compatibility with an older app which expets the old behaviour.

Android handle deprecated method

This is how I handle a deprecated method:
int layoutDirection ;
if (getContext().getApplicationInfo().targetSdkVersion > Build.VERSION_CODES.JELLY_BEAN_MR1) {
layoutDirection = getLayoutDirection();
}else {
layoutDirection = getResolvedLayoutDirection();
}
The problem is that getResolvedLayoutDirection() has been removed at JELLY_BEAN_MR1 and above. So since my project targets API 20 the method cannot be found and I get an error.
If I keep it foolish:
int layoutDirection = getLayoutDirection();
The project compiles and runs but still I get an error to add either the TargetApi or SuppressLint annotation. getLayoutDirection() docs have:
For compatibility, this will return {#link #LAYOUT_DIRECTION_LTR} if
API version is lower than {#link
android.os.Build.VERSION_CODES#JELLY_BEAN_MR1}.
So suppressing lint should be fine.
Should I suppress the lint error or fix it somehow else (possibly make getResolvedLayoutDirection() accessible)?

The approach to conditionally check whether a method is available is to check the version of Android that the device is running, via Build.VERSION.SDK_INT:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLY_BEAN_MR1) {
layoutDirection = getLayoutDirection();
}
else {
layoutDirection = View.LAYOUT_DIRECTION_LTR;
}
And add #TargetApi(Build.VERSION_CODES.JELLY_BEAN_MR1) to the method containing the above block to indicate to the build tools that, for that individual method, to consider your minSdkVersion to be 17 instead of whatever it normally is, for the purposes of generating Lint warnings and errors.

TargetApi not taken into account

In one of our methods, we use smoothScrolling in a list view. As this method is not available before API Level 8 (FROYO), we used the TargetApi annotation to prevent the method from being called in previous SDK versions.
As you can see, we do use TargetApi annotation both in class definition and in statements that use the objects of the class. This is more than needed.
Our problem is that the TargetApi annotation is not taken into account and make our emulator crash in version ECLAIR (SDK 7). By tracing, we just realize that the code that should only be executed in versions 8+ is also executed in version 7.
Are we missing something?
This code is in a listener :
#TargetApi(8)
private final class MyOnMenuExpandListener implements OnMenuExpandListener {
#Override
public void onMenuExpanded( int position ) {
doScrollIfNeeded( position );
}
#Override
public void onMenuCollapsed( int position ) {
doScrollIfNeeded( position );
}
protected void doScrollIfNeeded( int position ) {
if ( mListViewDocuments.getLastVisiblePosition() - 2 < position ) {
mListViewDocuments.smoothScrollToPosition( position + 1 );
}
}
}
And the listener is registered this way :
#TargetApi(8)
private void allowSmothScrollIfSupported() {
if ( Build.VERSION.SDK_INT >= Build.VERSION_CODES.FROYO ) {
//This if should not be necessary with annotation but it is not taken into account by emulator
Log.d( LOG_TAG, "Smooth scroll support installed." );
folderContentAdapter.setOnMenuExpandListener( new MyOnMenuExpandListener() );
}
}
BTW, we run the code in debug mode, so the issue is not related to obfuscation removing annotations.

#TargetApi does not prevent any code from being run, it is merely for annotating code and preventing compiler errors for new APIs once you know you are only conditionally calling them.
You still need to add something along the lines of
if (Build.VERSION.SDK_INT > 7){
//...
}

With almost one year of more thinking about this, I would like to add a tiny complement to #Guykun 's answer :
The #TargetApi will be only be used by tools to say developers "Hey, don't use this method below XXX android SDK". Typically lint.
So, if you design a method like :
if (Build.VERSION.SDK_INT > 7){
//...
}
then you should add #TargetApi( 7 ) to your method's signature.
BUT, if you add an else statement, and provide an alternative that makes it work for all versions of Android like :
if (Build.VERSION.SDK_INT > 7){
//...
} else {
//...
}
then you should not add #TargetApi( 7 ) to your method's signature. Otherwise, other developers will think they can't use your method belw api level 7, but indeed, it would work for them as well.
So this annotation has to be used, for static analysis, to indicate the minimum api level supported by the method. As in :
#TargetApi( 7 )
public void foo() {
if (Build.VERSION.SDK_INT > 7){
//...
else if (Build.VERSION.SDK_INT > 10){
//...
}
}
and even better, use constants defined in android.Build.VERSION_CODES.*.
BTW, you would have noticed that this is useless for private methods indeed, except to get a cleaner code and help to promote the method public in the future.

To enforce lint error when using a method targeted towards higher Api Level, you can use RequiresApi instead of TargetApi and whenever you'll try to use the method without checking the version code, you'll get compilation error.
This is what the documentation says about RequiresApi
This is similar in purpose to the older #TargetApi annotation, but
more clearly expresses that this is a requirement on the caller,
rather than being used to "suppress" warnings within the method that
exceed the minSdkVersion.