managing 'deprecated' warnings in Android project with minSdkVersion

Question

I hate warnings. Our Android project has 151 now, and I am sure that somewhere down the list there is one that actually warns us against a potential trouble.

One type of these warnings is about deprecated fields and methods. This could be useful, except that the Manifest contains <uses-sdk android:minSdkVersion="10" />, and these warnings only take into account the target SDK which is android-17.

It's easy to mute these warnings - add @SuppressWarnings("deprecation") annotation before the offending line, or the whole method. But this misses the whole point of it - if/when we decide to change minSdkVersion="11", the APIs that are deprecated at level 10 will still not show up, and somebody will have to go through all annotations in all our project, to find which code must be rewritten.

Is there some solution that could manage these warnings based on my minSdkVersion?

---

It seems that Mark who posted an interesting answer below, and even filed a feature request inspired by my question does not agree with me about the importance of minSdkVersion. He would prefer to see deprecation warnings (most likely from Lint, similar to the @TargetApi(NN) annotations) based on the target API level. But I cannot agree with this approach.

Consider a simple application that opens the Camera. It might want to check the preview frame rate. But this method was deprecated at API 9, and now we must check the preview FPS range. If we use platforms/android-8/android.jar, the Java compiler will not show deprecation warnings.

But it will not allow us to find the preferred video resolution, even in case the application is running on a device that supports such query. We will probably add @TargetApi(11) annotation there, to make sure the application is built with platforms/android-11/android.jar or higher.

Now that we have target Honeycomb and higher, the deprecation warning will be shown for getPreviewFrameRate(), and this is exactly what bothers me. For a while, my imaginary application must support some Froyo devices, therefore I have no choice but set minSdkVersion=8 and use the deprecated method. Naturally, I will use any advanced APIs in conditional blocks, and have the @TargetApi(NN) in place. Luckily, for Donut and higher, the class loader does not crash when a call to a non-existent method or member is detected, and wrapping the questionable calls in mere if() is enough.

So what do I do? Add @SuppressWarnings("deprecation") around the calls to getPreviewFrameRate() to mute the warnings? Add @SuppressDeprecation(8) instead?

But at some point, I will decide that the backward compatibility with Froyo is not important anymore. I set <uses-sdk android:minSdkVersion="9" /> in my Manifest, but the deprecation warnings for getPreviewFrameRate() are still suppressed... Well, the new approach is definitely better than the existing annotation, because it's easier to grep -R "@SuppressDeprecation(8)" the whole project after the change is made in Manifest.

But I would prefer a bit more tight integration here: let Lint parse the Manifest file for me.

Does this make better sense now?

Answer 1

Is there some solution that could manage these warnings based on my minSdkVersion?

No, because deprecation has nothing to do with android:minSdkVersion.

If you are really worried about this, isolate the deprecated stuff into their own methods, to minimize the odds that your annotation will obscure future deprecations of which you are unaware.

What's not completely out of the question would be a @SuppressDeprecation(NN) annotation, that would suppress deprecations for a given build target. This would be akin to how @TargetApi(NN) suppresses Lint complaints for a given android:minSdkVersion. I have filed a feature request for this.