Почему AOSP добавляет новые API для поддержки библиотек, не добавляя их в SDK?

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

Пример:

FragmentTabHost API доступен только через android.support.v4.app.FragmentTabHost. Это нормально в большинстве случаев, но если вы хотите использовать разложение фрагментов и PreferenceFragment вместе, вы мертвы в водах - nesting требует, чтобы вы переключились на android.support.v4.app.Fragment (для поддержки ниже 4.2), но в этой поддержке lib нет реализации PreferenceFragment. Как следствие, вы либо реализуете пользовательские обходные пути, либо используете сторонние библиотеки, которые уже реализовали их (см. этот вопрос)

Изменить: как указал @eugen в своем ответе, я сам ссылался на FragmentTabHost из support-v13, который поддерживает собственные фрагменты. Однако эта информация не меняет общий вопрос. На самом деле, если бы я использовал этот API с вложением фрагментов, мое приложение не запускалось бы на ~ 30% устройств сегодня (встроенные фрагменты поддерживают вложенность с 4.2 и далее).

Пример:

Еще одна проблема, с которой я столкнулся сегодня (и потратил слишком много времени), - это ActionBarDrawerToggle, доступный через android.support.v7.app.ActionBarDrawerToggle. Я хотел использовать эту функциональность, поэтому я добавил все зависимости com.android.support:appcompat-v7:21.0.+ к зависимостям проекта. Я догадался, что это будет сделано, но я ошибся - мое приложение не скомпилировало (недостающие ресурсы, на которые ссылается библиотека поддержки). Попробовав несколько трюков из Интернета, я нашел этот вопрос, который, наконец, предоставил решение. Короче: библиотека поддержки v7 имеет зависимость от SDK, поэтому мне пришлось определить compileSdkVersion 21.

Последствия:

Теперь я говорю себе: FragmentTabHost еще не добавлен ни в одну версию SDK, а это означает, что даже через 4-5 лет разработчики будут продолжать использовать поддержку-v4 lib для обеспечения этой функциональности (потому что даже если этот API добавляется сегодня, потребуется несколько лет, прежде чем вы сможете смело предположить, что все целевые устройства поддерживают его изначально), правильно? Тот же аргумент применяется к android.support.v4.widget.DrawerLayout и другим API, представленным только в библиотеках поддержки.

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

Вопрос:

Почему Google хочет хранить эти библиотеки навсегда? Не будет ли лучше для всех, если бы все новые API были добавлены в SDK параллельно с библиотеками совместимости, чтобы библиотеки совместимости могли возрасти и "уйти в отставку" в какой-то момент?

Изменить: после ответа @eugen. Я теперь озадачен еще больше - некоторые API "развиваются" с новыми библиотеками поддержки, но не попадают в основной SDK (например, FragmentTabHost, который развился из поддержки-v4 в поддержку-v7), В чем причина не добавления их в SDK?

Ответ 1

API FragmentTabHost доступен только через android.support.v4.app.FragmentTabHost.

Неправильно. Приведенная вами ссылка приводит к android.support.v13.app.FragmentTabHost, который (в отличие от android.support.v4.app.FragmentTabHost) работает с native Fragment, но делает API, представленный выше API 13 доступным с API 13.

Короче: библиотека поддержки v7 имеет зависимость от SDK, поэтому мне пришлось определить compileSdkVersion 21.

Конечно, для версии 21 библиотеки нужна версия 21 инструментов и версия 21 SDK. Всегда используйте соответствующие версии инструментов сборки, компилируйте SDK и библиотеки поддержки!

На сегодняшний день эти значения рекомендуются:

compileSdkVersion 22
buildToolsVersion '22.0.1'

targetSdkVersion 22

compile 'com.android.support:support-v4:22.0.0'
compile 'com.android.support:appcompat-v7:22.0.0' // includes support-v4
compile 'com.android.support:support-v13:22.0.0' // includes support-v4

Теперь я говорю себе: FragmentTabHost еще не добавлен ни в одну версию SDK, а это означает, что даже через 4-5 лет разработчики будут продолжать использовать поддержку-v4 lib для обеспечения этой функциональности (потому что даже если этот API добавляется сегодня, потребуется несколько лет, прежде чем вы сможете смело предположить, что все целевые устройства поддерживают его изначально), правильно?

Это означает, что если вы реализуете его с помощью библиотеки support-v13, вам не о чем беспокоиться. Он будет работать до API 13.

Ознакомьтесь с разницей между support-v4 и support-v13 выше.

Почему Google хочет хранить эти библиотеки навсегда?

Потому что вы, скорее всего, захотите поддержать старые платформы. Это означает, что вам нужна библиотека поддержки.

Даже теперь вы используете ActionBarActivity из appcompat-v7 (который изначально предназначался для резервного копирования панели действий в API 7) с помощью minSdkVersion 14, потому что вы хотите, чтобы этот проект материального дизайна. Это также означает, что вы застряли с фрагментами поддержки, потому что ActionBarActivity использует их.

Не будет ли лучше для всех, если бы все новые API были добавлены в SDK параллельно с библиотеками совместимости, чтобы библиотеки совместимости могли возрасти и "уйти в отставку" в какой-то момент?

Поддержка возраста библиотек. Возможно, вы заметили, что recyclerview-v7 (и другие последние библиотеки для Android) доступны с API 7, а не API 4. И вы также заметили, что RecyclerView не входит в собственный SDK. Почему вы добавили его в родной SDK, чтобы он был доступен только на новейшей платформе, когда вы можете поместить библиотеку поддержки, которая сделает ее доступной для всех?