By default, the framework provides basic support for Views that wish to internally scroll their content and draw scrollbars. For instance, you can scrollTo(int, int)). While this works perfectly with ScrollView it doesn’t with ListView nor WebView nor my beloved MapView. Another example of this confusion is the ViewTreeObserver.OnScrollListener that works perfectly on all kinds of scrollable content but doesn’t provide you with the container that scrolled. Once again, Google Maps Android API v2 MapView is an exception and won’t fire the callback when being scrolled or zoomed. Finally, there are some inconsistencies. For instance, AbsListView.OnScrollListener lets you listen to AbsListView scrolls but there is no View.OnScrollListener counterpart. If you want to listen to scrolls at the View level, you’ll need to override the onScrollChanged(int, int, int, int) method.
Put simply, Android offers several scroll containers, but no consistent way to formalize scrolling and notify the developer. Even if you can determine if a View is a scroll container by using View.setScrollContainer(boolean)1, there is absolutely no way to develop a unified algorithm that would scroll your container to its top with a single call to View.scrollTo(0, 0).
On the other side, iOS simplified the problem by making sure all scrollable containers are unified via a UIScrollView - the base class containing the “scrolling” and “scroll-to-top” implementation. The framework offers a bunch of scrollable containers: UITextView, UITableView, UIWebView, MKMapView, etc. that all inherit or encapsulate a UIScrollView. By factorizing the scrolling behavior, iOS ensure that the scrolling physics (velocity, friction, bouncing, etc.) are consistent throughout iOS apps and guarantee all scrollable content can be scrolled back to the top.
It appears that not being able to implement a global scroll-to-top gesture is not really a problem. Indeed, most issues can be solved at the application level using components that are generally way more specific to the data displayed by your app. It obviously requires more work than relying on the default system’s behavior and doesn’t provide a consistent and coherent gesture throughout the platform. But, why would I need a scroll-to-top gesture in the Contacts iOS app if it also offers an index on the right?
Ultimately, the scroll content issue Android suffers from at the API level has no impact on the UI. If you are complaining about the feature missing, you should probably notify the developer his/her app needs some enhancements. The framework includes out-of-the-box workarounds and components that prevent the user from flinging for eternity trying to reach the top of your scrollable container: