[georgemcbay]

There are some pretty gaping holes in the compatibility library. Luckily the most important of these (ActionBar support) is covered by a great 3rd party library (ActionBarSherlock).

If anything, I think the existence of the compatibility library and ABS show that Google is dropping the ball a bit on the core Android framework. Why even have these be extra (and in one case 3rd party) libraries? Where possible why not just write the core SDK in a way such that it can fall back to 1.6 or 2.2 without having to worry about fiddling with compatibility libraries?

[koko775]

Precisely. Furthermore, the older platforms have major problems with stream poisoning for HTTP requests, include an incomplete beta version of Apache's HTTP classes, have old SQLite libraries which don't support upserts, and so on.

[erd]

The SDK is a collection of stubs (none of the methods have an implementation), which is why the compatibility library exists as an add-on. The library does fall back to the native implementation on versions of the OS that support it for whatever you're using the library for.

[bad_user]

But Android was designed to allow fallback to older versions. Can you think of a case where you cannot? If anything the compatibility libraries stand as proof.

[georgemcbay]

My point was the fallback should be more seamless (and shouldn't rely on 3rd party FOSS libraries, which it sometimes does).

Example 1: Fragments.

Introduced with Honeycomb. Android supports these via the "support" library back to 1.6, but the APIs you're using are slightly different (eg. getFragmentManager() vs getSupportFragmentManager()) and the classes you use live in different packages (eg. android.app.Fragment vs android.support.v4.app.Fragment). If the support library were more tightly integrated with the mainline SDK, you wouldn't have to worry about all these splits, but it isn't so you do. You have to decide up front if you want to code to the mainline SDK classes or the support versions and then this gets worse when you implement other classes which use Fragments in a library meant for other developers -- should your classes assume those developer's Fragments derive from android.support.v4.app.Fragment or android.app.Fragment? It gets really messy really fast.

Example 2: ActionBar

Not even supported via the regular support library, you have to go get ActionBarSherlock which itself extends the Android support library. Kudos to Jake Wharton on this great library, but why didn't Google just make their ActionBar backward compatible to earlier versions out of the gate? It is clearly possible to do this as ABS does it.

I'm sure there is some specific reason the Android devs could give for why the support lib and the main SDK are so increasingly fragmented and it may have a very good legacy reason for existing, but having them work this way is harmful in the long run, IMO. Maintaining this split makes things much harder for devs just trying to get into Android who are very confused by all the different decisions they have to make just to get basic app functionality working across a decent cross-section of Android devices.

Granted, I'm not saying any of this makes Android development impossible or akin to rocket science, but it does make it needlessly complex which is bad given that Android is already seen as a bit of a red-headed-stepchild to iOS development even despite the overall marketshare advantage Android has.

[cageface]

Google does have a backwards-compatible implementation of the action bar planned but they haven't given a release date. I agree that it shouldn't fall on the Foss community to fill this gap.

[vibrunazo]

If they changed how older APIs behave on devices and that were not expecting it. Wouldn't that, by definition, break backward compatibility?