>And 57% of our demographics are on 5.0 or newer, with 19+ covering over 80% of users actually using the app
You must have a very unusual user base! We have 11.6% using 5.0 or newer, and apps in our category (Communications) have average of 16% using 5.0+. Our largest user base is for 4.4, at 49%.
Sometimes, Google releases some really cool new APIs or a new design language, and when that happens there's an opportunity for apps to show up that disregard all the other legacy stuff and are built specifically around those new APIs or with the new design language.
That's how they manage to capture a large percentage of the few users who have the latest version of Android. That's how the app builds a strong brand for the "new stuff", and then can usually maintain that brand as all devices start being replaced by devices that support those APIs.
Other time, they don't improve that much on their app, and someone else comes from behind and makes a better alternative with the new APIs, though.
However, as discussed below, the amount of users in the world with Google Play ≠ active app users. If you collect stats on your app's actual usage, I think you'd find that they are much more up-to-date than the Developer Dashboard stats would have you believe.
There are many useful libraries to get a close-enough Material experience working on the older devices. And I am not talking about the official support library, which should be at least on a par of many MIT licensed Android extensions out in the marketplace.
There's more to the Android APIs than UI stuff, which is the majority of what's covered by workarounds like the Compatibility Library. This is a very real problem with Android development -- "hey look at all this cool stuff we've added and you'll be able to actually make use of in two years!"
Sure we are using them, but for example the design support library is not very satisfactory.
The whole approach of backwards compatibility has not worked out well. Google's alternative approach for the last two years have been the Play Services, which are now a behemoth requiring multidex in your app, when the majority just use the API client libraries from them.
What I generally recommend for mass market apps is to code for the latest or near-latest API level, depending on features that are useful in new API levels, and to simultaneously or soon after back-port a version using the compatibility libraries for older devices. Note that you can target higher API levels than phones in the the current sweet-spot have by testing for API availability (I.e. use forward compatibility, not just back-compatibility). Depending on the shape of the market, this can be a better alternative for some Android versions than using the compatibility libraries.
This puts future development on two, or, for very mature products, on three tracks where you have a code-base for up-to-date devices, and another for somewhat training edge devices, and maybe a third for old devices. Very often new phones have an outsize value to app developers because that's where the new phone customers, who buy apps at a higher rate than people with two-year-old phones.
YMMV. If you don't have tens of thousands of users, you aren't going to do it that way. Or, if you app has no need for the latest features, you won't do it that way.
If you just need some API client libraries then you can compile most modules separately[1] e.g. Ads, Analytics, GCM, etc. This makes Play Services actually usable without multidexing.
Well if you write a hybrid app in polymer you can use material for everybody and share out a copy of your app on the chromeos app store and ios off the same code.
Which means that what I learned at I/O 2013 can finally be put to good use!
The sad part is that I decided to skip looking enthusiastically under the hood of M, because I won't be able to use it anyway for quite some time.