Take Windows for example, roughly we have the following revisions in common use today:
Windows XP RTM, SP1, SP2, SP3
Windows XP x64 RTM, SP1, SP2
Vista x86/x64 RTM, SP1, SP2
Windows 7 x86/x64 RTM, SP1
Most software released in the past 10 years will run on ALL these OSes out-of-the-box. Because the Win32 platform itself is 'fixed'. New functionality is added, bugs are fixed, but there are rarely any changes that break current or even legacy software.
Eg, you cannot link 2.xx code to 3.xx or 4.xx code. This makes it a lot harder to distribute libraries in binary form.
Compare that to Microsoft Visual Studio, where Visual Studio 2010 can still use libraries built with Visual Studio 6 from 1998 (and perhaps even earlier).
The REAL problem however is that the libraries themselves are not a 'fixed' target. The interfaces change (both at binary and function level), breaking compatibility with older or newer versions of software.
This is different on Android, or Windows for that matter. If you develop against a certain version of a library, you don't have to worry about newer versions breaking your code, because they will be backward compatible with the version against which you developed your software.
Which is why software developed for Windows XP still works in XP x64, Vista, Win7 and Win8. Or why software developed for Android 1.x still runs on 2.x, 3x and 4x.
This shouldn't be a problem in the first place, since you should be able to make a single package that works on all distros. But that is exactly the problem we're pointing out here: there is no easy way to do this, because too many parts in the chain vary.
This is different from linux distros.
For example, OpenGL ES 2.0 does not have any fixedfunction pipeline anymore. It can only use shaders. And these shaders use a slightly different dialect of GLSL, with keywords that regular OpenGL does not support (google around to see how people try to find solutions with #defines and such to make the same code compile on both OpenGL and OpenGL ES).