Why does AOSP add new APIs to support libraries without adding them to SDK?

Question

I've been developing for Android for a few months now, and this question arises again and again: what is the motivation behind addition of completely new features (APIs) to support libraries without them being available in the standard SDK?

Example:

FragmentTabHost API is available only through android.support.v4.app.FragmentTabHost. It is fine most of the time, but if you want to use fragments nesting and PreferenceFragment together, you're dead in the waters - nesting requires you to switch to android.support.v4.app.Fragment (for supporting below 4.2), but there is no implementation of PreferenceFragment in this support lib. As a consequence you either implement custom workarounds, or use third party libraries that have already implemented them (see this question)

Edit: as pointed out by @eugen in his answer, I myself referenced FragmentTabHost from support-v13, which supports native Fragments. However, this information does not change the overall question. In fact, if I would've used this API with fragments nesting, my app wouldn't run on ~30% of devices today (native fragments support nesting from 4.2 onwards).

Example:

Another issue that I encountered today (and wasted too much time on) is with ActionBarDrawerToggle available through android.support.v7.app.ActionBarDrawerToggle. I wanted to use this functionality, therefore I added the entire com.android.support:appcompat-v7:21.0.+ to project's dependencies. I guessed that this will do, but I was wrong - my app did not compile (missing resources referenced by the support library). After trying few tricks from the web, I found this question which finally provided the solution. In short: v7 support library has dependency on SDK, therefore I had to define compileSdkVersion 21.

Consequences:

Now, I tell myself: FragmentTabHost haven't been added to any SDK version yet, which implies that even 4-5 years from now developers will continue to use support-v4 lib for providing this functionality (because even if this API is added today, it will take years before you could safely assume that all target devices support it natively), right? The same argument applies to android.support.v4.widget.DrawerLayout and other APIs present only in support libraries.

If developers bound to use support libraries for years, this also imply that they are bound to experience the above inconsistency/dependency issues long after these issues could have already been resolved, right?

Question:

Why would Google want to keep these libraries forever? Won't it be better for everybody if all the new APIs were added to SDK in parallel to compatibility libs, such that compatibility libraries could age and "retire" at some point?

Edit: following @eugen's answer I'm now puzzled even more - some APIs "evolve" with newer support libs, but do not make it into main SDK (like FragmentTabHost, which evolved from support-v4 to support-v7). What is the reason for not adding them to SDK?

Answer 1

FragmentTabHost API is available only through android.support.v4.app.FragmentTabHost.

Incorrect. The link you provided leads to android.support.v13.app.FragmentTabHost which (as opposed to android.support.v4.app.FragmentTabHost) works with native Fragments but makes APIs introduced above API 13 available since API 13.

In short: v7 support library has dependency on SDK, therefore I had to define compileSdkVersion 21.

Of course the version 21 of the library needs version 21 of tools and version 21 of SDK. Always use corresponding versions of build tools, compile SDK and support libraries!

As of today these values are recommended:

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

Now, I tell myself: FragmentTabHost haven't been added to any SDK version yet, which implies that even 4-5 years from now developers will continue to use support-v4 lib for providing this functionality (because even if this API is added today, it will take years before you could safely assume that all target devices support it natively), right?

Which means that if you implement it using the support-v13 library, you have nothing to worry about. It's going to work as far as API 13.

Read about the difference between support-v4 and support-v13 above.

Why would Google want to keep these libraries forever?

Because you'll most likely want to support older platforms. Which means you need a support library.

Even now you use ActionBarActivity from appcompat-v7 (which was originally intended to backport action bar to API 7) with minSdkVersion 14 because you want that material design backport. This also means you're stuck with support fragments because ActionBarActivity is using them.

Won't it be better for everybody if all the new APIs were added to SDK in parallel to compatibility libs, such that compatibility libraries could age and "resign" at some point?

Support libraries age. You may have noticed that recyclerview-v7 (and other recent android libraries) is available since API 7 and not API 4. And you may also have noticed that RecyclerView is not in the native SDK. Why would you add it to a native SDK making it available only to the newest platform when you can put out a support library making it available for everyone?