We had a couple people at CTIA last week -- people whose words carry weight -- tell us off the record that the next major version of Android would take big strides toward stopping the ugly trend toward severe fragmentation that has plagued the platform for much of this and last year. You know, the kind of fragmentation that has already left users running not one, not two, not three, but four distinct versions of the little green guy (1.5, 1.6, 2.0, and 2.1) depending on a seemingly arbitrary formula of hardware, carrier, region, software customization, and manufacturers' ability to push updates in a timely fashion. Put simply, Google's been iterating the core far faster than most of its partners have been able to keep up.

Thing is, in light of our CTIA conversations, we didn't have an idea of how Google planned on fixing this -- until now. We've been given reason to believe that the company will start by decoupling many of Android's standard applications and components from the platform's core and making them downloadable and updatable through the Market, much the same as they've already done with Maps. In all likelihood, this process will take place over two major Android versions, starting with Froyo and continuing through Gingerbread. Notice that we said apps and components, meaning that some core elements of Android -- input methods, for instance -- should get this treatment. This way, just because Google rolls out an awesome new browser doesn't mean you need to wait for HTC, Samsung, or whomever made your phone to roll it into a firmware update, and for your carrier to approve it -- almost all of the juicy user-facing stuff will happen through the Market.

The second part of this doubled-edged attack on platform fragmentation comes from a simple reality: we're hearing that Google may be nearing the end of its breakneck development pace on Android's core and shifting attention to apps and features. By the time we get to Froyo, the underlying platform -- and the API that devs need to target -- will be reaching legitimate maturity for the first time, which means we should have far fewer tasty treat-themed code names to worry about over the course of an average year. We like awesome new software as much as the next guy, but Google's been moving so fast lately that they've created a near constant culture of obsolescence anxiety among the hardcore user base -- and in turn, that leads to paralysis at the sales counter.

How much of this strategy actually materializes -- and how effective it is at changing the direction of the platform at large -- remains to be seen, but it sounds like a promising turn of events. Considering it's been a solid five months since the Eclair SDK premiered, that's an eternity in Google years; time to shake things up a bit, we reckon.