How to deal with Android fragmentation: closed source?

How to deal with Android fragmentation: closed source?

Summary: Could Google take a leaf from Microsoft's book and rein in the handset manufacturers by taking closer control over Android - and closing the source?The Android operating system itself is open source, but the Google apps on Android aren't - and Google already places other conditions on Android OEMs.

SHARE:
TOPICS: Windows
10

Could Google take a leaf from Microsoft's book and rein in the handset manufacturers by taking closer control over Android - and closing the source?

The Android operating system itself is open source, but the Google apps on Android aren't - and Google already places other conditions on Android OEMs. If they want the Android Marketplace on phones, they have to use Google's location services; if they want Honeycomb, they have to remove physical buttons from their tablets. But if they don't, they're free to choose any version of Android, to offer updates or to leave users stranded on old versions, to add a third-party marketplace or their own skin to the home screen. Not only does that give you an unpredictable experience with any Android phone you pick up, it makes it harder for Android developers - including Google itself and key partners like Adobe - to create apps that will run on every Android device. For example, fixes to some embarrassing bugs - like sending text messages to the wrong person or not syncing email from the latest version of Microsoft Exchange - are only available on Google's own Nexus handsets so far.

Oh, and manufacturers can take Android - and strip Google Search out of it, which is where Google makes money from Android. Verizon making Bing the default search tool on a handful of phones probably isn't too painful for Google; Chinese manufacturers replacing Google with Baidu is worse news.

Fragmentation isn't the Android-killer some mobile rivals paint it as, but it is a major issue. Even the Google TV team has fragmented Android (Google TV is based on a customised version of Android 2.1, but with the Chrome browser rather than the Android browser and we've heard rumours of spirited discussions about the platform involving both teams and their hardware partners).

Closing the source and having more say over what handset partners can do would let Google avoid losing mobile search share, but the rumour we've heard says the Android team want to close the source to address the fragmentation issue, perhaps forcing updates the way Microsoft has promised to do (although it seems to have run into delays actually delivering on that ). It wouldn't start charging for Android or changing its stance on patent indemnification; it would just take back a lot more control.

Some handset makers that Google would like to attract (like, say, Nokia) are put off by the prospect of entering a market for Android handsets that look remarkably like commodities. Interestingly, when Andy Rubin claims that Android isn't commoditised, he doesn't point at the HTC Sense user interface (a good user experience that's evolved significantly from its Windows Mobile beginnings) or any other user interface improvements; his usual example is Sony Ericsson’s Xperia Play PlayStation-inspired gaming phone. That's a combination of hardware and Sony assets that not many handset manufacturers have the resources to pull off and it's a world away from the plethora of cheap and cheerful (or in some cases cheap and nasty) handsets and tablets we've been seeing in the last year. While we don't think closed source would have changed Nokia's decision (the prospect of being the star of an ecosystem it can hope to dominate and realising the value of assets like Navteq is more attractive than joining the herd), if it raised the quality of Android devices and made a level playing field for developers that could explain why Eric Schmidt has predicted Nokia might one day pick Android again.

And as head of Android Andy Rubin takes control of the rumoured Google Music service for Honeycomb, a platform that Google has more control over is going to be more attractive to the record labels he needs to court. Last year Greg Peters of Netflix said the video service was reduced to dealing with individual handset manufacturers instead of releasing a single Android client; " the hurdle has been the lack of a generic and complete platform security and content protection mechanism available for Android".

The 'Icecream' release that follows Gingerbread and Honeycomb will reunite the separate handset and tablet code bases . Could it also take Android back to its roots on the Google-designed G1 phone by closing the source? Or could Google just use the threat of doing that to get premium handset manufacturers to toe the line and push updates out faster?

Mary Branscombe

Topic: Windows

Simon Bisson

About Simon Bisson

Simon Bisson is a freelance technology journalist. He specialises in architecture and enterprise IT. He ran one of the UK's first national ISPs and moved to writing around the time of the collapse of the first dotcom boom. He still writes code.

Mary Branscombe

About Mary Branscombe

Mary Branscombe is a freelance tech journalist. Mary has been a technology writer for nearly two decades, covering everything from early versions of Windows and Office to the first smartphones, the arrival of the web and most things inbetween.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

10 comments
Log in or register to join the discussion
  • @Mary: "Could Google take a leaf from Microsoft's book and rein in the handset manufacturers by taking closer control over Android - and closing the source?"

    I think the short answer is no -- that's the thing about open source, once it's open, it's open. You can't then decide to close the source, as the open source license(s) would prevent this.

    This is my layman's interpretation, I'm sure there are many things in the Real World that Google could do...
    Jake Rayson
  • @Jake - I defer to experts on interpreting licences but when the *next* version of Android comes out (say, Icecream) Google can decide to release that under an entirely different licence. Google couldn't take back the older versions of Android - so it won't solve the problems for devices already out there - but it can make things different in the future (or, possibly, the threat of that happening could also change some things). My source was quite convinced, but without proof this is, of course, still all speculation.
    Simon Bisson and Mary Branscombe
  • "I defer to experts on interpreting licences but when the *next* version of Android comes out (say, Icecream) Google can decide to release that under an entirely different licence."

    @Mary, Google can only relicense code that it owns the copyright to. And since (as I understand it) Android uses a modified Linux kernel, if Google were to try and distribute those modifications under a GPL-incompatible license then it would *immediately* lose the rights to distribute the kernel code written by everyone else.

    The bottom line: you cannot distribute a "proprietary" Linux kernel.

    As for the rest of the Android stack, you'd have to work out how much of that is 100% Google code.
    Zogg
  • @Chris - yes, it's the rest of the stack - phone makers want a platform, not a kernel. This is certainly complicated by Oracle's claim that it's not, but for instance, Google says that the Dalvik VM is a 'clean-room' implementation of Java, and the library is built on a subset of the Apache Harmony Java implementation - and while it has chosen to put Dalvik out under the Apache 2.0 licence, as a clean-room implementation it doesn't inherit copyright-based license restrictions from either the standard or open source Java runtimes - which is why it's under Google's choice of licence, and why they could choose to change that licence, or at least threaten to. It could only apply to forward releases of Android, but a clear division between the cool new stuff and the older open source stuff could still be a win for Google. Then there's all the Android 'middleware' - the apps are certainly not open source (Google made Cyanogen take them out). It would be messy and combative, but Google has been throwing a few punches recently and it's going to be really interesting to see what Rubin gets to do with Android under Larry Page's direct leadership.

    M
    Simon Bisson and Mary Branscombe
  • @Mary, So when you say "Android", you're really meaning "Dalvik" instead. Thanks for clearing that up.
    Zogg
  • @Chris - when I say Android, like most people I mean the broad Android platform, because I don't know any manufacturers who just use the Android kernel, or Dalvik or any of the other platform pieces. With Honeycomb, if you don't take the Google-sanctioned bundle, you lose a significant part of what actually makes it 'Android' and that percentage goes up with every release of the Android platform. One of the things Google does well is tie the various open, GPL and proprietary parts of the Android system together in a way that gives both control and the impression of complete openness; it's a great piece of marketing ;-)
    Simon Bisson and Mary Branscombe
  • "when I say Android, like most people I mean the broad Android platform, because I don't know any manufacturers who just use the Android kernel, or Dalvik or any of the other platform pieces."

    @Mary, then we're back to square one because Google *cannot* change the license terms for those parts of Android that it does not own %100. And it most certainly does *not* own the Android (Linux) kernel, and never will.
    Zogg
  • All rather moot dontcha think, since the carriers are not remotely interested in losing whatever differentiation they can squeeze from using Android? They are highly unlikely to pool their IP for the good of Android if it removes their own unique niche.
    @Mary... 'One of the things Google does well is tie the various open, GPL and proprietary parts of the Android system together in a way that gives both control and the impression of complete openness; it's a great piece of marketing ;-)'
    Except they don't really tie together the fundamentals of Android giving 'control'- neither to themselves or the carriers and that's both the success and fail of Android. It's certainly not user friendly. As you rightly say 'the impression of complete openness' is great marketing but complete tosh.
    frogspaw
  • Android should have been GPL-ed to avoid fragmentation.
    Google uncharitably referred to the GPL's condition of keeping source code open"viral" nature, for phone makers that might want to add proprietary features as a way to differentiate, so it chose the less confining Apache License, Rubin said.
    As Rubin had said:-
    "The thing that worries me about GPL is this: suppose Samsung wants to build a phone that's different in features and functionality than (one from) LG. If everything on the phone was GPL, any applications or user interface enhancements that Samsung did, they would have to contribute back," Rubin said. "At the application layer, GPL doesn't work."

    So basically in short Rubin was saying "handset makers should be able to fragment android...and that too with proprietary code"
    And now Android developers want close the source to "avoid fragmentation".Had Google used the GPL with Android to a larger extent ,handset makers would have avoided modifying Android and would have introduced there customizations as closed source applications.For example Samsung uses "TouchWiz" to customize UI on their android phones.In fact Samsung has releases as much code as they can without hurting themselves.GPL would have ensured that Handset makers contribute necessary changes to GPL code(the main OS) upstream and kept their customizations to themselves.

    Application on a GPL Android could have been closed-source,just like Adobe Reader, Nvidia Drivers and many more software on Linux.Despite fragmentation on Linux you will find single setups of closed source application which works on all distros of linux (like the Nvidia graphics Driver).
    abhisek243-4449e
  • @abhisek - I agree, this was a very deliberate decision by Google that's hard to see as giving open source the most advantage. But would GPL have allowed handset manufacturers not to release their customised interfaces? I'd have thought they would come under derivative works and once published rather than only used internally, have become subject to copyleft too (running the interface as an app might not be efficient or performant). There is a fascinating discussion of how Google 'cleansed' Linux code to create the Bionic library to move it from GPL to Apache licensing and whether that is legitimate (http://www.ipinfoblog.com/archives/licensing-law-issues-infringement-and-disclosure-risk-in-development-on-copyleft-platforms.html); the question of business models built atop open source continues to be a rich and interesting learning experience.
    M
    Simon Bisson and Mary Branscombe