Управление «устаревшими» предупреждениями в Android-проекте с помощью minSdkVersion

Я ненавижу предупреждения. Сейчас у нашего Android-проекта есть 151, и я уверен, что где-то в списке есть тот, который на самом деле предупреждает нас о потенциальных проблемах.

Один из типов этих предупреждений – об устаревших полях и методах. Это может быть полезно, за исключением того, что манифест содержит <uses-sdk android:minSdkVersion="10" /> , и эти предупреждения учитывают только target SDK, который является android-17 .

Легко отключить эти предупреждения – добавьте @SuppressWarnings("deprecation") до строки нарушения или весь метод. Но это не соответствует всему этому – если / когда мы решили изменить minSdkVersion="11" , API, которые устарели на уровне 10, все равно не появятся, и кому-то придется пройти все аннотации во всем нашем проекте, Чтобы найти, какой код должен быть переписан.

Есть ли какое-то решение, которое могло бы управлять этими предупреждениями на основе моего minSdkVersion ?


Похоже, что Марк, который разместил интересный ответ ниже и даже подал запрос на функцию, вдохновленный моим вопросом, не согласен со мной в отношении важности minSdkVersion . Он предпочел бы видеть предупреждения об устаревании (скорее всего, из Lint, похожие на @TargetApi(NN) ) на основе целевого уровня API. Но я не могу согласиться с этим подходом.

Рассмотрим простое приложение, которое открывает камеру. Возможно, потребуется проверить частоту кадров предварительного просмотра . Но этот метод был устаревшим в 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 и выше, загрузчик классов не сбой, когда обнаружен вызов несуществующего метода или члена, и обертывание сомнительных вызовов просто, если () достаточно.

Итак, что мне делать? Добавить @SuppressWarnings("deprecation") вокруг вызовов getPreviewFrameRate (), чтобы отключить предупреждения? Добавьте вместо этого @SuppressDeprecation(8) ?

Но в какой-то момент я решит, что обратная совместимость с Froyo уже не важна. Я установил <uses-sdk android:minSdkVersion="9" /> в моем манифесте, но предупреждения о недопустимости для getPreviewFrameRate () все еще подавлены … Ну, новый подход определенно лучше, чем существующая аннотация, потому что проще grep -R "@SuppressDeprecation(8)" весь проект после изменения сделан в манифесте.

Но я предпочел бы более сложную интеграцию здесь: пусть Lint проанализирует файл манифеста для меня.

Теперь это имеет смысл?

Solutions Collecting From Web of "Управление «устаревшими» предупреждениями в Android-проекте с помощью minSdkVersion"

Есть ли какое-то решение, которое могло бы управлять этими предупреждениями на основе моего minSdkVersion?

Нет, потому что устаревание не имеет ничего общего с android:minSdkVersion .

Если вы действительно беспокоитесь об этом, изолируйте устаревшие вещи в своих собственных методах, чтобы свести к минимуму вероятность того, что ваша аннотация будет скрывать будущие суждения, о которых вы не знаете.

Не исключено, что это будет аннотация @SuppressDeprecation(NN) , которая будет подавлять отклонения для заданной цели сборки. Это будет похоже на то, как @TargetApi(NN) подавляет жалобы Lint для данного android:minSdkVersion . Я подал заявку на эту функцию .

На самом деле есть запрос функции для этого: https://code.google.com/p/android/issues/detail?id=41318, поданный 12 декабря 2012 года.