我讨厌警告。我们的 Android 项目现在有 151 个，我敢肯定，在列表的某个地方，确实有一个可以警告我们注意潜在的麻烦。
其中一种警告是关于不推荐使用的字段和方法。这可能很有用，除了 Manifest 包含<uses-sdk android:minSdkVersion="10" />，并且这些警告仅考虑targetSDK 是android-17.
将这些警告静音很容易——@SuppressWarnings("deprecation")在有问题的行或整个方法之前添加注释。但这忽略了它的全部要点 - 如果/当我们决定更改时minSdkVersion="11"，在第 10 级已弃用的 API 仍然不会出现，并且有人将不得不检查我们所有项目中的所有注释，以找到哪些代码必须被重写。
是否有一些解决方案可以根据我的minSdkVersion管理这些警告？
似乎在下面发布了一个有趣的答案，甚至根据我的问题提出了一个功能请求的Mark并不同意我关于minSdkVersion的重要性。他希望看到基于目标 API 级别的弃用警告（很可能来自 Lint，类似于注释）。但我不能同意这种做法。@TargetApi(NN)
考虑一个打开相机的简单应用程序。它可能要检查预览帧速率。但这种方法在 API 9 中已被弃用，现在我们必须检查预览 FPS 范围。如果我们使用platforms/android-8/android.jar，Java 编译器将不会显示弃用警告。
但它不会让我们找到首选的视频分辨率，即使应用程序运行在支持此类查询的设备上也是如此。我们可能会在@TargetApi(11)那里添加注释，以确保应用程序是使用platforms/android-11/android.jar或更高版本构建的。
现在我们有了目标Honeycomb和更高版本，将显示getPreviewFrameRate()的弃用警告，这正是困扰我的地方。有一段时间，我想象的应用程序必须支持一些Froyo设备，因此我别无选择，只能设置minSdkVersion=8和使用不推荐使用的方法。自然，我会在条件块中使用任何高级 API，并准备@TargetApi(NN)好。幸运的是，对于Donut及更高版本，当检测到对不存在的方法或成员的调用时，类加载器不会崩溃，并且仅将有问题的调用包装在if()中就足够了。
那我该怎么办？添加对getPreviewFrameRate()@SuppressWarnings("deprecation")的调用以使警告静音？改为添加？@SuppressDeprecation(8)
但在某些时候，我会决定与 Froyo 的向后兼容性不再重要。我在我的 Manifest 中设置了，但是getPreviewFrameRate()<uses-sdk android:minSdkVersion="9" />的弃用警告仍然被抑制......嗯，新方法肯定比现有的注释更好，因为在 Manifest 中进行更改后，整个项目更容易。grep -R "@SuppressDeprecation(8)"
但我更喜欢这里更紧密的集成：让 Lint 为我解析 Manifest 文件。
现在这是否更有意义？