警告が嫌いです。私たちのAndroidプロジェクトには現在151人がいます。リストのどこかに潜在的なトラブルから私たちに警告するものがあると確信しています。minSdkVersionのAndroidプロジェクトで「廃止予定」の警告を管理しています
これらの警告の1つのタイプは、非推奨のフィールドとメソッドです。マニフェストに<uses-sdk android:minSdkVersion="10" />が含まれ、android-17というtarget SDKのみが考慮される点を除いて、これは便利です。
これらの警告をミュートするのは簡単です。違反行の前に@SuppressWarnings("deprecation")注釈を追加するか、メソッド全体を追加します。しかし、これが全体のポイントを逃してしまいます。minSdkVersion="11"を変更する場合、レベル10で廃止予定のAPIはまだ表示されず、誰かがすべてのプロジェクトのすべての注釈を調べ、コードを見つける必要があります書き直さなければならない。
minSdkVersionに基づいてこれらの警告を管理できる解決策がありますか？
なお、以下に面白い答えを掲示し、さらにfiled a feature requestは私の質問に触発MarkがminSdkVersionがの重要性について私と一緒に同意していないようです。彼はターゲットAPIレベルに基づいて非推奨警告（ほとんどの場合、Lint、@TargetApi(NN)注釈と同様）を見たいと考えています。しかし、私はこのアプローチに同意できません。
カメラを開く簡単なアプリケーションを考えてみましょう。 preview frame rateを確認してください。しかしこのメソッドはAPI 9では廃止されました。今度はpreview FPS rangeをチェックする必要があります。 platforms/android-8/android.jarを使用すると、Javaコンパイラは廃止予定の警告を表示しません。
ただし、このようなクエリをサポートするデバイスでアプリケーションが実行されている場合でも、preferred video resolutionは見つかりません。アプリケーションにplatforms/android-11/android.jar以上が組み込まれていることを確認するため、おそらく@TargetApi(11)注釈を追加します。
今、私たちは、非推奨の警告が
getPreviewFrameRate（のためのターゲット
ハニカムと高く表示されますされていること）
、これは私を悩ます、まさにです。しばらくの間、私の想像上のアプリケーションは、Froyoデバイスをサポートする必要があります。したがって、私は選択肢がありませんが、minSdkVersion=8を使用し、廃止予定の方法を使用します。当然ながら、私は条件付きブロックで任意の高度なAPIを使用し、@TargetApi(NN)を適切に配置します。 幸いにも、の場合、以上では、存在しないメソッドやメンバーへの呼び出しが検出された場合にクラスローダーがクラッシュせず、の疑わしい呼び出しをラップすると、（）で十分です。
どうすればいいですか？
getPreviewFrameRate（）
への呼び出しの回りに@SuppressWarnings("deprecation")を追加して警告をミュートしますか？代わりに@SuppressDeprecation(8)を追加しますか？
しかし、ある時点で、私はFroyoとの後方互換性がもう重要ではないと判断します。私はマニフェストに<uses-sdk android:minSdkVersion="9" />を設定しましたが、
getPreviewFrameRate（）
の廃止予定の警告はまだ抑制されています...まあ、変更後のプロジェクト全体がgrep -R "@SuppressDeprecation(8)"より簡単であるため、新しいアプローチは既存のアノテーションよりもはるかに優れています。
しかし、もう少し緊密に統合したいと思っています。LintがManifestファイルを解析してください。
これは今の方が理にかなっていますか？
チェック！ –