Linked by Thom Holwerda on Mon 21st Oct 2013 22:15 UTC, submitted by ddc_
Google

Ars Technica has a great article about what, exactly, Google is doing to retain (or retake) control over Android. Many things were already known, and have, in fact, been discussed here before. For instance, the Open Handset Alliance prohibits its members from forking Android or using other companies' forks. This had been known for a long time, and has always been an important aspect of the OHA - its goal is to prevent the fragmentation of Android, after all. Another thing we've always known is that the Google Applications - like YouTube and such - have always been closed source, and that a license is required to use them (they are freely available though, and Android is completely usable about them.

There are two bigger problems, however. First, the more Google moves parts of Android to Google Play (such as the keyboard or calendar), the less open source Android becomes.

For some of these apps, there might still be an AOSP equivalent, but as soon as the proprietary version was launched, all work on the AOSP version was stopped. Less open source code means more work for Google's competitors. While you can't kill an open source app, you can turn it into abandonware by moving all continuing development to a closed source model. Just about any time Google rebrands an app or releases a new piece of Android onto the Play Store, it's a sign that the source has been closed and the AOSP version is dead.

There's definitely an opportunity here for groups like CyanogenMod - and in fact, that's exactly what's happening. For instance, CM has created the camera application Focal, which is available in the Play Store. In other words, most of the Google Applications can be recreated and improved upon easily, after which they can be placed in the Play Store. An exception, of course, is the Play Store application itself, but even that one has alternatives, such as the Amazon App Store.

A bigger problem, however, are the Google Play Services. This is an Android application - closed source - that provides developers with access to a whole bunch of Google's APIs. It's becoming more and more mandatory.

Taking the Android app ecosystem from Google seems easy: just get your own app store up and running, convince developers to upload their apps to it, and you're on your way. But the Google APIs that ship with Play Services are out to stop this by convincing developers to weave dependence on Google into their apps. Google's strategy with Google Play Services is to turn the "Android App Ecosystem" into the "Google Play Ecosystem" by making a developer's life as easy as possible on a Google-approved device - and as difficult as possible on a non-Google-approved device.

In other words, there's a lot going on at Google to prevent more forks, such as Kindle Fire, from happening. I had no issues with Google's own applications being closed source (you can easily replace them), but the Play Services are a much bigger issue. As more and more applications adopt Play Services, the harder it'll become to run Android 'Google free' - and that's not exactly an ideal situation.

Thread beginning with comment 575233
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: Huh?
by lucas_maximus on Tue 22nd Oct 2013 18:23 UTC in reply to "RE[3]: Huh?"
lucas_maximus
Member since:
2009-08-18

Yeah it is "technically open" ... but (depending on a companies resources) porting over changes from Google's branch to your own version will become problematic, time consuming and costly.

I maintain my own version of jQuery, parsely.js and bootstrap (I added in legacy IE support). I don't have time to merge the changes from new releases so as time goes on my version is becoming increasingly incompatible with the un-modified versions.

This is because I can't dedicate enough time at work to keeping up with the change of pace on these projects. And these are a few hundred lines of code.

Realistically if the project is large enough, the company that is developing controls the development, which isn't really that different from closed.

Edited 2013-10-22 18:27 UTC

Reply Parent Score: 3

RE[5]: Huh?
by darknexus on Tue 22nd Oct 2013 18:45 in reply to "RE[4]: Huh?"
darknexus Member since:
2008-07-15

[q] I maintain my own version of jQuery, parsely.js and bootstrap (I added in legacy IE support). I don't have time to merge the changes from new releases so as time goes on my version is becoming increasingly incompatible with the un-modified versions.

This is because I can't dedicate enough time at work to keeping up with the change of pace on these projects. And these are a few hundred lines of code.

It's interesting that Google's measures to supposedly prevent the fragmentation of Android may, in fact, cause it to fragment even worse in the long term. You're absolutely right that other companies/developers/whatever wouldn't be able to continue to backport (for lack of a better word) Google's changes into their branch. Besides, in the case of businesses with other goals, it may not even make sense to try. Android's already fragmented enough, any more diverging and Google might as well be the only one with the Android name. We'll have AmazonOS, SamsungOS, HTCOS, etc and Android as we see it now might just fade away into history.

Reply Parent Score: 2

RE[6]: Huh?
by lucas_maximus on Tue 22nd Oct 2013 19:58 in reply to "RE[5]: Huh?"
lucas_maximus Member since:
2009-08-18

I can easily see Amazon being able to put the resources in (they are at the end of the day a Software House) that happens to make decent hardware.

But HTC, Samsung, ZTE and friends. I can't see it. I can't talk about Samsung's SDK too much because I believe I maybe under NDA or my employer is ... but their free SDK tools are somewhat lacking and they have no easy "Hello World" and the Todo app / Blog example to get you up and running with some of their platform.

Reply Parent Score: 3