What is better: @SuppressLint or @TargetApi?
I have issues in my app regarding StrictMode and added the code snippet that basically disables the StrictModeHelper
Please fix the networking bug.
Which method is prefered ..or are they basically doing the same?
@TargetApi
and @SuppressLint
have the same core effect: they suppress the Lint error.
The difference is that with @TargetApi
, you declare, via the parameter, what API level you have addressed in your code, so that the error can pop up again if you later modify the method to try referencing something newer than the API level cited in @TargetApi
.
For example, suppose that, instead of blocking the StrictMode
complaints about your networking bug, you were trying to work around the issue of AsyncTask
being serialized on newer versions of Android. You have a method like this in your code to opt into the thread pool on newer devices and use the default multithread behavior on older devices:
@TargetApi(11)
static public <T> void executeAsyncTask(AsyncTask<T, ?, ?> task,
T... params) {
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
task.executeOnExecutor(AsyncTask.THREAD_POOL_EXECUTOR, params);
}
else {
task.execute(params);
}
}
Having @TargetApi(11)
means that if Lint detects that I am using something newer than my android:minSdkVersion
, but up to API Level 11, Lint will not complain. In this case, that works. If, however, I modified this method to reference something that wasn't added until API Level 14, then the Lint error would appear again, because my @TargetApi(11)
annotation says that I only fixed the code to work on API Level 11 and below above, not API Level 14 and below above.
Using @SuppressLint('NewApi')
, I would lose the Lint error for any API level, regardless of what my code references and what my code is set up to handle.
Hence, @TargetApi
is the preferred annotation, as it allows you to tell the build tools "OK, I fixed this category of problems" in a more fine-grained fashion.
android @Suppress errors vs @TargetApi
@TargetApi(NN)
says "Hey, Android! Yes, I know I am using something newer than what is allowed for in my android:minSdkVersion
. That's OK, though, 'cause I am sure that I am using Build
(or something) such that the newer code only runs on newer devices. Please pretend that my minSdkVersion
is NN
for the purposes of this (class|method)".
@SuppressLint
, to address the same error, says "Hey, Android! Yes, I know I am using something newer than what is allowed for in my android:minSdkVersion
. Quit complaining.".
Hence, given a choice of @TargetApi(NN)
or @SuppressLint
, go with @TargetApi(NN)
. There, if you start using something newer than NN
-- and therefore your existing version-checking logic may be insufficient -- you will get yelled at again.
Calling API from higher API level than the minimum requirement
Would this one line be ignored?
No.
Would my app crash?
Spectactularly. :-)
Would the app be filtered by Google Play so they can't install?
No.
I'd like to have this single line ignore on lower devices.
You have two problems:
@SuppressLint("NewApi")
was the wrong quick-fix choiceYou didn't add any code to avoid this line on older devices
Use @TargetApi(...)
instead of @SuppressLint("NewApi")
, where ...
is the name (e.g., FROYO
) or number (e.g., 8
) of the code that your method is referencing.
But before you do that, wrap your offending lines in a check to see if they should be executed on this device:
if (Build.VERSION.SDK_INT>=Build.VERSION_CODES.FROYO) {
// then execute your code that requires API Level 8
}
// optional else block if you have some workaround for API Level 7
Your if
check will cause your line to be avoided. Your @TargetApi
annotation will cause Lint to stop yelling at you about referencing a too-new class or method.
what is the use of @SuppressLint(InlinedApi)
By executing lint --list
(the lint tool is located in your sdk/tools
directory) you can see a list of the valid issue id's. You can find the explanation of InlinedApi
there :
"InlinedApi": Finds inlined fields that may or may not work on older
platforms
What is the proper way to get rid of compatibility errors?
Using TargetApi
, you tell the compiler that you are sure that this class/method/whatever is never ever called unless the API requirements are met.
That's what you want to do. But that also means that your must make sure that this class is never called under this level of API. You can do that by using
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
// Call that class
} else {
// Call another class
}
android implement methods to different api levels
Use:
@TargetApi(Build.VERSION_CODES.HONEYCOMB_MR2)
private int getDisplayWidth(Display display){
if (Build.VERSION.SDK_INT>=Build.VERSION_CODES.HONEYCOMB_MR2) {
Point size = new Point();
display.getSize(size);
return size.x;
}
return display.getWidth();
}
Suppress API level warning in code
Don't use a boolean for the API checking. Put it directly in the if statement:
if (Build.VERSION.SDK_INT < android.os.Build.VERSION_CODES.KITKAT)
{
smsIntent.setPackage("vnd.android-dir/mms-sms");
}
else
{
smsIntent.setPackage(Telephony.Sms.getDefaultSmsPackage(getActivity()));
}
That should make the warning go away. TargetApi annotations should be done at the method level:
@TargetApi(Build.VERSION_CODES.KITKAT)
public void yourKitkatMethod() {}
Call requires API level 11(current min is 9) android.app.Activity#onCreateView
I encountered the same issue as well.
If you take a look at the javadoc for the Activity class (http://developer.android.com/reference/android/app/Activity.html#onCreateView%28android.view.View,%20java.lang.String,%20android.content.Context,%20android.util.AttributeSet%29), you'll see that the method public View onCreateView (View parent, String name, Context context, AttributeSet attrs) was added in API 11.
Rather than using @SuppressLint("NewApi") at the class declaration level, I added that particular method to my code and suppressed the lint warning for the method declaration. Like so:
@SuppressLint("NewApi")
public View onCreateView(View parent, String name, Context context, AttributeSet attrs)
{
if(Build.VERSION.SDK_INT >= 11)
return super.onCreateView(parent, name, context, attrs);
return null;
}
This way any future additions to the code of the class will still get checked by lint, but lint will stop flagging this method with an error.
ETA: Javadoc for class indicates that both onCreateView(...) methods return null as the default behavior, and that the pre API 11 method has an empty implementation.
Related Topics
Custom Listview Fast Scrollbar in Android
Mobile Chrome Fires Resize Event on Scroll
Setting Action Bar Title and Subtitle
Android Active Link of Url in Textview
How to Set Status Bar Background as Gradient Color or a Drawable in Android
Make Android Webview Not Store Cookies or Passwords
Release APK Not Updating with JavaScript Code
Eclipse: Won't Let Me Use Android Sdk, Wrongly Claims My Adt Is Out of Date
How to Display a One Time Welcome Screen
Constraintlayout Chains and Text Ellipsis + Image on The Right
How to Hide The System/Navigation Bar in Android Ics
Fragment Standard Transition Not Animating
Bitmapfactory.Decodestream Out of Memory Despite Using Reduced Sample Size
Access Ordered Images and Video in Same Cursor
Not Able to Debug App in Android Studio
How to Show Alphabetical Letters on Side of Android Listview
How to Disable "Next" Button on a Edittext Software Keyboard (Replace with "Done" Button)
Android - Set a Progressbar to Be a Vertical Bar Instead of Horizontal