Anecdotally, this is also my experience with using some of the lesser known frameworks in the Android ecosystem - nothing is documented properly or the documentation is years out of date and/or uses long deprecated methods, significant bugs remain open for years without attention, requiring time-consuming workarounds, and everyone just puts up with it, because that's the way things have always been.
An example of problematic documentation is Volley, which is a brilliant and totally needed framework and documentation that exists for it is a 45 minute presentation and a handful of StackOverflow posts.
While I'm not arguing against your overall point, your example is not a good one. Volley was unnecessary. It only got attention because Google did it but the community was already on top of the issue. From shipping their own, newer Apache Client libs, through koush's ion and picasso, to Square's okhttp, networking on Android is full of good libraries to use. Volley didn't anything dramatic to this and, judging by the amount of attention it has received, it was someone's side project.
I take your point, and that's exactly why I'm not using it in production, but it doesn't seem like Google should have drawn as much attention as they did to it, running a session on it within Google I/O, if it was just intended to be a side-project and not for widespread consumption.
I guess I'm just coming at this with a WWDC mentality, where a presentation would be run only on a completely production-ready and documented framework, and perhaps I/O does things differently.
An example of problematic documentation is Volley, which is a brilliant and totally needed framework and documentation that exists for it is a 45 minute presentation and a handful of StackOverflow posts.