我讨厌警告。我们的Android项目现在有151个，我相信在列表的某个地方有一个实际上警告我们免受潜在麻烦。
这些警告中的一种是关于不推荐使用的字段和方法。这可能很有用，只是清单包含<uses-sdk android:minSdkVersion="10" />，而这些警告只会考虑target SDK android-17。
很容易将这些警告静音 - 在违规行之前添加@SuppressWarnings("deprecation")注释或整个方法。但这忽略了它的全部要点 - 如果/当我们决定更改minSdkVersion="11"时，在10级弃用的API仍然不会显示，并且有人将不得不在我们所有的项目中查看所有注释，找到必须重写的代码。
是否有一些解决方案可以根据我的 minSdkVersion 管理这些警告？
似乎Mark在下面发布了一个有趣的答案，甚至filed a feature request受到我的问题的启发并不同意我对 minSdkVersion 的重要性的看法。他希望看到基于目标API级别的弃用警告（很可能来自Lint，类似于@TargetApi(NN)注释）。但我不同意这种方法。
考虑打开相机的简单应用程序。它可能想要检查preview frame rate。但是这种方法在API 9中已弃用，现在我们必须检查preview FPS range。如果我们使用platforms/android-8/android.jar，Java编译器将不会显示弃用警告。
但即使应用程序在支持此类查询的设备上运行，它也不允许我们找到preferred video resolution。我们可能会在那里添加@TargetApi(11)注释，以确保应用程序使用platforms/android-11/android.jar或更高版本构建。
现在我们已经定位 Honeycomb 和更高版本，将为 getPreviewFrameRate（）显示弃用警告，这正是困扰我的。有一段时间，我想象中的应用程序必须支持一些 Froyo 设备，因此我别无选择，只能设置minSdkVersion=8并使用弃用的方法。当然，我将在条件块中使用任何高级API，并使@TargetApi(NN)到位。 幸运的是，对于 Donut 以及更高版本，当检测到对不存在的方法或成员的调用时，类加载器不会崩溃，并且仅仅在 if（）中包装可疑调用就够了。
那我该怎么办？在对 getPreviewFrameRate（）的调用周围添加@SuppressWarnings("deprecation")来静音警告？改为添加@SuppressDeprecation(8)？
但在某些时候，我将决定与Froyo的向后兼容性不再重要。我在我的清单中设置了<uses-sdk android:minSdkVersion="9" />，但是 getPreviewFrameRate（）的弃用警告仍被抑制......好吧，新方法肯定比现有的注释更好，因为它更容易{ {1}}在Manifest中进行更改后的整个项目。
但我更喜欢这里更紧密的集成：让Lint为我解析Manifest文件。
这现在更有意义吗？
答案 0 :(得分：7)
是否有一些解决方案可以根据我的minSdkVersion管理这些警告？
不，因为弃用与android:minSdkVersion无关。
如果您真的对此感到担心，请将已弃用的内容隔离到自己的方法中，以最大程度地降低注释将掩盖您未知的未来弃用的几率。
什么不是完全不可能的是@SuppressDeprecation(NN)注释，它会抑制给定构建目标的弃用。这类似于@TargetApi(NN)如何抑制给定android:minSdkVersion的Lint投诉。我有filed a feature request for this。
答案 1 :(得分：2)
实际上有一项功能请求：https://code.google.com/p/android/issues/detail?id=41318于2012年12月12日提交。