It's a poor idea. Google has worked to make Android functionally unforkable, with no practical way to simultaneously fork the platform and take advantage of its related strengths: abundant developers, and abundant applications.

The outline of the "Microsoft should fork Android" argument is as follows: Windows Phone doesn't have huge developer buy-in or sales success, but Android has both. By forking Android, Microsoft could provide unique value—corporate integration with things like Exchange, Active Directory, and System Center or InTune; full Office support; a polished user experience—and make the platform depend on its own cloud services (Bing, Bing Maps, Azure) rather than Google's. But simultaneously, it would still have access to all the Android applications that people depend on.

The result should be a platform that's somehow more attractive to consumers, by virtue of the Android brand and all those Android apps, more attractive to developers thanks to the Android APIs, and cheaper for Microsoft to develop, since core operating system development can be left to Google.

Where this falls down is that there's no good way to use the Android platform this way. It's not designed for it. In fact, with each new Android release, Google is making a forked operating system less and less viable.

Not-very-open source

Broadly speaking, Google produces two big chunks of code. The first is the Android Open Source Platform (AOSP) codebase. This provides the basic bones of a smartphone operating system: it includes Android's version of the Linux kernel, the Dalvik virtual machine, and portions of the basic user interface (settings app, notification panel, lock screen). This part is licensed under a mix of the GPL and Apache license. Google produces periodic code release of these open source parts, though has been criticized for performing the actual development largely behind closed doors.

The second chunk is called the Google Mobile Services (GMS). (Or at least, sometimes it's called GMS. Sometimes it's called just Google Services, and sometimes it's Google Play or Google Play Apps; GMS is what it's called in the code, though, so that seems to be the most common name). This has two big portions. The Google Play Services provides a wealth of APIs and system services: APIs for Google Maps, Location, and in-app purchasing; Google+ integration; Remote Wipe; Malware scanning; and more. Then there's the Play Store collection of apps: Search, Gmail, Chrome, Maps, and many more.

The GMS has a few important features. GMS isn't open source. Anyone can take AOSP and slap it on a phone. That's not true of GMS. To get GMS, the device has to meet certain technical requirements (performance, screen resolution, and so on), and it has to pass validation. Though Google says that the GMS suite is itself free, the validation process isn't, with reports that it costs around $0.75 per device.

GMS also seems not to be divisible: if your phone passes the GMS validation and can include GMS, it includes everything: both Play Services, and the various Google-branded apps that use those services.

Further Reading

The split between AOSP and GMS is not constant, either. Google has slowly been migrating more and more functionality to GMS. For example, in the latest Nexus 5, the core phone user interface—the thing that you use to launch apps and show icons—has been rolled into the GMS Search app.

Similarly, APIs have made the move. AOSP contains a location API, but GMS contains a newer, better one, with additional features. Google encourages developers to use the GMS API, and the AOSP Location API mostly dates back to Android 1.0, and hasn't seen any substantial changes since Android 1.5. The result is that many third-party applications are not merely "Android" applications: they're GMS applications, and won't run without the proprietary, non-open Google software.

Four ways to do Android

There are four ways that hardware builders can use Android on their phones.

The first is the way that Google really wants companies to use Android: by relying both on AOSP and GMS. Pass the certification, include all the Google services and Google apps. That's what companies like Samsung and HTC and LG do. Going this route still provides some facility for the OEM to customize. OEMs can provide their own apps to sit alongside the Google ones, for example. It appears that Google isn't completely happy about this—there are reports that the company recently made an agreement with Samsung whereby Samsung would reduce the amount of customization of the user interface and deprioritize or remove its apps that competed directly with Google-branded equivalents.

Taking this path provides the best compatibility with third-party applications by ensuring that they have both AOSP and GMS APIs available to them. It also provides the most consistent experience: in spite of the various customizations that are done, it means that Google's apps will be available, and those apps will work the same way on any AOSP+GMS device.

It also cedes most control to Google, and that level of control will only grow. Each new release increases the level of integration with Google's own services, and Google is moving more and more new functionality to GMS, leaving AOSP a barebones husk.

At the other end of the spectrum, you can ignore GMS entirely. Ship a phone with AOSP and perhaps some custom software on top of it to make the experience a little less rough for users, and call the job done. At the very cheapest end of the market, there are companies doing precisely this; it's abundant in China, in particular. If they choose, OEMs can provide their own stores and other services to fill the many, many gaps that omitting GMS leaves, but they're always at a disadvantage relative to GMS devices, because they won't be compatible with any third-party applications that use GMS' APIs. That's not a small category, either, since features such as in-app purchasing are in GMS.

The third option is the one that spans the two: ship a device with AOSP, and an equivalent to GMS that provides new implementations of substantially the same APIs. Provide workalike replacements for services such as location and mapping, but plumb into Microsoft services rather than Google ones. No company has really gone down this route. The closest is Amazon, which provides near-drop-in replacements for some Google APIs (in particular mapping), but which hasn't even begun to keep pace with GMS development in general.

Technically, however, a company with sufficient development resources could provide its own GMS replacement. The overhead would be not insignificant, especially as—to ensure optimal compatibility—the replacement would have to replicate not just correct functioning, but any bugs or quirks of the GMS implementation.

There are also lots of little awkward aspects of the GMS API; it includes such capabilities as "share with Google+" which few companies have any real counterpart to. Another example: there is an API for handling turn-based multiplayer gaming. A company could implement this API and have its own server infrastructure for managing the gaming sessions, but obviously these gaming sessions would be completely separate from Google's gaming sessions, fragmenting the player base in a way that game developers are unlikely to be keen on.

As an added bonus, should the ultimate resolution of Google's long-running legal battle with Oracle be that APIs are, in fact, copyrightable, this kind of wholesale reimplementation of GMS would become legally actionable. Google could, if it chose to, shut it down through the courts.

To these three options, one could perhaps add a fourth: use AOSP to provide a few essential services—support for hardware, telephony, and so on—but then build an entirely new platform and APIs to run on it. Aspects of Amazon's API support would fall into this category, with some of its APIs covering the same ground as GMS APIs, but in a completely different, incompatible way. It's not clear, however, that any manufacturer has entirely embraced this path, though one might argue that Ubuntu for Android is similar, at least in spirit.

You can have compatibility or control: Not both

The first of these options—AOSP with GMS—is the only option that provides the full Android experience. It's the only one that ensures developers can transfer their skills perfectly, the only one that ensures that the full breadth and variety of Android software is available. However, it's clearly not a good option for Microsoft, given that it would almost entirely cede control of the platform to Google—and judging by the advertising company's track record, it would cede even more control with each new Android release.

The second option—AOSP with a few extra custom extras—has the upside of providing an opportunity for Microsoft to integrate its own services. It would support some Android software, though exactly how much is unclear. It would certainly mean omitting any high-profile title using in-app purchasing, so, say, Plants vs. Zombies 2 or the latest iteration of Angry Birds would be out. If one were building a feature phone platform, this may be a somewhat reasonable path to take. When the phone is only really built for running the built-in apps (camera, browser, e-mail) the fact that many Android apps would be incompatible doesn't really matter.

The rumors of a Nokia-built Android phone suggest this kind of approach: AOSP under the hood, but with Nokia services, not Google ones, on top.

This approach also probably works acceptably for ultra-low-end devices where compatibility isn't such a big deal, which accounts for much of the Chinese AOSP market. But for Microsoft, this would be missing the point: the company already has a platform that's not compatible with the latest and greatest high profile apps. It doesn't need another one.

However, it's important to understand just how deficient this kind of device would be. Google has pushed very significant pieces of functionality into GMS, including messaging and the Chrome browser. The AOSP counterparts are buggy, feature deprived, and by at least some accounts, barely maintained. If a company wants to use AOSP without GMS, it has a lot of work to do if it wants to produce a high quality experience. The open source parts just aren't good enough.

Amazon's Kindle experience also demonstrates how even having an Android-like AOSP-derived platform is challenging. Kindle doesn't have the latest and greatest Android games, because their various developers haven't bothered making non-GMS versions of their games, even though the Kindle platform is very similar to Google's. In other words, the application challenge already faced by Windows Phone isn't solved by using AOSP. The only way to solve the application issue is to be not merely an AOSP platform but a GMS platform.

The third option—AOSP with a home-grown GMS equivalent—would solve this, but it would also maximize the development effort required by the forker. Providing equivalents to every GMS capability ensures at least that users get a decent experience. It would also reinstate the software compatibility that AOSP without GMS forfeits.

But this is a huge undertaking. For Microsoft, the effort required to build a GMS workalike on top of AOSP is going to be comparable to the effort required to build the Windows Phone shell and APIs on top of Windows. In fact, it's likely to be somewhat greater: Microsoft already has, for example, a browser engine that runs on Windows. It doesn't have one that runs on AOSP.

Moreover, it still implicitly gives Google control over the platform. Various aspects of how Android is used are determined by the underlying APIs: sharing between applications, for example, is done in a particular Android way. Any platform using Android in this way would have only a limited ability to take the platform in a different direction from the one Google chose.

The fourth option—use AOSP with an entirely new software stack on top—gives freedom and flexibility, but to what end? The kernel isn't the important bit. Microsoft already has a smartphone kernel. Windows Phone 8 already uses it. And strikingly, for Microsoft, ditching Windows Phone doesn't mean that the company can ditch development of this kernel. It's already being developed—for Windows! The kernel isn't the hard part.

Fork off

If Android were an open platform in the way that Firefox OS or Ubuntu for smartphones were an open platform, the forking suggestion would make more sense. The AOSP/GMS split wouldn't exist. Everything would be in AOSP, so piecemeal substitution of back-end services without having to reinvent vast tracts of code and without any major compatibility implications would be practical.

But it isn't. Not only is it not this kind of an open platform, but Google is actively working to make it functionally less open with each new release. The result is that a forker has to make a choice: they can give Google control and get the all the upsides of the platform, or they can snatch control from Google and get almost none of them.

Android isn't designed to be forked. With GMS, Google has deliberately designed Android to resist forking. Suggestions that Microsoft scrap its own operating system in favor of such a fork simply betray a lack of understanding of the way Google has built the Android platform.

Promoted Comments

You left out Google's licensing agreements with hardware manufacturers, which prohibits them from shipping incompatible (read non-GMS containing) Android devices based on AOSP code AND GMS devices. Basically, a hardware OEM will have all GMS applications rejected if they build an AOSP-based device for a different software vendor. Amazon has had to shop around a *lot* to find an OEM for the Kindle - it has to be an OEM with no ambitions of becoming their own Android brand.

Why would anyone suggest with any seriousness that Microsoft should abandon their NT-kernel-based smartphone OS with a Linux-kernel-based fork of Android? I really can't understand how that sounds like a good idea, especially as WP8 is actually doing pretty well in some countries. Their problem in the USA is more of an image and awareness issue than anything...

How about an open source GMS? It'd take a dedicated company with deep pockets, but if Amazon duplicated current GMS and enough developers started targeting it as the lowest common denominator, you could wrest that control from Google, couldn't you?

I think Android has already forked, at least 3 ways, possibly 4 if you count the Nook. The low end non-Google tablets are worthless if you want to load an app from the Play store. Amazon and Barnes and Noble basically did exactly what is described in the article, creating their own app store with it's own SDK. That would imply they have a lot of their own code on the device too.

As someone with parents who refuse to take my advice when it comes to gadgets*, I can tell you these low end devices are about as far from the Android experience as iOS.

*"$69.99 for a 'Polaroid' tablet! Can you believe it? Now how do I load up all those neat apps you have?" -Dad

I think Android has already forked, at least 3 ways, possibly 4 if you count the Nook. The low end non-Google tablets are worthless if you want to load an app from the Play store. Amazon and Barnes and Noble basically did exactly what is described in the article, creating their own app store with it's own SDK. That would imply they have a lot of their own code on the device too.

The main difference between Amazon and Microsoft is that Amazon doesn't have to care about being compatible with Google Play. In fact, they'd presumably prefer not to be. Amazon is in the business of selling content, and they want you to buy all the content for your kindle from them. Being a fork is, for them, an advantage. By controlling their own app store they can keep out competitors like Kobo. Microsoft might want that too, but they're not going to get it.

For a significant number of people, openness is practically of no value; they only want a phone that works. And this is the market that Google is targeting.

There's another option actually: provide *both* GMS and an additional Microsoft framework inside. Yes, it will consume additional RAM, but a 2 GB phone should have no problems running two frameworks.

Many open source projects are updated very rapidly... Remember how many people got dizzy when Firefox said they'd be incrementing their version number with every release. We were at Firefox 3 a few years ago, and now we're at Firefox 27. Of course, there are lots of open source projects that languish or have laborious governance, but there are plenty that release nightly updates, too. So, I think you certainly can have "open" and "rapidly updated" at the same time. Not sure why you're saying you can't.

I think you're right about who Google is targeting. And probably a lot of of their customers are like that. Unfortunately, many of their more vocal customers are _buying_ Android phones because they feel like they are more "open". If only they knew...

The whole "two frameworks" thing has been done on occasion and it never works. Who was it recently that made a tablet or netbook that dual-booted Android and Windows 8? Maybe Asus? I'll admit I can't think of a ton of failures, but I can't think of any successful dual-products. Even something sensible sounding like DVD/VHS combos were more of a curiosity. A dual product usually costs more and doesn't run either of its constituents quite as well as a dedicated product, or has other tradeoffs that people don't like.

I'd be highly interested. And I think it'd pay off for them because much of their business comes from areas where Android is already king.

Can you imagine how awesome Nokia hardware would be with android?

Not as awesome as it is with WP8 trololol...

Seriously, though, I don't have experience with their high-end phones, but even their $100 Lumias feel pretty solid. I think Android would struggle with the horsepower inside, though, even with the recent optimization that it has undergone.

Edit: I mean to say that Android would not be as smooth of an experience on a 520 or 620, not that it would struggle on a 1020 or a 1520.

If the Google vs Oracle court decision w.r.t. APIs gets overturned and APIs are judged as copyrightable it will have a greater impact than just restricting companies from replicating the GMS APIs (and the effects of this on Google using the Java API in Android). That does not even cover if/when people start going after similar APIs (e.g. SAX-based or reader-based XML processing APIs in the different languages/frameworks/libraries).

Get rid of Windows Phone 8 and instead use Windows RT across all ARM devices. Add a XAML view for phone screen in Windows 8 apps and call it a day.

Windows Phone 8 and it's stuck in purgatory limbo craptastic API needs to die if Microsoft has to survive on phone devices. The platform hasn't moved an inch since end 2012. Tiny meaningless changes which are completely failing to keep up with iOs and Android.

Seriously what the fuck has the Windows Phone 8 team doing all this time? What do they do all day? Post nasty messages to IOS and Android dev mailing lists and run out into the bushes giggling like little girls?

AOSP is really just the parts that OEMs need to port Android to their devices without constant oversight from Google. I imagine if you wanted to build a Windows Phone 8 device, the NDAs required to work with the core code would be a nightmare to deal with, but with AOSP, literally anyone can do it, with a bit of frivolous customization allowed too.

I think there's another option - go the GMS copy with MS services substituted route at first, long enough to get enough app compatibility to get people buying MS phones. If that works, then fork; with a large enough userbase, developers will adapt their apps - or if they won't, they wouldn't have for Windows Phone either, so just call it a failure.

Why would anyone suggest with any seriousness that Microsoft should abandon their NT-kernel-based smartphone OS with a Linux-kernel-based fork of Android? I really can't understand how that sounds like a good idea, especially as WP8 is actually doing pretty well in some countries. Their problem in the USA is more of an image and awareness issue than anything...

I think more to the point is why would a MICROSOFT with nearly unparalleled experience in developing SYSTEM SOFTWARE want to use Android as the basis of their phone's OS?

If people want to run Windows APIs on their phones, they want a WINDOWS PHONE, not an Android phone or an Apple phone.

There are people like that, so why the hell not? It's a market. Their failure was in not realizing that it's a DIFFERENT market than the one captured by Apple and Google, and a smaller set of people can be persuaded to pay a premium for devices designed for the market of people-who-want-or-need-a-Windows-API-on-their-mobile-device, so long as they don't suck.

Even better if they copy the AOSP API and as much as they can reverse-engineer of the GMS API and provide users with a way to download and install Android apps as well if they want. Or fuck it. Why not also reverse-engineer the Apple APIs so users can run iTunes and all that Appleware if they want?

It would be a mirror of the way users put WINE or MONO on their Linux and Macintosh computers to run Windows apps.

Or another option: Develop, promote and distribute an app that modifies your Android phone with a Windows API so you can run Windows apps on it. Then lever it into OEM Android phones by getting users to ask, "Does it run Windows apps?"

I think that it's pretty much a given that, between iOS, Android 4.X, and Windows Phone 8, WP8 is /vastly/ lighter on resources. If Nokia/Microsoft started using Android, there's no way a device like the Lumia 520 would ever exist. If you want to know what a responsive and smooth phone looks like for <$70, check a 520 out.

That's just something that doesn't happen with Android. Can you imagine running Jelly Bean/ KK on an MSM8930 w/ 512MB single channel 533mhz RAM? That would be quite the disaster.

In short, Microsoft really has no incentive to want to make an Android phone. It would go against their fundamental strategy of "throw money at a losing idea for a decade until it becomes profitable." (Xbox).

I would never advocate that Microsoft abandon their platform for Android, but this article challenges us to accept claims like "can't", which I don't believe are supported by reality.

It is commonly reported that more than 70 percent of Android smartphones in China do not offer Google Play services. We already see that there is a significant market that doesn't care about 100% application compatibility, or Google services.

In addition, Microsoft could curate their own store with apps that have had minor updates to use Microsoft location services instead of those from Google.

Again, I don't suggest they should do it, just that I can't see this as impossible.

Why would anyone suggest with any seriousness that Microsoft should abandon their NT-kernel-based smartphone OS with a Linux-kernel-based fork of Android? I really can't understand how that sounds like a good idea, especially as WP8 is actually doing pretty well in some countries. Their problem in the USA is more of an image and awareness issue than anything...

The only places it is doing well is where people have limited funds, and they buy very low end Luminas for a price that nets Microsoft nothing.

I changed jobs a while back and I am regularly taking public transit for the first time in my life.

On the ground it looks much worse for Microsoft in Mobile than the impression I get from the net.

What I see are Tons of iPhones/Android phones (and a significant number of Blackberries). I have yet to see a single Windows phone.

I see lots of E-ink readers (Kindles/Kobos, etc), some iPads and some Android tablets, and again I have yet to see a single Windows tablet.

I see a myriad of devices in transit every day and I can count the number powered by a Microsoft OS on one finger. That is it. I have seen ONE MS powered device used in transit (someone with a Dell Laptop).

That said, it still makes no sense for Microsoft to get into Android phones/run Android apps, regardless of the forking potential.

I think Android has already forked, at least 3 ways, possibly 4 if you count the Nook. The low end non-Google tablets are worthless if you want to load an app from the Play store. Amazon and Barnes and Noble basically did exactly what is described in the article, creating their own app store with it's own SDK. That would imply they have a lot of their own code on the device too.

As someone with parents who refuse to take my advice when it comes to gadgets*, I can tell you these low end devices are about as far from the Android experience as iOS.

*"$69.99 for a 'Polaroid' tablet! Can you believe it? Now how do I load up all those neat apps you have?" -Dad

I actually got one of those Polaroid tablets for my sister-in-law. On the model I got, at least, it was trivial to download the GMS zip from Cyanogen's site and install it using ADB. It's actually a decent little tablet for the price; nothing too fancy, but lets her play videos, read comic books, and show off her art.

Why would anyone suggest with any seriousness that Microsoft should abandon their NT-kernel-based smartphone OS with a Linux-kernel-based fork of Android? I really can't understand how that sounds like a good idea, especially as WP8 is actually doing pretty well in some countries. Their problem in the USA is more of an image and awareness issue than anything...

I would never advocate that Microsoft abandon their platform for Android, but this article challenges us to accept claims like "can't", which I don't believe are supported by reality.

It is commonly reported that more than 70 percent of Android smartphones in China do not offer Google Play services. We already see that there is a significant market that doesn't care about 100% application compatibility, or Google services.

In addition, Microsoft could curate their own store with apps that have had minor updates to use Microsoft location services instead of those from Google.

Again, I don't suggest they should do it, just that I can't see this as impossible.

He didn't say it was. He said it'll be hard and probably pointless. And China is China, they are pretty heterogeneous, it works there. Microsoft is a different story.

Why would anyone suggest with any seriousness that Microsoft should abandon their NT-kernel-based smartphone OS with a Linux-kernel-based fork of Android? I really can't understand how that sounds like a good idea, especially as WP8 is actually doing pretty well in some countries. Their problem in the USA is more of an image and awareness issue than anything...

The only places it is doing well is where people have limited funds, and they buy very low end Luminas for a price that nets Microsoft nothing.

I changed jobs a while back and I am regularly taking public transit for the first time in my life.

On the ground it looks much worse for Microsoft in Mobile than the impression I get from the net.

What I see are Tons of iPhones/Android phones (and a significant number of Blackberries). I have yet to see a single Windows phone.

I see lots of E-ink readers (Kindles/Kobos, etc), some iPads and some Android tablets, and again I have yet to see a single Windows tablet.

I see a myriad of devices in transit every day and I can count the number powered by a Microsoft OS on one finger. That is it. I have seen ONE MS powered device used in transit (someone with a Dell Laptop).

Meanwhile, in Italy Windows Phone is now bigger than iOS (on new phones). On a global scale what you see on your commute is pretty insignificant. I think I've seen two Windows Phones IRL the last years, but that doesn't change the fact they are growing.

Application writers can't implement the newest API's etc if they want the application to have a market as most phone out there are old. So newer API's aren't that big a problem for forking as apps will have to support phones 3-4 year old.

Google+ integration too isn't a big problem when most people use Facebook.

The platform hasn't moved an inch since end 2012. Tiny meaningless changes which are completely failing to keep up with iOs and Android.

Seriously what the fuck has the Windows Phone 8 team doing all this time? What do they do all day? Post nasty messages to IOS and Android dev mailing lists and run out into the bushes giggling like little girls?

I often wonder this. I used to think Windows Phone was EASILY the best platform (not accounting for the then-poor app selection) - but it hasn't received a significant update since WP8 launched. Hopefully 8.1 changes things, otherwise I might switch back to Android.

I think Android has already forked, at least 3 ways, possibly 4 if you count the Nook. The low end non-Google tablets are worthless if you want to load an app from the Play store. Amazon and Barnes and Noble basically did exactly what is described in the article, creating their own app store with it's own SDK. That would imply they have a lot of their own code on the device too.

As someone with parents who refuse to take my advice when it comes to gadgets*, I can tell you these low end devices are about as far from the Android experience as iOS.

*"$69.99 for a 'Polaroid' tablet! Can you believe it? Now how do I load up all those neat apps you have?" -Dad

I actually got one of those Polaroid tablets for my sister-in-law. On the model I got, at least, it was trivial to download the GMS zip from Cyanogen's site and install it using ADB. It's actually a decent little tablet for the price; nothing too fancy, but lets her play videos, read comic books, and show off her art.

Did she install the GMS or did you? If she did, was she able to ignore all the warnings about bricking and usual BS disclaimers that pop up when you do the install? Or did she call you because she was worried about destroying her device because some programmer who took a 3 credit law class thought a click through would get him off the hook if someone decided to sue him over some poorly written code (not that Cyanogen is bad code, it's actually often better than stock).

Trivial and simple for you isn't the same as it is for everyone, especially when their worldview is that computers are barely able to function and it's a miracle that they boot at all, let alone work for years without problems.

Why would anyone suggest with any seriousness that Microsoft should abandon their NT-kernel-based smartphone OS with a Linux-kernel-based fork of Android? I really can't understand how that sounds like a good idea, especially as WP8 is actually doing pretty well in some countries. Their problem in the USA is more of an image and awareness issue than anything...