CQM,
Understand that I agree with Commonswares and nearly everything that stated in the supplied answer. However, the question seems to imply that there is an issue that you are having (either in comprehension or conception) and want to find/develop a more adequate solution for your needs.
Addressing the question and the responses you are probably going to receive:
I believe Commonswares valid criticism is due to the fact that you do not state why or how the provided platform object is unsatisfactory, nor do you state why or when you believe that Google has said that said object is unreliable. If you would like better feedback, edit your question appropriately to communicate this and you'll have fewer problems here.
Further, as explained further below, you imply that this is a problem with the Android platform (in fact, almost directly state it) and it is not. There are too many considerations in the broad scope of web browsing to be completely addressed by a simple control such as the WebView. Microsoft faced the same issue with their embedded IE COM Object back in the 90s. Its a big issue that doesn't belong to any one group.
Addressing the implied question:
The WebView object is basically a mini-browser utilizing highly flexible rendering code based on entirely different parameters from that of a dedicated browser. This includes everything from simple rendering, to even interactible (sp?) objects such as the links that such a page would employ. This process is very difficult to (for lack of a better word) to miniaturize in such a way that capability is uniform for embedding into a variety of apps that have may a different layout structure and parameters every time. Heck, such engines are hard to program uniformly even with a dedicated browsing engine, leading to a lot of the differences between the current major browsers as a whole.
As such, the WebView is not meant to provide the full functionality of a dedicated browser, but the most useful aspects of displaying web delivered content within an application that often does other things. This is especially true when you consider the security implications of adding Javascript functionality or client-based processing delivered from said content. Add to that, each device has the potential to have a different rendering engine or different version of the same rendering engine, much the same way that different devices have different capabilities utilizing SQLite (i.e. Foreign Key support).
As such, the WebView is provided as a solution to display web delivered content without guarantee as to its extensibility or usability unless you use it purely to view (and possibly react) trusted and standards conformant HTML code. Once you get into the actual practices of real world websites, you realize that HTML was made so flexibly specifically because each standard as adhered to at different levels by different developers. Since the primary credo of HTML is that it work (show content), despite potential ambiguities, the issue of developing a fully comprehensive app-embedded object oriented solution becomes even harder to develop.
... where other mobile devices - like an iphone - will run it fine
This depends on the content. Also the development philosophy for the Apple devices is entirely different from that of Android. Apple has only a handful of devices, so they can guarantee uniformity across their devices and choose which and when to add additional features. For instance, the first iPhone didn't have native support for Flash. Based on the implications of your question, I believe this fails the "comprehensive" test.
Android, in contrast, has a much wider repertoire of devices. The code for Android is adjusted and altered by the manufacturers of these devices to allow them to make more adequate supportable solutions for their specific device needs. Google cannot guarantee that any given device will keep any or all of its code the same in any way. This creates further limitations but creates other very awesome freedoms.
... they both use webkit.
Chrome and Safari both use webkit, as well. Many developers have been plagued by the even minute differences in the way that they both utilize it differently.
... outside of an app, the actual android browser runs just fine.
This is addressed above.
Is there a way to really address android's problem, on a lower level?
Again, this is not android's problem. If you are having a specific issue with the current implementation, you are free to code a separate solution. Further, web content was made to be viewed in a browser and that is provided. The best practice is to define what you need it to do specifically. Do you need the WebView to view any web page? Or just yours? What are your issues with its current rendering? Do you require client-side scripting?
Every tool is made with particular needs in mind. This is even true of the so-called "better" listviews. Those views were made to address specific needs that might be needed by more than one developer. In the world of programming (especially OOP), there is really very little such thing as comprehensive. If there was, we wouldn't have to extend our objects in the first place. When looking at such a tool, consider what need it was specifically trying to address.
Has anyone made a more comprehensive web object for Android?
Yes. They are normally manifested in the other dedicated browsers that you can download to your device. As to whether or not they are accessible: personally, I have no idea and am not inclined to look.
Final Statement
The issue you have raised was really not specific enough to provide a true solution. It also seemed to take an antagonistic stance, due to poor word choice. If your issue was not resolved by either CommonsWare's answer or my own, consider editing your question to add our more specific needs. That said, I hope both of our answers were able to provide some insight for you.
Hope this helps,
FuzzicalLogic
