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

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


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 22buildToolsVersion '22.0.1'targetSdkVersion 22compile 'com.android.support:support-v4:22.0.0'compile 'com.android.support:appcompat-v7:22.0.0' // includes support-v4compile '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?