Создание Android-приложений с несколькими SDK в Eclipse без потери проверок во время компиляции

Я разрабатываю приложение для Android в Eclipse. Я хотел бы ориентироваться на самые разные устройства и версии SDK (например, я могу опционально поддерживать мультитач). Я понимаю рекомендуется выделить все новые функции в отдельный класс и использовать отложенную загрузку, чтобы загружать только этот класс при запуске. время, если хост-устройство действительно поддерживает эту функцию.

Недостатком этого подхода является то, что мне приходится компилировать весь свой код с SDK новейшей функции, которую я хочу использовать. Это означает, что если какая-то новая функция просочится в мой независимый от версии код, компилятор больше не сможет ее уловить.

Я хотел бы, чтобы в Eclipse была возможность скомпилировать мой проект со старым Android SDK, чтобы убедиться, что мой код, не зависящий от версии, в порядке. Я бы хотел, если это возможно, не перемещать свою систему сборки из Eclipse. Меня устраивает, что эту старую сборку SDK немного неудобно запускать.

Я думаю, что это сводится к выполнению некоторой условной компиляции (или условной компоновки) внутри Eclipse? Например, в моем проекте при сборке с SDK-1.6 я хотел бы оставить исходный код MultiTouchHandler.java вне сборки. Однако я не уверен, что в Eclipse можно выразить такие типы сборки.

Похоже, что хакерское решение просто вручную меняет версию SDK проекта, перестраивает и просматривает ошибки и игнорирует «ожидаемые» ошибки. Решение overkill, похоже, пишет мои собственные сценарии сборки ant/maven/make.

Похожие вопросы

Этот вопрос: Управление версиями и общие кодовые базы с Eclipse охватывает аналогичную тему. , но потребует перемещения всех классов, зависящих от версии, в отдельные библиотеки. (И я думаю, что у меня все еще будет проблема с несколькими типами сборки в Eclipse.)

Этот вопрос: Построить несколько конфигураций проекта с помощью eclipse подразумевает, что я должен перейти к внешняя система сборки (например, ant или maven), но это намного больше работы, чем просто время от времени пытаться собрать старый SDK.


person P.T.    schedule 04.10.2011    source источник


Ответы (2)


Обновления инструмента Lint Tool в ADT от февраля 2012 г. (v17) должны помочь решить эту проблему, не требуя нескольких сборок. Когда приложение нацелено на старый минимальный SDK, но скомпилировано с новейшим SDK (как это рекомендуется), инструмент lint заметит, если будут вызваны вызовы к более новому SDK. Если вы уверены, что вызов в порядке (потому что вы скрыли его за проверкой SDK_INT во время выполнения или чем-то еще), вы можете быстро исправить аннотацию, чтобы предотвратить предупреждение.

Например, в моем коде есть вызов View.setSystemUiVisibility, который был введен в API 11, но я ориентируюсь на API 8. Запуск Lint показывает:

Для вызова требуется уровень API 11 (текущий минимум 8): android.view.View#setSystemuiVisibility

QuickFix предлагает два вида исправлений: либо добавление аннотации, подавляющей предупреждение, либо добавление аннотации, объявляющей фрагмент кода работающим в API 11.

Подробнее здесь: http://tools.android.com/recent/lintapicheck

person P.T.    schedule 28.06.2012
comment
К сожалению, инструменты lint довольно ненадежны и часто не работают или не обновляются должным образом. - person Timmmm; 01.11.2012

Несколько менее чистым/менее производительным методом было бы использование отражения для доступа к более новым API, которые вам нужны, вместо того, чтобы пытаться ссылаться на них напрямую с отложенной загрузкой. Это должно позволить вам скомпилировать более низкий уровень SDK.

person JesusFreke    schedule 04.10.2011
comment
Да, это хороший момент. Я должен был упомянуть об этом в своем вопросе. Недостатком является то, что я теряю любую проверку нового кода во время компиляции (поскольку все это разрешается во время выполнения), и это может стать очень уродливым быстро, если новые методы сложны. Но для моего текущего кода обходные пути, которые мне нужны, — это всего лишь пара констант и два простых вызова методов, так что это может быть полезно. - person P.T.; 04.10.2011
comment
Согласованный. Рефлексия - это определенно боль :) - person JesusFreke; 04.10.2011