额济纳旗东风航天城入选首批中国十大科技旅游基地

As happens from time to time, the suggestion has been made that Microsoft cancel Windows Phone, and instead fork Android. It's not the first time this suggestion has been made. It's probably not the last, either.

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.

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.