Google recently updated its SDK license terms for the first time in a long while. While most changes are minor, one change has been grabbing quite a few headlines – Google's proclamation that those using the SDK are disallowed from taking "any actions that may cause or result in the fragmentation of Android". Here's the full clause in question:

3.4 You agree that you will not take any actions that may cause or result in the fragmentation of Android, including but not limited to distributing, participating in the creation of, or promoting in any way a software development kit derived from the SDK.

Many outlets report that this change is in response solely to the perceived "fragmentation" problem that has plagued Android's image for so long, putting the onus on developers, rather than handset manufacturers and wireless carriers. It's true that the language in the first part of the clause uses the words "any actions," but we think Google had a very specific purpose for this change of terms, and it isn't meant for developers – Google wants to prevent another Aliyun fiasco.

What it Means

Let us harken back to the Aliyun saga. For those who don't remember, Aliyun is a mobile platform built by a Chinese internet firm that is – by some metrics – the country's largest. Many of us first heard of Aliyun when Acer abruptly canceled a launch event for their A800 smartphone built with the platform in mind. Alibaba spread word that the cancelation was due to a "warning" from Google that they'd cut off Android dealings with Acer if the event proceeded.

Google soon piped up, explaining that Aliyun was not a separate platform, but one made by tearing underlying frameworks and runtime from Android. In Google's words, Aliyun was a "non-compatible version of Android," barely able to run Android apps properly, never mind Google services.

Not long after Google's initial word, we discovered something else that may have been at the heart of Google's concern – we independently confirmed that Aliyun's own app store was a virtual treasure trove of pirated Android apps (including many by Google itself).


The entire episode was very illustrative of Google's true stance on the openness of Android, and the updated TOS for Google's Android SDK appear to represent an official declaration that things like the Aliyun incident should not happen again. Google, in the updated license, is essentially saying that if you use the SDK to make something that isn't fully real, fully compatible Android, your rights to it will be revoked.

What About Amazon?

Of course, the first thing that will spring to some readers' minds (including my own) is – what about Amazon? The debate is heated as to just what relation Amazon's fork has to true Android. Aren't Android forks, by definition, derivatives of Android?

It's important to note though that just because Amazon has a fork, they aren't necessarily breaking the rules because they don't distribute a derivative SDK – Amazon, after all, relies on apps developed using the standard Android SDK, with their own mobile SDK used as a means of incorporating Amazon services (since Amazon can't make use of Google services)  – the SDK itself is not derived from Android's.

Final Thoughts

So, in the end, the TOS change has little to do with individual developers, and is more focused on stamping out the development of incompatible Android clones. Google wants to make sure that those using the SDK are not using its components to build their own derivative SDK or pumping out broken platforms based on Android, thereby fragmenting the overall environment. For the full TOS, just hit the link below.

Source: Google

Liam Spradlin
Liam loves Android, design, user experience, and travel. He doesn't love ill-proportioned letter forms, advertisements made entirely of stock photography, and writing biographical snippets.

  • TheWhiteLotus

    My question is, if they DO change the SDK and break this rule, is it that Google can sue them? Or does it just mean Google will not allow the Play Store to work?

    • ProductFRED

      I doubt they'll sue; Google has usually taken a pacifist approach when it comes to dealing with these types of things. They'll most likely revoke their Google Apps license (Gmail, Play Store, Maps, etc).

      • TheWhiteLotus

        Yes, I also highly doubt they would sue. But my question is, CAN they sue? I know that with other rules Google has said "you can do whatever you want with Android. All that we'll decide is whether the Play Store runs on your device or not if you don't adhere to them." Is it the same with this?

        • ProductFRED

          If they were to take an Aliyun-like approach, and the person breaking the license agreement were to successfully commercialize a pirated-apps-Store, then yeah I suppose they could sue. In other words there would have to be some real damage done (monetary or defamation that resulted in stock prices tanking or something).

          • TheWhiteLotus

            But the Aliyun thing was an example of the other thing, not suing. I don't remember Google ever saying they'd sue Aliyun. I thought Google just said they'd kick them out of AOSP or something like that. I'm pretty sure Andy Rubin even wrote a Google+ post saying they were allowed to do with it what they pleased.

          • ProductFRED

            No; Aliyun is an OS named after the company that makes it; it was built on Android, but heavily modified. The issues were:

            1. The app store it used consisted completely of pirated Play Store apps.

            2. Acer agreed to not build a phone that uses an unofficial fork of Android when they became an Open Handset Alliance member (Amazon, for example, is not an OHA member, and therefore can fork Android and sell the Kindle Fire).

            Google didn't sue because Acer backed off and didn't produce the phone, so Aliyun, I believe is not actually out in the wild. Actually they weren't going to sue to begin with because there were no damages at that point; all that was at stake was Acer's OHA membership, which they would have revoked. If it WAS released on a device and it lead to mass-piracy of apps, then I suppose Google could/would sue for legitimate damages.

        • Skywriter

          This clause is in the SDKs TOS and not even under the section "Use of the SDK by You".

          It's about making a new SDK and not about changing Android.
          Do what you want with Android but don't use Googles SDK to create your own SDK for your version of Android.

  • http://tablified.com Ayman Suleiman

    The SDK is meant for building apps, not building an OS. Why would this be in the SDK and not the licensing for the source code? Doesn't add up.

  • Devin Cofer

    Google is fairly obviously in the right on this one.

    Imagine a bunch of 3rd-party Android rip-off platforms that don't quite work with most apps.

    So they make their own SDKs, and the apps on Google Play become fragmented across devices they work and don't work on.

    We have enough trouble already with games that only work on certain SoCs, but hopefully that will improve.

  • RenatoFontesTapia

    are they killing monodroid with this too?

    • Melissa Peterson

      Is that an actual OS or a custom ROM, because this doesn't prevent custom ROMs from being made.

    • http://codytoombs.wordpress.com/ Cody Toombs

      99% certainty that it will not have any effect on Monodroid. The only way this change would have any effect on Monodroid is if something about it would selectively exclude certain distributions of Android (for example, an app written for Monodroid were not to run on a Nexus device but it would only run on a specially customized versions).

      For reference (for the people who aren't familiar), Monodroid is a development package that makes it possible to write applications using a .Net language (C#) instead of Java. Ultimately, the apps still compile down to an apk that runs natively on Android, just as if you had written it in Java and compiled it as normal, except it might not be quite as small or performant.

  • Asphyx

    First off I agree with the writer that this is probably done for the purposes mentioned (Alibaba) and not really about fragmentation of Android itself.
    Truth is Google itself is the one most responsible for the fragmentation of Android as they just keep on making new versions while the Carriers and Manufacturer are still trying to implement and upgrade Android units still running the Android from three versions ago!
    Add to it the fact that they have pretty much punted on standardizing the RIL and HAL in any meaningful way and left it up to the Carriers and Manufacturers to handle those parts of Android and it's no wonder it takes forever and a day to keep pace with the latest version of Android. I mean in the end Google is leaving the most important parts of Android to be written to Manufacturers and Carriers. First they have to learn the new version of Android and then spend more money to get someone to code the needed changes on a unit they aren't going to make another penny on by doing so!
    All it would take to really solve the Fragmentation problem is to standardize the calls used by HAL and RIL and force the compatability into the kernel drivers which would allow just about any version of Android to work pretty much out of the box since the drivers and radios would still use the same functions no matter what version of Android was used.
    When new gardware features come out then you create the new calls needed for it in Android so that drives for the unit are not totally Android version dependent anymore.
    Then Google can upgrade Android without the need for the Carrier or Manufacturer to rewrite code they won't profit from and the fragmentation will be a thing of the past.

    • http://codytoombs.wordpress.com/ Cody Toombs

      Yeah, no.... I'll just take these in order.

      In the context of the article, 'fragmentation' is used to talk about the creation of completely incompatible variants to the OS, which is a very different thing from issuing new versions or (as many tech bloggers often misunderstand) inclusion of OEM skins and interfaces. The same word is used to describe two very different situations. And you may not have meant it in this way, but I really can't stand to hear any argument that approaches the idea that the solution is to 'make less changes and release less versions'.

      You are completely overstating the effect of changes to the RIL (Radio Interface Layer) and the HAL (Hardware Abstraction Layer). With the exception of the changes from Gingerbread to ICS, the driver model hasn't gone through very many significant changes since the early days (Cupcake through Eclair). If you take a look at many of the forums where people are doing piecemeal ports, most of the old drivers work fine on newer versions of the OS, rarely requiring more than a little code to act as a shim for the couple of new methods that may have been added or changed. If the changes were that drastic, there would be no way that so many devices would get ports as quickly as they do. Steve Kondik of CyanogenMod gave a speech during Google I/O where he explained some of the process they use to add support for hardware that hasn't yet seen the release of a new kernel. In the instances where a particular hardware component is open source (OMAP for example), we've already seen community produced drivers happen at a record pace. To say that billion-dollar companies are getting stumped on updating some driver code when they've got the hardware manuals sitting on their desks is simply wrong. Furthermore, this is part of the reason Google has started up the PDK (Platform Development Kit) program for their partners, to give them early access to the changes in the driver model.

      I'm not saying that drivers aren't ever the reason for delays, but there are far more significant reasons:
      a) It's profitable to delay releases to encourage some customers to abandon older hardware to buy the latest model.
      b) The larger development cost associated with releasing updates is related to all of the OEM modifications. OEMs went into such deep customizations, especially in the 2.x days, that each time they were going to release updates they had to spend weeks in fixing existing bugs, adding features, and testing everything to make sure they hadn't broken something in the OS.
      c) They don't care. In line with what you said, they aren't going to make any more money on devices they've already sold. The only incentive to release another update is to minimize the bad press that comes from people complaining that their devices aren't getting the updates they expected. As a company, when you're trying to decide where to dedicate your resources, you aren't going to dedicate time and money towards supporting old devices when you can put them towards creating the new devices.

      Trust me, I agree that Google is responsible for not making the situation better than it is, but committing to making fewer improvements is definitely not better for anybody.

      • Asphyx

        Well fragmentation goes a lot further than skins and interfaces if you ask me. I mean an interface is not much more than a launcher for all intents and purposes and if skins were a problem then Google could have made android easily skinnable as opposed to being tied to particular versions of android and launchers. Again if they had set the standard as opposed to letting anyone just do what they want with the parts Google left unanswered (HAL, RIL, SKINS)

        As for the Driver issues I was speaking directly to the fact that it's the carrier code that is all over the place using pretty much a custom program running to run the radios which SteveK also commented on at Google IO. In some cases they work across different versions and when they don't you never see an update to that version of the OS without inccessant whining to your provider. So google can't update Android for everyone because it doesn't write the entire code needed for it to run on every unit. Only the GE (and really only Nexus) devices can be easily updated by Google.

        If google had standardized how the RIL must talk to Android better then there would be no need to rewrite the carrier portion for compatability. Cause it would be compatible with any Android "Standard"

        Wer all look for Nexus units as a PLUS type device but the truth is they should be the standard rule not the exception.

        As far as the real problem with fragmentation it is really an issue for the developers because they are forced to code and change code for many different versions that are not compatible and at some point they just stop keeping up.

        You could buy an app today that works fine, upgrade to a new device with Jelly Bean and lose that purchase for use unless the Developer has the good sense to fix the incompatabilities.

        No one is suggesting that Google shouldn't innovate or release new versions but they could be a little more dilligent in knowing when a change is likely to break something and build in a workaround that could make the old way of doing things work under the new system just as well.

        This is the reason the FUNCTION CALL was developed so no matter how you changed the function, as long as the function does the same task it doesn't matter HOW it does it only that it returns the proper result.

        And it is this that Google has the power to control.

        Apple suffers from none of those issues really. Sure because they are the only ones who release versions....Google could take the same control if they wanted and get rid of the fragmentation they seem to be so worried about.

        But it requires filling in the pieces of HAL and RIL they seem reluctant to do so to standardize those systems in a way that any android can run on any unit without having to wait for some 3rd party to finish it and in the proccess make it incompatible with other versions.

  • dinso

    i totally agree with google on this. fragmentation, piracy and having billions of people getting the benefits of android while not contributing to advertising earnings for google are great reasons to discourage this kinda thing. but i think the products like aliyun and baidu mobile os illustrate a problem ive seen with mobile operating systems in general, although i think its particularly inexcusable in the case of android for reasons i explain below. asian consumers have shown that they have a hunger for services and features that are homegrown, locally relevant and feel like they were specifically made with them in mind. in too many instances google services are US first and are later modified for 'international' users as a kind of afterthought.im a vixtim of this too since i dont live in the US. services like google books, movies, music the list goes on...
    why are they trying so hard to get complicated inter-country licensing aggreements? doesnt south africa have its own print publishing industry? dont india and nigeria have flourishing film industries? instead of trying to move mountains getting ppl in india to watch transformers, why not start by allow them to watch bollywood movies on their own google movies site. afterall google is not new to compartmentalising their products based on location. call it a "local first" strategy. i think it would be a way easier place to start and youd really make your 'international' users happy.
    I understand google is a US company and the US is a huge market but their not the only one out there. for the longest time when registering an apple device my country was not even available as an option, so you just had to choose the uk or us option. really decreases my engagement with your product if you dont even acknowledge that i exist.

    its also particularly mind boggling when you see how much more popular android is internationally compared with in the us. look at those recent figures in china 90% or something like that? i mean gee looks like theyre becoming less and less a US company and more a global company. so tailoring google products for different locales is important. and its not just about language support, or location based apps. it should go a bit deeper than that. one important step is allowing developers from any country distribute paid apps. theyd immedeately multiply the number of users in a country if they incentivize developers in that country. case in point: india - thousands of amazingly talented developers who were kinda cut out of android for years. think of how apple made a point of introducing some features specifically made for china at wwdc this year. theyre saying, "hey china: we know youre there and we care". if google doesnt chinese customers are gonna continue to gravitate towards baidu services and away from google services. and this will happen in every country.

    just saying...

    • http://codytoombs.wordpress.com/ Cody Toombs

      Nobody is preventing Android from being tied to other services. Amazon is obviously doing quite well by breaking ties with the Google services and replacing them with their own. This change to the license is about preventing OS incompatibilities, not about preventing competitors from providing their own alternatives with Android as the base. They are trying to prevent technical issues which would devalue Android as a platform for developers to target.

      Honestly, I don't understand why there isn't a company in India or China that offers their own local counterparts for the book and movie markets. These seem like incredibly obvious and very profitable businesses, so it surprising if somebody (especially a local company) hasn't jumped up to fill that demand. If I had the money and a few connections, I'd jump on this (in India, not China).