1) Testing costs to developers are super high
Developers have an insanely hard time testing their apps across different versions and vendors. The Android emulator is buggy (HTML5 videos do not work in WebViews) and slow (I’ve never been able to run x86 emulation on my Mac). These problems seem minor when compared to the hell of trying to test an app across vendors. The emulator completely ignores the biggest problem in Android fragmentation: it does not reproduce vendor specific quirks.
2) Old Android versions are still supported.
Android v11 (Honeycomb) introduced a TON of new APIs and improvements under the hood. Sadly, you can’t use them unless you’re willing to ignore 1/3 of your potential market.
How has this problem been dealt with in the browser world? The solution was led by Google, which famously deprecated IE6 in 2009, putting downward pressure on consumers and enterprises to upgrade their browsers. This eventually empowered developers, like those of Bootstrap, to ignore IE6 entirely when developing next generation frameworks.
The same hasn’t happened to Android so far. Anecdotally, I haven’t seen a consumer choose an Android phone because “my apps will work on it.” Similarly, no major app has publicly dropped support for a certain variation of Android.
3) Google is slow
Google has been releasing “support libraries” which emulate newer APIs in older versions of Android. These are very welcome, but are released at a very slow pace. It took the “action bar” (the bar at the top of newer Android apps) two years to gain backwards compatibility past Honeycomb.
4) Little trust in open source solutions
The points above make me very wary of existing open source solutions that try address fragmentation. How do I know that a given project has coverage over the giant matrix of Android versions and devices? No one library, other than the slowly released “support libraries,” have enough critical mass or industry support to obtain the resources necessary to properly test across devices.