Google has been way behind in terms of execution with their Android story, I keep hoping that Motorola Mobility will inject their execution DNA into Google rather than the other way round, only time will tell.
I think Google's software engineering team has mostly been doing a very good job evolving and refining the platform.
Unfortunately Google hasn't done very well corralling the various OEMs into getting their work out there into users' hands and I agree their execution needs to improve there, although I'm not sure specifically what they can do without pushing OEMs away from the platform altogether.
This means that if you are an OS vendor but not the system vendor, you have to do things (aka execute) which allow complete systems (hw + OS) to be brought to market. You have to define a HAL for example, and a way to evolve that HAL, and a way to probe what parts of the HAL need to be implemented in software because the hardware bits are missing. You need to provide a bullet proof schedule (which usually means prioritizing software availability over feature availability) at pre-defined times. You need to have a strong relationship with chipset and other silicon vendors to enable solid device support, which is at least backward compatible and ideally forward compatible as well. You need to be able to work with a hardware partner to get their stuff up and running, you need clear APIs that don't change and solid training materials to bring engineers up to speed. You need to create a series of test suites and compatibility suites to provide confidence on your vendors part that they are doing it right. And perhaps most importantly you should provide legal indemnification for your partners who use your software.
When you execute well, all those things are there. When you execute poorly there are parts missing, or parts that are confusing.
The result of poor execution is incompatibility flareups, your partners product shipments slip because they haven't had enough integration time, you screw some partners with a release they cannot ever run on their hardware, and your partners take punches in court for you over their decision to use your OS. That's painful.
I was working at Google when Android was released and while not part of that team, participated in the early development contests and worked on a 'loaner' G1 to test various things. That first release with T-mobile was when Google still felt that could release on open source (mostly) OS, and a reference implementation, and the rest of the world could just pick it up and go wild. (this is sometimes referred to as the 'throw it over the wall' strategy). Fortunately, this failed really hard, really fast as evidenced by the pretty sizable gap between the first Android phone and the second. But Google is nothing if not resilient. When I left in 2010 they were still struggling with the notion of 'software releases have timelines' kind of thing because all of Google's other properties just pushed out to their own hardware in their data centers which meant alpha was beta was release all wrapped in one. Not only that but major changes could occur between any step. Hardware partners really really don't like it when you make a major change between one release and the next.
Much of the early thrashing in the Android market was due to inexperience on Google's part. The fact that Jelly Bean has been released and Ice Cream Sandwich is hardly anywhere is, in my opinion, and artifact of this learning process.
Unfortunately Google hasn't done very well corralling the various OEMs into getting their work out there into users' hands and I agree their execution needs to improve there, although I'm not sure specifically what they can do without pushing OEMs away from the platform altogether.