Android целевой sdk vs устаревшие методы

Question

Этот код является базовым кодом для настройки вкладок в Android.

final ActionBar actionBar = getActionBar(); 
actionBar.setNavigationMode(ActionBar.NAVIGATION_MODE_TABS); 

Если вы пишете этот код в проекте, где targetSDK < 20 или compileSDK < 20 (я не знаю, в чем разница между версиями compileSDK и targetSDK), то это прекрасно.

Однако, если у вас есть compileSDK выше, например. 23, то Android Studio сообщит вам, что приведенный выше код устарел (и, более того, он удаляется из SDK, я думаю).

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

Вопросы:

1) Что произойдет, если я скомпилировать свой проект с версией compileSDK и targetSDK версии установлен в 20 (там, где нет проблем с бытием устаревшее) и попробуйте запустить его на Android с SDK 21 или 23, где эти функции , очевидно, удалены из SDK? Повреждено ли приложение или работает?

2) Что произойдет, если я решит настроить «высокий» SDK (например, 23)? Это есть, я оставлю «старый» код, упомянутый выше, и будет использовать «новый» код для вкладок, которые появились в SDK 23 или около того (что не было в нижнем SDK); то я попытаюсь запустить приложение на Android с более низким SDK, например. 20. Применяется ли приложение или работает?

редактировать:

Btw Теперь я начал проект с targetSDK и compileSDK 20 на Android с 22 уровня, и она работала.

Значит, единственное, что действительно имеет значение, это версия compileSDK? Даже не имеет значения на SDK-версии устройства, но это действительно важно для compileSDK?

Потому что, как я сказал о двух тестах - проект с плохим HIGH SDK запущен на устройстве с хорошим LOW SDK = сбой. Проект с хорошим низкоуровневым SDK запускается с делением с плохим HIGH SDK = не сбой.

Но логика, конечно же, говорит о том, что она также должна иметь значение на версии устройства Android (например, для доступа к некоторым новым функциям .. или действительно имеет значение только на compiledSDK или, по крайней мере, из вида back-functionallity)?

Нужны некоторые мнения экспертов по этому вопросу.

Answer 1

Однако, если у вас есть compileSDK выше, например, 23, то Android Studio скажет вам, что код выше устарел (и, кроме того, удален из SDK, я думаю).

No. getActionBar()is not deprecated. setNavigationMode() является deprecated but not removed.

Что произойдет, если я скомпилировать свой проект с версией compileSDK и targetSDK версии, например, 20 (где не проблема с устаревшим) и будет пытаться запустить его на Android с SDK, например, 21 или 23, где эти функции из SDK, очевидно, удален? Удастся ли приложение работать или работать?

Приложение должно работать нормально. «Устаревшее» означает «мы считаем, что есть лучшее решение, и мы предпочли бы, чтобы вы его использовали».

Что произойдет, если я решу цель «высокого» SDK, что означает, например, 23, я оставлю «старый» код, указанный выше, и будет использовать некоторые «новый» код для вкладок, которые появились, например, в SDK 23 или около того (это значит, что в нижнем SDK не существует), и я попробую запустить приложение на Android с более низким SDK, например, 20? Удастся ли приложение работать или работать?

Во-первых, я не знаю ни одного «нового» кода для вкладок, который появился, например, в SDK 23 ». В библиотеке поддержки дизайна есть единственная новая вкладка, которую я могу придумать, и она возвращается к уровню API 7.

Во-вторых, ваше приложение не должно компилироваться, если вы пытаетесь использовать что-то более новое, чем ваше minSdkVersion без надлежащих проверок (например, с использованием Build.VERSION.SDK_INT и обхода этого кода на старых устройствах).

В конце, если вы ссылаетесь на класс, метод, поле, интерфейс и т. Д., Которые не существуют на более раннем уровне API, ваше приложение будет разбиваться, если и когда этот код будет выполнен. Типичная ошибка VerifyError, хотя это немного зависит от характера того, что вы пытаетесь использовать, чего не существует.

Что касается вкладок, для вас доступно множество доступных вариантов. Большинство из них представлено в виде third-party libraries tied to ViewPager. С точки зрения Android SDK, вышеупомянутый TabLayout из библиотеки поддержки дизайна, FragmentTabHost и PagerTabStrip (хотя the latter has a bug in the 23.0.0 edition of the support-v4 library, apparently).

Answer 2

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

Answer 3

Here - некоторое объяснение на сборке/цель/minSDK.

1) Что произойдет, если я скомпилировать свой проект с версией compileSDK и targetSDK версии, например, 20 (где не проблема с устаревшим) и будет пытаться запустить его на Android с SDK, например, 21 или 23, где находятся эти функции из SDK явно удалены? Удастся ли приложение работать или работать?

Android Studio, вероятно, предупреждает вас, что API устарел, но не удален. Если он был удален, установка компиляции SDK на 23 должна разорвать вашу компиляцию. Ваше приложение должно работать нормально, даже если оно использует устаревший API, но вы должны обновить его, когда у вас есть время, поскольку оно больше не является рекомендуемым.

2) Что произойдет, если я решу цель «высокого» SDK, что означает, например, 23, я оставлю «старый» код, указанный выше, и будет использовать некоторые «новый» код для вкладок, которые например, в SDK 23 или около того (это означает, что не было в более низком SDK), и я попробую запустить приложение на Android с более низким SDK, например, 20? Удастся ли приложение работать или работать?

Когда вы используете API, который был введен в SDK 23, вам также нужно будет установить compileSDK на 23. Если вы установили minSDK на 22, вы сможете установить его на устройство, использующее SDK 22, однако при попытке использовать этот метод приложение будет сбой с NoSuchMethodError. Тем не менее, вы можете проверить работу SDK на устройстве (используйте Build.VERSION.SDK_INT) и не вызывать этот метод в этом случае.