Я хотел знать последствия наличия targetSDK > buildTarget.
Недавно я заметил, что если я сохраняю buildTarget=16 и targetSDK=17 вкладки на моем планшете (работает 4.1.1, уровень API 16) перемещается в центр actionBar. Я не смог рационализировать поведение. Может кто-то пролил свет на то, почему это произошло?
Хороший вопрос! У меня было подобное поведение некоторое время назад, когда buildTarget и targetSDK отличались описанным образом. Мне потребовалось некоторое время, чтобы понять это, но я попытаюсь обобщить свое понимание.
Вы должны различать три важных значения:
minSdkVersion:
Это самая низкая доступная версия, на которой приложение будет (или должно!) работать. При установке .apk на Android значение будет проверяться, и если версия Android, на которой вы работаете, ниже указанной версии, она не будет установлена.
buildTarget:
Что SDK, на котором будет скомпилировано приложение .apk(и Eclipse тоже будет целевым значением для проверки ошибок компиляции). Если buildTarget выше, чем minSdkVersion, вы сможете установить приложение, даже если ваша версия Android не поддерживает все методы. По умолчанию эта версия установлена на последнюю версию Android, доступную в вашем SDK. Вы можете создать приложение для поддержки более старых версий, но установка цели сборки на последнюю версию позволяет вам включать новые функции и оптимизировать ваше приложение для отличного использования на последних устройствах.
Вам нужно проверить, присутствуют ли во время выполнения методы, запущенные на более низком уровне API, в противном случае приложение может сработать!
targetSdkVersion:
targetSdkVersion указывает, на какой платформе SDK ваше приложение должно работать нормально. Итак, если вы протестировали против API 17, вы можете добавить API 17 как targetSdkVersion. Если вы используете версию Android > targetSdkVersion, система Android войдет в какой-то режим прямой совместимости, чтобы обеспечить поддержку приложения. Это поведение совместимости будет введено, чтобы убедиться, что ваше приложение продолжает работать так, как вы ожидаете, так как могут быть некоторые изменения в поведении между уровнями API никогда (вот некоторые из наиболее важных изменений). Таким образом, любое приложение, разработанное для более низкого уровня API, сможет работать на более высокой версии, поскольку старое поведение (например, устаревшие значения) может быть "смоделировано" в режиме совместимости.
Например:
Если вы установите targetSdkVersion в HONEYCOMB (API 11), тема по умолчанию будет изменена на Theme_Holo (темный голографический интерфейс). Установка targetSdkVersion на более низкое значение повлияет на то, что система останется на тему освещения по умолчанию, независимо от того, какой API сборки вы будете использовать!
В вашем случае не должно быть много заметных изменений между API 16 и 17, которые должны влиять на изменение дизайна, но я думаю, что более высокий targetSdkVersion будет влиять на некоторые дополнительные изменения во время компиляции ( например, включая дополнительные классы, темы, значения,...), что повлияет на другое поведение, как в примере выше.
Надеюсь, это немного помогло вам разобраться в странном поведении. Ниже приведена дополнительная информация для чтения в документации разработчика Android.
PS: Есть какой-то вид вперед-назад-ад: Android-система обратно совместима, так что обеспечивается прямая совместимость приложений Android. Это означает: если вы обновляете версию Android через OTA, например, все старые приложения должны оставаться в рабочем состоянии (поэтому они будут оставаться совместимыми в будущем).
Цель сборки - для разработки приложений, целевой SDK - для совместимости приложений.
цель сборки указывает, к какому API вы имеете доступ при реализации приложения. Как если бы вы установили тег сборки на API-интерфейс API Android 10, то, что касается вашего кода, нет такой вещи, как ActionBar. API, который вы используете во время разработки, - это просто заглушка для Android, поэтому его нужно эмулировать или запускать на реальном устройстве. Следовательно, цель сборки определяет (для компилятора и вашего IDE) интерфейс Android, который вы используете. После компиляции не должно быть разницы в зависимости от цели сборки (система Android не видит цель сборки, это флаг времени компиляции). Это строгий контракт между вами и компилятором android (и вашей IDE), который определяет, какие компоненты Android вы можете использовать в своем приложении, так как вы получите ошибки компиляции, если попытаетесь использовать что-то, что находится за пределами установленной версии Android как ваша цель сборки.
целевой SDK - это контракт, который вы подписываете в системе Android, гарантируя, что ваше приложение будет готово работать от минимального SDK до целевого SDK (эффективный максимальный SDK, так как максимальную настройку SDK следует избегать). Я считаю, что есть несколько вещей, которые не обеспечивают передовой совместимости, например, некоторые изменения безопасности (возможно, изменения происходят из-за разработки приложений и являются общесистемными). Этот договор является соглашением, которое означает, что вы выполнили меры, чтобы убедиться, что ваше приложение обрабатывает любые изменения в API Android в этом диапазоне, так что оно обеспечивает поведение, которое вы ожидаете во всех ситуациях. Другой конец контракта - из системы Android, он согласен использовать версию Android, которая не превышает целевой SDK, даже если на устройстве с более высокой версией Android (это исключает несколько изменений, о которых я упоминал ранее).
Примечание о совместимости с прямой версией подразумевает, что ваша цель сборки всегда должна соответствовать вашему целевому SDK. Вы говорите, что вы протестировали свое приложение для запуска в своем целевом SDK, поэтому зачем строить его на более низком уровне API?
Пример реальной жизни целевого и целевого SDK в действии: ActionBarSherlock обеспечивает обратную совместимость ActionBar. Вот цитаты из требований к использованию библиотеки в настоящее время.
Сама библиотека должна быть построена против Android 4.0 (API уровня 14). Ваш проект должен быть построен с использованием последней версии SDK, насколько это возможно, если это 4.0 или новее.
Требуется уровень API-интерфейса Targeting 11 или более поздний, поскольку это приведет к тому, что Android автоматически добавит собственную панель действий при работе на новых устройствах. Поскольку вы будете компилировать против новых API, но ваше приложение, скорее всего, будет запущено на устройствах со старыми версиями Android, следует проявлять особую осторожность, чтобы либо не использовать, ни правильно проверять и не вызывать любые методы, которые были введены после минимальной версии SDK.
Первый абзац показывает, что требуется цель сборки, которая содержит API ActionBar 4.0, поскольку библиотека использует его и не может скомпилировать без него. Второй абзац показывает, что требуется целевой SDK, который содержит 3.0 ActionBar API, поскольку библиотека использует собственный ActionBar на таких устройствах, но система Android не будет предоставлять ActionBar, если ваш целевой SDK ниже чем 3.0, поскольку это говорит ему не использовать ничего более нового, чем ваша цель (например, 3.0 ActionBar).
Некоторые ссылки: