Verwalten 'veraltete' Warnungen in Android-Projekt mit MinSdkVersion

Question

Ich hasse Warnungen. Unser Android-Projekt hat jetzt 151, und ich bin mir sicher, dass es irgendwo auf der Liste einen gibt, der uns tatsächlich vor einem potenziellen Ärger warnt.

Ein Typ dieser Warnungen bezieht sich auf veraltete Felder und Methoden. Dies könnte nützlich sein, außer dass das Manifest <uses-sdk android:minSdkVersion="10" /> enthält und diese Warnungen nur das target SDK berücksichtigen, das android-17 ist.

Es ist einfach, diese Warnungen stumm zu schalten - fügen Sie @SuppressWarnings("deprecation") Annotation vor der betreffenden Zeile oder die gesamte Methode hinzu. Aber das vermisst den ganzen Punkt - wenn wir uns entscheiden, minSdkVersion="11" zu ändern, werden die APIs, die auf Stufe 10 veraltet sind, immer noch nicht angezeigt, und jemand muss alle Anmerkungen in unserem gesamten Projekt durchgehen, um den Code zu finden muss neu geschrieben werden.

Gibt es eine Lösung, die diese Warnungen basierend auf meinem minSdkVersion verwalten könnte?

---

Es scheint, dass Mark, die unten eine interessante Antwort geschrieben, und sogar filed a feature request inspiriert durch meine Frage mit mir nicht einverstanden ist über die Bedeutung der minSdkVersion. Er würde es vorziehen, Abnutzungswarnungen (höchstwahrscheinlich von Lint, ähnlich wie die @TargetApi(NN) Annotationen) basierend auf der Ziel-API-Ebene zu sehen. Aber ich kann diesem Ansatz nicht zustimmen.

Betrachten Sie eine einfache Anwendung, die die Kamera öffnet. Vielleicht möchten Sie die preview frame rate überprüfen. Aber diese Methode wurde an API 9 nicht weiter unterstützt und jetzt müssen wir die preview FPS range überprüfen. Wenn wir platforms/android-8/android.jar verwenden, zeigt der Java-Compiler keine veralteten Warnungen an.

Aber es wird uns nicht erlauben, die preferred video resolution zu finden, auch wenn die Anwendung auf einem Gerät läuft, das eine solche Abfrage unterstützt. Wir werden wahrscheinlich @TargetApi(11) Annotation hinzufügen, um sicherzustellen, dass die Anwendung mit platforms/android-11/android.jar oder höher erstellt wird.

Jetzt, da wir Ziel Honeycomb und höher, wird die deprecation Warnung für getPreviewFrameRate gezeigt werden() , und das ist genau das, was mich stört. Für eine Weile muss meine imaginäre Anwendung einige Froyo Geräte unterstützen, daher habe ich keine andere Wahl als minSdkVersion=8 setzen und die veraltete Methode verwenden. Natürlich werde ich alle erweiterten APIs in bedingten Blöcken verwenden und die @TargetApi(NN) an Ort und Stelle haben. Zum Glück, für Donut und höher, stürzt der Klassenlader nicht ab, wenn ein Aufruf an eine nicht existierende Methode oder Mitglied erkannt wird, und das Wrapping der fragwürdigen Anrufe in nur if() ist genug.

Also was mache ich? Fügen Sie @SuppressWarnings("deprecation") um die Anrufe zu getPreviewFrameRate() hinzu, um die Warnungen stumm zu schalten? Fügen Sie stattdessen @SuppressDeprecation(8) hinzu?

Aber irgendwann werde ich entscheiden, dass die Abwärtskompatibilität mit Froyo nicht mehr wichtig ist. Ich setze <uses-sdk android:minSdkVersion="9" /> in meinem Manifest, aber die Verfallswarnungen für getPreviewFrameRate() sind immer noch unterdrückt ...Nun, der neue Ansatz ist definitiv besser als die vorhandene Annotation, weil es einfacher ist, das gesamte Projekt grep -R "@SuppressDeprecation(8)" nach der Änderung in Manifest zu machen.

Aber ich würde hier eine etwas engere Integration bevorzugen: lass Lint die Manifest-Datei für mich analysieren.

Macht das jetzt mehr Sinn?

Answer 1

Es ist eigentlich ein Feature-Request für diese: https://code.google.com/p/android/issues/detail?id=41318 am 12. Dezember eingereicht 2012.

Answer 2

Gibt es eine Lösung, die diese Warnungen basierend auf meiner minSdkVersion verwalten könnte?

Nein, weil die Einstellung nichts mit android:minSdkVersion zu tun hat.

Wenn Sie sich darüber Sorgen machen, isolieren Sie die veralteten Inhalte in ihre eigenen Methoden, um die Wahrscheinlichkeit zu minimieren, dass Ihre Anmerkung zukünftige Abwertungen verschleiert, von denen Sie nichts wissen.

Was nicht völlig ausgeschlossen ist, wäre eine @SuppressDeprecation(NN) Annotation, die die Abwertungen für ein bestimmtes Build-Ziel unterdrücken würde. Dies wäre ähnlich wie @TargetApi(NN) Lint Beschwerden für eine gegebene android:minSdkVersion unterdrückt. Ich habe filed a feature request for this.